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 to this point, 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 a couple of chief design targets in thoughts, and whereas this isn’t in any respect complete, listed below are a couple of:
- Isolate every sidechain so any failure or drawback would solely have an effect on these utilizing it.
- Permit sidechains to be spun up while not having a brand new fork for each.
- Allow the switch of bitcoin out and in of a sidechain with a two-way peg.
- Permit totally free experimentation in design he hopes would out of date the necessity for altcoins.
There are two main elements of your entire design, which is why there are two separate BIPs. The primary is the peg mechanism (BIP300), which is what permits the two-way peg to perform. Sztorc designed one thing known as a hash charge 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 aim is to permit bitcoin miners to be the block producers at a consensus stage with out being required to validate the sidechain to take action. Each of those items collectively current a two-way peg mechanism and a approach for bitcoin miners to participate in mining the sidechains whereas trying 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 isn’t 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 knowledge of their coinbase output that features a distinctive identifier for that sidechain, a public key to make use of in deposit operations, model knowledge, human-readable descriptions, and hashes of the software program shopper and GitHub historical past of it (there is no such thing as a consensus enforcement right here, simply knowledge for people to reference).
When a miner proposes activating a brand new sidechain and together with all the required knowledge of their coinbase, it turns into a form of “miner signaling” interval concerning 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 an issue 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 consumer merely creates a two enter transaction with their very own enter and the UTXO equivalent to the sidechain stability with a single output assigning every little thing 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 think about 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, much like sighash, flags solely committing to a part of a transaction as an alternative of your entire factor. It doesn’t decide to the enter UTXO that represents funds locked in a drivechain or the output that returns every little thing 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 capable of 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 doable to have a couple of bundle for a single sidechain — if a miner chooses to vote “sure” (increase 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 may 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 purported to perform as a form of alarm for everybody {that a} miner validating these withdrawals (ensuring they’re legitimately owned cash on the sidechain being withdrawn) has observed one thing invalid taking place. Keep in mind, a key level of this design is that miners would not have to validate something on the sidechain, so until they select to anyway, many miners could also be upvoting bundles they don’t seem to be verifying. This alarm perform 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 may 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 right this moment. The bigger Bitcoin grows, the tougher such actions might be to coordinate.
When you recall from the article on spacechains, that design was primarily based 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 sort 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 particular person may be somebody who isn’t 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 extra consensus guidelines utilized to most of these transactions. First, a request transaction is invalid until there’s additionally an identical settle for output within the coinbase transaction of that block. That is to ensure miners can not acquire 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 simply 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 could be very easy: message header knowledge and the hash of the sidechain block. If a miner is working a drivechain node themselves, they’ll merely ignore request transactions and at all times embrace their very own settle for output of their coinbase to mine their very own sidechain blocks. Collectively, these two elements 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 concept 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 prone to preserve bidding up the charge they’re keen to pay miners of their request transaction till it represents nearly all of the charges they earn, with the non-miner solely retaining a small share of revenue and paying the remainder to miners.
That is the mechanics behind how drivechains perform. 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 submit by Shinobi. Opinions expressed are completely their very own and don’t essentially replicate these of BTC Inc or Bitcoin Journal.
