This is an opinion editorial by Shinobi, a self-taught educator in the Bitcoin space and tech-oriented Bitcoin podcast host.
This time I’m going to be breaking down and discussing how drivechains work; they were initially proposed in 2015. Out of all the proposals discussed so far, drivechains are the oldest and the most fleshed out in terms of specific implementation details and design, documented in BIPs 300 and 301. Paul Sztorc, the creator of the concept, had a few chief design goals in mind, and while this is not at all comprehensive, here are a few:
- Isolate each sidechain so any failure or problem would only affect those using it.
- Allow sidechains to be spun up without needing a new fork for each one.
- Enable the transfer of bitcoin in and out of a sidechain with a two-way peg.
- Allow for free experimentation in design he hopes would obsolete the need for altcoins.
There are two primary aspects of the entire design, which is why there are two separate BIPs. The first is the peg mechanism (BIP300), which is what enables the two-way peg to function. Sztorc designed something called a hash rate escrow, which, in the most basic terms, is allowing miners as an amorphous group to collectively custody the coins in all the sidechains. The second is a “blind” merged mining scheme, where the goal is to allow bitcoin miners to be the block producers at a consensus level without being required to validate the sidechain to do so. Both of these pieces together present a two-way peg mechanism and a way for bitcoin miners to take part in mining the sidechains while attempting to mitigate the centralization risk that it presents.
BIP300 specifies logic for the proposal of a new sidechain, the activation of a new sidechain, the proposal of a bundled set of withdrawals, the approval of such a set of withdrawals, the validation logic for actual withdrawal transactions and the validation for deposit transactions.
Activating a new sidechain under the drivechain proposal is very similar to the process of a soft fork activated through miner signaling. The major difference is, of course, it’s not actually a soft fork — a single fork to activate the drivechain consensus rules allows miners to, at any time, signal to activate a new sidechain within drivechain consensus rules. To propose activating a new sidechain, a miner must place an OP_RETURN data in their coinbase output that includes a unique identifier for that sidechain, a public key to use in deposit operations, version data, human-readable descriptions, and hashes of the software client and GitHub history of it (there is no consensus enforcement here, just data for humans to reference).
When a miner proposes activating a new sidechain and including all the necessary data in their coinbase, it becomes a sort of “miner signaling” period regarding whether or not to create this new sidechain from the point of view of mainchain consensus. A miner can use a special format to include a proposal in their coinbase outputs, and other miners can create another output following a second format to signal for activation. A new sidechain proposal requires 90% of blocks in a difficulty period to signal for activation in order for a new sidechain creation to be confirmed. This creates the peg mechanism to enable the sidechain, but the interaction between sidechain and mainchain is more nuanced than that.
At this point, anyone can peg coins into the sidechain. To peg into the sidechain, a user simply creates a two input transaction with their own input and the UTXO corresponding to the sidechain balance with a single output assigning everything to the sidechain. This guarantees the sidechain only ever has a single UTXO containing all the funds locked in it. Withdrawals are handled by miner voting. The mainchain has no understanding of who owns what on the sidechain, and the mainchain will consider any withdrawal approved by miners within the voting mechanism valid. Because of this, there is a long delay in the withdrawal process. There are two phases to the process of withdrawing from a sidechain: a withdrawal proposal (bundle), and then the withdrawal voting phase. Miners must create an OP_RETURN output in their coinbase transaction with a hash of the proposed withdrawal transaction to propose a withdrawal. This hash, however, similar to sighash, flags only committing to part of a transaction instead of the entire thing. It does not commit to the input UTXO that represents funds locked in a drivechain or the output that returns everything not being withdrawn to a special sidechain UTXO. This is because any deposits into the drivechain would create a new UTXO, and thus invalidate the commitment to the withdrawal transaction when people went to validate it.
From here, the miner voting period on the withdrawal proposal begins. After a bundle has been proposed, miners are able to vote on whether to approve them or not. Each block that is mined allows that miner to increment an approval counter, up or down by one, or two to abstain from doing anything. There are some specific limitations in addition to this, because it is possible to have more than one bundle for a single sidechain — if a miner chooses to vote “yes” (raise the counter by one) for a withdrawal bundle for a sidechain they must vote “no” (lower the counter by one) for every other bundle associated with that specific sidechain.
This is to guarantee that there are no “double withdrawals,” where someone has an output in multiple bundles that would pay them out more bitcoin on the mainchain than they are owed.
On the other side, miners are also allowed to vote no for every single proposed bundle. This is supposed to function as a sort of alarm for everyone that a miner validating these withdrawals (making sure they are legitimately owned coins on the sidechain being withdrawn) has noticed something invalid happening. Remember, a key point of this design is that miners do not have to validate anything on the sidechain, so unless they choose to anyway, many miners may be upvoting bundles they are not verifying. This alarm function is designed for them to be alerted that they should verify the bundles to ensure a fraudulent withdrawal isn’t happening.
Once a bundle has reached the required threshold (13,150 blocks, or roughly 90 days), the transaction actually processing the withdrawal becomes valid and can be confirmed. But what do people do if miners approve a fraudulent withdrawal that steals money from the sidechain? Sztorc’s proposal is to engage in a user-ctivated soft fork (UASF) to invalidate the invalid peg-out transaction. This presents a huge risk in terms of consensus to the mainchain. The UASF in 2017 was a high-risk move that only barely succeeded and Bitcoin was much smaller than it is today. The larger Bitcoin grows, the more difficult such actions will be to coordinate.
If you recall from the article on spacechains, that design was based around blind merged mining (BMM). Ruben Somsen’s BMM design is actually the second variant of that, the first being Sztorc’s design as laid out in BIP301. The BMM spec in drivechains is composed of two messages: a request message and an accept message. Both are coordinated respectively through a special transaction type on the mainchain and special output in a miner’s coinbase transaction.
The request transaction is constructed by whoever is creating sidechain blocks. The whole point of BMM is that this person can be someone who is not mining, so the request transaction is there to allow them to pay miners to confirm their proposed sidechain block. The sidechain block proposal constructs a transaction that includes the hash of the sidechain block, the ID assigned to the sidechain when it was created and the last four bytes of the previous mainchain block header. There are three additional consensus rules applied to these types of transactions. First, a request transaction is invalid unless there is also a matching accept output in the coinbase transaction of that block. This is to guarantee miners cannot collect a fee from the request without also accepting and mining the sidechain block. Second, for each sidechain only one request transaction is allowed to be included in a mainchain block. This is to ensure only one block from any sidechain can actually be mined per mainchain block. Lastly, the last four bytes of the previous mainchain block must match. This ensures that a request is only valid to be mined in the next block, and such transactions cannot be mined later and steal money from a sidechain block proposer after someone else’s block has been mined.
The accept output is very simple: message header data and the hash of the sidechain block. If a miner is running a drivechain node themselves, they can simply ignore request transactions and always include their own accept output in their coinbase to mine their own sidechain blocks. Together, these two aspects allow miners to either operate a sidechain node themselves, or another non-miner to do it and pay the miner to mine their blocks. The idea is that, if miners themselves do not run the sidechains and eat the extra validation costs, then someone else can do it for them. If there is competition in non-miners trying to earn fees on the sidechain, they are likely to keep bidding up the fee they are willing to pay miners in their request transaction until it represents the majority of the fees they earn, with the non-miner only keeping a small percentage of profit and paying the rest to miners.
That’s the mechanics behind how drivechains function. Next up, federated sidechains, and then, after that, a breakdown of all the negatives and downsides each design can have.
This is a guest post by Shinobi. Opinions expressed are entirely their own and do not necessarily reflect those of BTC Inc or Bitcoin Magazine.