What is a Drivechain, and why does it divide the Bitcoin community so much?

Understanding Sidechains Before Delving into DrivechainsBefore focusing on drivechains, one must first understand what sidechains are. Sidechains are blockchains that sit as a second-layer infrastructure above a main blockchain. They aim to create or enhance one or more features on the underlying chain.

Sidechains operate independently of the main chain, meaning they can technically function without impacting or being impacted by the parent blockchain. A sidechain allows the creation of features that are absent from the main chain or the improvement of existing ones.

However, similar to Polygon (POL) in relation to Ethereum (ETH), performance improvements often come at the expense of network decentralization.

Due to the nature of these sidechains, assets on them are often mere representations of assets on the main chain.

For example, to have Ether (ETH) on Polygon (POL), you need to use a bridge and trust a third party to hold the asset on the main chain to issue its representation on the secondary chain at a 1:1 ratio, called Wrapped Ether (WETH).

This wrapped asset can also be "unwrapped" to retrieve the native asset on the main chain, a process known as "two-way peg".

This two-way peg creates an almost essential bridge to the life of the sidechain. Without these representations, sidechains would have to create their own assets, which could hinder the adoption of this second layer, even when it could be genuinely useful.

To date, the most well-known sidechains on Bitcoin are Rootstock, Liquid, and Stacks.

Drivechains are sidechains where miners control the two-way peg. More precisely, the concept of Drivechain is often linked to merge mining, an incentive method designed to encourage miner participation.

Unlike sidechains like Liquid, where network security and transactions depend on a federation of entities, each owning a node and a voting right, Drivechains and their merge mining operate through Bitcoin's own consensus.

Merge mining allows miners to participate in both Bitcoin and Drivechain blockchain operations simultaneously. This enables Drivechains to take advantage of Bitcoin's decentralization right from the start.

When a miner successfully validates a block, they earn a voting right. When enough favorable votes are gathered, this allows the two-way peg to be confirmed.

The number of votes required to validate two-way peg depends on the required number of blocks. The more "for" votes there are, the more likely transactions will be confirmed.

Regardless of miner voting, the two-way peg mechanism can take place on a secondary market where cross-chain exchanges can occur more quickly through atomic swaps.

For instance, the issuance of stablecoins like USDT can only be done through Tether's services, which is the primary market. However, it's possible to acquire USDT on exchange platforms like Binance or Uniswap, which is the secondary market.

Currently, no Drivechain has been deployed on Bitcoin, and this is what BIP-300 and BIP-301 are trying to establish.

Proposed by Paul Sztorc in 2017, the Bitcoin Improvement Proposal 300 (BIP-300) aims to introduce the concept of "Hashrate Escrow."

The Hashrate Escrow is at the heart of how the two-way peg operates. It looks like a multisignature Bitcoin deposit address, but instead of being secured by multiple private keys, it is secured by hashing power over a defined period.

In the case of BIP-300, this is a defined period, ranging from a minimum of 13,150 block confirmations, approximately 3 months, to a maximum of 26,300 block confirmations, about 6 months. Thus, peg-in and peg-out requests will be executed if they gather at least 13,150 favorable votes.

This mechanism aims to make the two-way peg system more secure, but unfortunately, it's not that simple.

Despite its advantages, BIP-300 has disadvantages. To collect the fees generated by Drivechains, miners must be aware of its registry, which means running a node for each Drivechain.

This requirement could pose a significant financial burden for those who cannot afford the associated infrastructure costs.

This is where BIP-301 comes in to prevent any centralization of Drivechains consensus.

Also proposed by Paul Sztorc in 2017, Bitcoin Improvement Proposal 301 (BIP-301) aims to introduce the concept of "Blind Merge Mining."

Merge Mining allows miners to work on both the main Bitcoin blockchain and a sidechain without having to validate its rules. Merging Bitcoin network mining with Drivechains' consensus allows them to benefit from its security, ensuring decentralization and resistance to censorship.

Blind Merge Mining, on the other hand, is supposed to be a fairer form of Merge Mining. Blind Merge Mining is there to enable miners to secure Drivechains, thereby freeing them from the need to run a full node for each Drivechain to collect their fees.

Without Blind Merge Mining, miners would be unable to collect fees and would lose profitability. The mining industry is highly competitive, and increasing a miner's computational power reduces the profitability of their competitors.

Moreover, miners with the most resources could run nodes for each Drivechain, collect more fees, increase their income, which would make it easier for them to reinvest in more powerful infrastructure, thereby reducing the income of their competitors.

While the integration of Blind Merge Mining is not essential to the operation of Drivechains, BIP-301 is there to try to ensure a fairer operation of the network's consensus.

Unfortunately, the situation is much more complex. It is precisely because Blind Merge Mining does not convince the entire community of its effectiveness that the topic of Drivechains is a subject of debate within the Bitcoin community.

Indeed, in a form as presented by Paul Sztorc, Drivechains could undermine Bitcoin's consensus and weaken it.

Several years after the Blocksize War, the debate over Drivechains is rekindling discord within the Bitcoin community.

On one side, there are miners hoping to increase their income, supported by crypto enthusiasts who see Drivechains as a means to create smart contracts on Bitcoin and compete with the Ethereum (ETH) ecosystem.

On the other side, there are those questioning the relevance of such an update, especially worrying about the risk of damaging the current consensus of the Bitcoin network.

Indeed, a Drivechain could support many different features, each constituting a distinct shard of the Bitcoin blockchain and performing a specific task.

