That is an opinion editorial by Shinobi, a self-taught educator within the Bitcoin house and tech-oriented Bitcoin podcast host.
This time I will be breaking down and discussing how drivechains work; they have been initially proposed in 2015. Out of all of the proposals mentioned thus far, drivechains are the oldest and essentially the most fleshed out when it comes to particular implementation particulars and design, documented in BIPs 300 and 301. Paul Sztorc, the creator of the idea, had just a few chief design objectives in thoughts, and whereas this isn’t in any respect complete, listed here are just a few:
- Isolate every sidechain so any failure or downside would solely have an effect on these utilizing it.
- Permit sidechains to be spun up without having a brand new fork for every one.
- Allow the switch of bitcoin out and in of a sidechain with a two-way peg.
- Permit without spending a dime experimentation in design he hopes would out of date the necessity for altcoins.
There are two major facets of all the design, which is why there are two separate BIPs. The primary is the peg mechanism (BIP300), which is what allows the two-way peg to operate. Sztorc designed one thing known as a hash price escrow, which, in essentially the most primary phrases, is permitting miners as an amorphous group to collectively custody the cash in all of the sidechains. The second is a “blind” merged mining scheme, the place the objective is to permit bitcoin miners to be the block producers at a consensus degree with out being required to validate the sidechain to take action. Each of those items collectively current a two-way peg mechanism and a method for bitcoin miners to participate in mining the sidechains whereas making an attempt to mitigate the centralization danger that it presents.
BIP300 specifies logic for the proposal of a brand new sidechain, the activation of a brand new sidechain, the proposal of a bundled set of withdrawals, the approval of such a set of withdrawals, the validation logic for precise withdrawal transactions and the validation for deposit transactions.
Activating a brand new sidechain beneath the drivechain proposal is similar to the method of a smooth fork activated via miner signaling. The foremost distinction is, in fact, it is not really a smooth fork — a single fork to activate the drivechain consensus guidelines permits miners to, at any time, sign to activate a brand new sidechain inside drivechain consensus guidelines. To suggest activating a brand new sidechain, a miner should place an OP_RETURN information of their coinbase output that features a distinctive identifier for that sidechain, a public key to make use of in deposit operations, model information, human-readable descriptions, and hashes of the software program consumer and GitHub historical past of it (there is no such thing as a consensus enforcement right here, simply information for people to reference).
When a miner proposes activating a brand new sidechain and together with all the required information of their coinbase, it turns into a kind of “miner signaling” interval relating to whether or not or to not create this new sidechain from the standpoint of mainchain consensus. A miner can use a particular format to incorporate a proposal of their coinbase outputs, and different miners can create one other output following a second format to sign for activation. A brand new sidechain proposal requires 90% of blocks in a problem interval to sign for activation to ensure that a brand new sidechain creation to be confirmed. This creates the peg mechanism to allow the sidechain, however the interplay between sidechain and mainchain is extra nuanced than that.
At this level, anybody can peg cash into the sidechain. To peg into the sidechain, a person merely creates a two enter transaction with their very own enter and the UTXO comparable to the sidechain stability with a single output assigning all the pieces to the sidechain. This ensures the sidechain solely ever has a single UTXO containing all of the funds locked in it. Withdrawals are dealt with by miner voting. The mainchain has no understanding of who owns what on the sidechain, and the mainchain will contemplate any withdrawal permitted by miners throughout the voting mechanism legitimate. Due to this, there’s a lengthy delay within the withdrawal course of. There are two phases to the method of withdrawing from a sidechain: a withdrawal proposal (bundle), after which the withdrawal voting part. Miners should create an OP_RETURN output of their coinbase transaction with a hash of the proposed withdrawal transaction to suggest a withdrawal. This hash, nonetheless, just like sighash, flags solely committing to a part of a transaction as an alternative of all the factor. It doesn’t decide to the enter UTXO that represents funds locked in a drivechain or the output that returns all the pieces not being withdrawn to a particular sidechain UTXO. It is because any deposits into the drivechain would create a brand new UTXO, and thus invalidate the dedication to the withdrawal transaction when individuals went to validate it.
From right here, the miner voting interval on the withdrawal proposal begins. After a bundle has been proposed, miners are in a position to vote on whether or not to approve them or not. Every block that’s mined permits that miner to increment an approval counter, up or down by one, or two to abstain from doing something. There are some particular limitations along with this, as a result of it’s attainable to have a couple of bundle for a single sidechain — if a miner chooses to vote “sure” (elevate the counter by one) for a withdrawal bundle for a sidechain they should vote “no” (decrease the counter by one) for each different bundle related to that particular sidechain.
That is to ensure that there are not any “double withdrawals,” the place somebody has an output in a number of bundles that will pay them out extra bitcoin on the mainchain than they’re owed.
On the opposite facet, miners are additionally allowed to vote no for each single proposed bundle. That is presupposed to operate as a kind of alarm for everybody {that a} miner validating these withdrawals (ensuring they’re legitimately owned cash on the sidechain being withdrawn) has seen one thing invalid taking place. Keep in mind, a key level of this design is that miners don’t have to validate something on the sidechain, so except they select to anyway, many miners could also be upvoting bundles they don’t seem to be verifying. This alarm operate is designed for them to be alerted that they need to confirm the bundles to make sure a fraudulent withdrawal is not taking place.
As soon as a bundle has reached the required threshold (13,150 blocks, or roughly 90 days), the transaction really processing the withdrawal turns into legitimate and could be confirmed. However what do individuals do if miners approve a fraudulent withdrawal that steals cash from the sidechain? Sztorc’s proposal is to interact in a user-ctivated smooth fork (UASF) to invalidate the invalid peg-out transaction. This presents an enormous danger when it comes to consensus to the mainchain. The UASF in 2017 was a high-risk transfer that solely barely succeeded and Bitcoin was a lot smaller than it’s at present. The bigger Bitcoin grows, the harder such actions shall be to coordinate.
If you happen to recall from the article on spacechains, that design was based mostly round blind merged mining (BMM). Ruben Somsen’s BMM design is definitely the second variant of that, the primary being Sztorc’s design as specified by BIP301. The BMM spec in drivechains consists of two messages: a request message and an settle for message. Each are coordinated respectively via a particular transaction kind on the mainchain and particular output in a miner’s coinbase transaction.
The request transaction is constructed by whoever is creating sidechain blocks. The entire level of BMM is that this individual could be somebody who will not be mining, so the request transaction is there to permit them to pay miners to substantiate their proposed sidechain block. The sidechain block proposal constructs a transaction that features the hash of the sidechain block, the ID assigned to the sidechain when it was created and the final 4 bytes of the earlier mainchain block header. There are three further consensus guidelines utilized to a lot of these transactions. First, a request transaction is invalid except there’s additionally an identical settle for output within the coinbase transaction of that block. That is to ensure miners can’t accumulate a charge from the request with out additionally accepting and mining the sidechain block. Second, for every sidechain just one request transaction is allowed to be included in a mainchain block. That is to make sure just one block from any sidechain can really be mined per mainchain block. Lastly, the final 4 bytes of the earlier mainchain block should match. This ensures {that a} request is just legitimate to be mined within the subsequent block, and such transactions can’t be mined later and steal cash from a sidechain block proposer after another person’s block has been mined.
The settle for output may be very easy: message header information and the hash of the sidechain block. If a miner is working a drivechain node themselves, they’ll merely ignore request transactions and all the time embrace their very own settle for output of their coinbase to mine their very own sidechain blocks. Collectively, these two facets permit miners to both function a sidechain node themselves, or one other non-miner to do it and pay the miner to mine their blocks. The thought is that, if miners themselves don’t run the sidechains and eat the additional validation prices, then another person can do it for them. If there’s competitors in non-miners attempting to earn charges on the sidechain, they’re more likely to hold bidding up the charge they’re keen to pay miners of their request transaction till it represents the vast majority of the charges they earn, with the non-miner solely conserving a small proportion of revenue and paying the remainder to miners.
That is the mechanics behind how drivechains operate. Subsequent up, federated sidechains, after which, after that, a breakdown of all of the negatives and disadvantages every design can have.
It is a visitor publish by Shinobi. Opinions expressed are fully their very own and don’t essentially replicate these of BTC Inc or Bitcoin Journal.
