Drivechains are a Layer2 technology for Bitcoin that allow the creation and use of multiple sidechains, thus facilitating the existence of alternative currencies within the same Bitcoin network. This approach has numerous advantages. These include the ability to experiment without permission, introducing new features and use cases, mitigating competition between blockchains, and improving scalability.
The creator of the proposal is Paul Sztorc, a Bitcoin developer and current CEO of LayerTwo Labs, who presented two improvement proposals for Bitcoin (BIPs) in 2017: the BIP-300 and BIP-301. In these two BIPs, Sztorc laid the foundation for a decentralized implementation of multiple Bitcoin sidechains.
Drivechains
Sztorc's goal is for Bitcoin to absorb the rest of the altcoins, by allowing them to be represented as Bitcoin sidechains, thus avoiding the fragmentation of the ecosystem and improving interoperability between them. In this way, it would be possible for cryptocurrencies such as Litecoin to be simply a drivechain representation within Bitcoin, secured by the Bitcoin network, compatible with it and being fully interoperable, as is the case with the current Lightning Network.
How Drivechains work
To make all of this a reality, Drivechains utilize a number of capabilities of the Bitcoin network. More specifically, they use Simplified Payment Verification (SPV) proofs to allow users to transact Bitcoin to and from a sidechain, employing two-way pegging.
The BTC sent in this operation is subsequently locked to a dedicated on-chain address. This address functions as a secure vault, assigning balances to the drivechain in question. This system is very similar to what we see in current cross-chain pool bridges in the DeFi ecosystem.
Let's remember that when we send a token or currency between chains (e.g. DAI from Ethereum to DAI in Polygon) what really happens is that the bridge takes our DAI in Ethereum and issues the corresponding amount of DAI (paying commissions) in the Polygon network.
Well, exactly the same thing happens with drivechains. When a Bitcoin user makes a payment to interact with a drivechain, they issue the payment with a series of instructions (using Bitcoin Script), which are then processed by the Bitcoin network and the drivechain in question.
In the end, the user will receive their corresponding payment in the drivechain and specified address, while their BTC (the source currency) is stored in a vault as liquidity insurance between both networks. A very similar mechanism is used in the Lightning Network, using a type of contract known as HTML or Hash Time Lock Contract.
Your own consensus rules
Of course, all this goes through a verification process, in which both parties (the mainchain and the drivechain) verify the transaction carried out, ensuring that the balance blocking operation is done appropriately. This is important because the security and correct economic relationship between both chains depends on it.
But here another fundamental point of drivechains comes into play: they can have their own consensus rules. Thanks to this capability, drivechains can have issuance and commission policies that are different from those we see on the main Bitcoin chain, which, in effect, makes them a “separate” ecosystem from Bitcoin, even though they are actually running independently. jointly.
Multiple cryptocurrencies, one network
For example, a possible implementation with drivechains is ZCash. Let us remember that ZCash is a derivative of the Bitcoin protocol, to which a series of measures have been added designed to improve the privacy of this cryptocurrency, thanks to the use of zero-knowledge proof cryptography, zk-SNARKs.
Being a derivative, ZCash has many similar aspects with Bitcoin, which makes it compatible with the implementation of drivechains. Thus, we can create a drivechain for ZCash and add everything necessary for its operation to said drivechain. Including, of course, the anonymity capability that zk-SNARKs enables. All this without interrupting the proper functioning of Bitcoin.
This example makes it clear that Drivechains amplify the utility of the Bitcoin network. Just as we can implement ZCash, we can implement other chains. Like Monero or Ethereum, including the EVM and all the smart contract capacity of this network. All this, because the implementation would be a drivechain. Imagine the level of expansion that this technology can achieve.
As with the Lightning Network, the best thing of all is that we can go from a drivechain to Bitcoin again. In this case, the process to follow is the opposite, issuing the operation from the drivechain and then taking it to the Bitcoin mainchain. In the following video we can see how Paul Sztorc demonstrates this technology using ZCash.
Hashrate Escrow, a large multi-signature of miners
Now, moving from Bitcoin to the drivechain (or vice versa) is quite simple, since a messaging system is established using a new operations code known as OP_DRIVECHAIN. This Bitcoin Script code allows the Bitcoin network to send messages to the drivechains and for them to operate according to them. Of course, drivechains can also do the same, but the mechanism is a little different, as you will see below.
The important thing is that when an operation is carried out between a Bicoin and a drivechain, the OP_DRIVECHAIN comes into play. This is our messenger and allows interoperability between both networks and their consensus rule sets. This entire process is orchestrated by a mechanism called Hashrate Escrow.
Hashrate Escrow is a voting system that allows Bitcoin miners and drivechain operators to vote on the validity or invalidity of an operation. In reality, it is a huge multi-signature in which a minimum of 13,150 votes (out of a total of 26,300) are needed for an operation to be accepted or not. These signatures are what enable the operation of a drivechain.
An example of Hashrate Escrow
For example, if we execute a withdrawal from a drivechain to the Bitcoin mainchain, the operation is carried out following the consensus of the drivechain. This consensus may entail freezing the funds to be withdrawn and sending the corresponding transaction data to the Bitcoin blockchain miners, using OP_DRIVECHAIN, in order to enable withdrawal on the mainchain.
However, this is not immediate, since Hashrate Escrow comes into play here. For this to be approved, miners must vote whether the operation is valid or not, which requires 13,150 signatures, which are issued by the miner in each block that is added to the mainchain network. In this way, a withdrawal from a drivechain can take approximately six months.
Certainly, the latter doesn't sound very fun, much less usable. But everything has a solution: the generation of compensation markets. These would be services that can be created in both the mainchain and the drivechain, to bring both parties to an agreement in order to make exchanges.
For example, if Juan wants to leave a drivechain with €1000, but María wants to enter that drivechain with the same amount, exchange mechanisms can be created that allow Juan and María to exchange their respective currencies between them. Thus, Juan passes the €1000 to María on the drivechain and María, in turn, does the same on the mainchain. Thus, both operations would be carried out much faster and giving rise to the generation of new markets and applications dedicated to this type of services.
Blind Merge Mining, mining cryptocurrencies blindly
The second element that makes drivechains possible is Blind Merge Mining (BMM). The objective of this type of mining is to overcome two limitations associated with the well-known Merge Mining (e.g. that used by RSK or Namecoin). These limitations in question are:
Miners must run a full node of the drivechain (something that can lead to errors)
Miners receive payments using a currency other than Bitcoin (ex: in RSK, you receive RSK tokens).
However, in Blind Merge Mining, mainchain miners (in this case Bitcoin) can mine on a sidechain (drivechain) without needing to validate on the sidechain (without running software other than Bitcoin Core). .
Critical hash
To do this, drivechains introduce a new type of transaction in which the drivechain node requests the mainchain miner to include a “critical hash” in the coinbase of a mainchain block. The inclusion of the critical hash in the coinbase means a successful mining of the drivechain block. After mining a Blind Merge Mining block in the drivechain, the miner will be able to claim the reward corresponding to said drivechain, receiving said reward in the Bitcoin mainchain and subject to the Hashrate Escrow, so the miner must wait for the block to be completed. signed to be able to withdraw said reward in Bitcoin.
This is the mechanism that allows the OP_DRIVECHAIN to be able to interoperate between both chains, since no special nodes are executed for each drivechain, but rather their functionality at the level of block generation and consensus can be achieved using the same Bitcoin Core software (with the corresponding add-ons for it).
Drivechain potential and impact on the ecosystem
As you can see, drivechains seek to address key challenges facing Bitcoin, such as scalability, upgradability, and asset diversification. Some of these challenges include the need for broad consensus to introduce changes to Bitcoin. Such as Bitcoin's limitation to transfer only its native asset and the trade-off between scalability and decentralization.
Likewise, drivechains seek to unify existing functions in other chains within Bitcoin. For example, it would be possible to create a drivechain that emulates the functionality of Filecoin, in which the participants of that drivechain provide data storage services and receive corresponding payments for the service provided. Remembering again, it is tied to the BTC that is inside the drivechain.
Paul Sztorc continues to develop this curious design from his company LayerTwo Labs. Currently, there are already implementations for Ethereum and ZCash, which clearly shows the potential of this technology.
#Bitcoin #Ethereum #Zcash $BTC $FIL $ETH #Filecoin
Fuente: Observatorioblockchain.com