But how can we be sure that the Drivechains' format will be enough to attract users when sidechains like Liquid and Stacks are relatively inactive?

The major issue that Drivechains could create is that of "Miner Extracted Value".

Theo Pantamis, R&D engineer at LN Markets, discussed this in an episode of Space Kek in August 2023. We reached out to him, and he agreed to answer our questions on this subject:

"Miner Extracted Value or MEV is an economic advantage that a miner can obtain from their ability to resolve a double spend: they can choose which conflicting transactions (e.g., spending the same coins) to confirm.

Some protocols allow a large group of people to spend coins. When the miner of a block is among the people who can spend such coins, they can take advantage of the choice to create and favor their conflicting transactions and thus make a profit.

MEV quickly emerges from open protocols that require consensus and whose information is public if not taken into account in their design.

It is sometimes tolerated, as is the case, for example, for purging anchor outputs in the latest versions of Lightning Network payment channels. But in the overwhelming majority of cases, we seek to avoid it as much as possible.

Indeed, MEV diverts miners from their initial, idealized function: confirming valid Bitcoin transactions in order of decreasing fees.

MEV is problematic when the extracted value is high compared to the value derived from transaction fees. Because the gain becomes significant, miners who make the effort to seek and extract MEV are more profitable than those who do not and only order transactions in their block.

This naturally leads to a situation where the only remaining miners are those who chase MEV, as was the case for Ethereum before its transition to proof of stake.

This brings us to the problem of MEV in Drivechains. A sidechain is a widely open protocol, and the information is public. Miners are explicitly put in a privileged position because they can mine a sidechain and manage peg-outs while mining on Bitcoin to earn more income.

But for this, they must ensure that they comply with the sidechain's rules. We find ourselves in a situation where a miner must validate the rules of the sidechain in addition to Bitcoin's rules.

Blind Merge Mining was proposed in addition to Hashrate Escrow in response to this critique: it allows miners to collect MEV by leaving the responsibility of validating the sidechain's rules to other users. But it's just a way to move the problem; MEV is still there and must be collected by the miner to be profitable.

The prerequisite to obtain it is no longer to validate the rules of all Drivechains yourself (there can be up to 256 in the current version of the specifications) but to know and negotiate a competitive rate with people who could validate them for you or to be able to do it yourself (and it's always the most advantageous option).

The consequence of this is that it becomes more difficult to be a profitable miner, and proof of work is no longer the sole criterion; it's an additional strong incentive for mining centralization, in addition to those that may already naturally exist."

Theo Pantamis also warned us of a rarely mentioned risk within the community, that of slowing down block propagation between network nodes:

"In addition to changing miners' incentives, Bitcoin developers are trying to avoid MEV because it generates uncertainty about the content of the next block in some cases. But Drivechains exacerbate the problem due to Hashrate Escrow.

The security of the Bitcoin network relies on the short propagation time of a new block to all nodes compared to the average mining duration. This is why Bitcoin network blocks are small (to minimize propagation time) and infrequent (to maximize the average mining time).

Bitcoin developers have worked hard to reduce the block propagation time, and one of the main improvements comes from the fact that nodes expect to discover and validate only a very small part of the block's transactions, since they know and have already validated the vast majority of transactions that pay the most fees in the mempool.

Hashrate Escrow is managed through transactions that do not require a signature and that only a miner can perform, just like a coinbase transaction that rewards a block miner.

Such transactions cannot reasonably be broadcast and validated before the block is mined by the network (doing so would open a spam vector). Transactions related to Hashrate Escrow will necessarily be discovered and validated while the block propagates, which slows down this propagation and reduces network security.

We certainly have enough margin for the network to remain secure despite Drivechains, but there is no reason to be less severe on Drivechains than we already are regarding a potential increase in block size. Currently, I have not seen a quantification of the maximum impact of Drivechains on this essential data."

For many, the risk of weakening Bitcoin's consensus simply to create an ecosystem resembling Ethereum's is not worth taking, especially when infrastructures like RGB, BitVM, and Ark are in development.

Dr. Maxim Orlovsky, the main contributor to the development of RGB, argues that the structure of a blockchain is not meant to be scalable and that building one blockchain on top of another merely defers the problem.

While second-layer blockchains for Ethereum, such as Arbitrum (ARB) and Optimism (OP), are often more scalable than the main chain, they are also more centralized.

Drivechains are also more vulnerable to consensus attacks than the Bitcoin network.

Indeed, the only way to falsify transactions on the Bitcoin network would be if an actor or group of actors held more than 51% of the network's computing power.

If such a situation were to occur, a malicious actor could then censor new transactions, perform double spends of their transactions, and begin to go back in the blockchain to modify past transactions.

In the case of Drivechains, if a malicious actor managed to maintain 51% of the network's computing power for 3 to 6 months, the attacker could mine 51% of the new blocks, take control of Drivechains' votes, and retrieve all the funds held by the two-way pegs.

However, a 26% attack would be sufficient to undermine the vote and freeze the two-way peg. According to the BIP-300 voting system, a "yes" vote counts as +1, and a "no" vote counts as -1.

This means that even if 74% of miners vote "yes," the remaining 26% can vote "no," reducing the score to 48%, which is insufficient to confirm the two-way peg. It would then be necessary to wait for the next votes in the hope that the two-way peg would be confirmed.

Now that you have the information necessary to understand the debate on Bitcoin's Drivechains, what do you think?

Should the community take the risk of damaging Bitcoin's consensus to try to introduce new features that may not necessarily be desired?