Sidechains, Drivechains, and RSK 2-Way peg Design

A 2-way peg (2WP) allows the transfer of bitcoins from the Bitcoin blockchain to a Secondary blockchain and vice-versa. The “transfer” is in fact an illusion: bitcoins are not transferred, but temporarily locked on the Bitcoin blockchain while the same amount of equivalent tokens are unlocked in a secondary blockchain. The original bitcoins can be unlocked when the equivalent amount of tokens on the second blockchain are locked again (in the secondary blockchain). This is essentially the 2WP promise. The problem with this promise is that can only be theoretically realized if the secondary blockchain has settlement finality. Therefore any 2WP system must do compromises and rely on assumptions about the honesty of the actors involved in the 2WP. The most important assumptions are that the primary blockchain is censorship resistant and that the majority of Bitcoin miners are honest. Another required assumption may be that the majority of third parties that will hold custody of locked bitcoins is also honest. If these assumptions do not hold, then bitcoins and their equivalent secondary blockchain tokens could be both unlocked at the same time, thus allowing a malicious double-spend. Any 2WP system must choose an implementation so that the parties being assumed to behave honestly have economic and legal incentives to do so. This involves analysing the of cost of an attack by these critical parties and consequences of an attack. The security of a 2WP implementation depends on the incentives to enforce the 2WP promise by the critical parties taking part of the 2WP system.

What is not a 2WP

A Bonded Escrow Contract (BEC) is a method proposed by bitshares and then adopted by other platforms to allow Bitcoins (or fiat currencies) to be traded on a smart payment platform having a different native token. To allow it, a set of issuers lock bonds in the native currency of an amount equivalent or generally higher than the amount of “bitcoins” they create, then they create IOUs and sell them on the platform. The bond amounts are dynamically adjusted using the price of the btc by querying platform oracles. Clearly, this is not a 2WP by definition because new “bitcoins” are created, and there are no equivalent bitcoins locked on the Bitcoin blockchain. The security model of the BEC is generally weaker than of a 2WP, since users must trust the oracles which may not have high incentives to stay honest. Also there is little or no economic incentive for the market makers to hold such huge bonds in a highly volatile native token.

Any 2WP is just a voting system

When the secondary chain does not have settlement finality, we can simplify the security model of any 2WP by showing that any 2WP system is equivalent to having a group of custodians cast votes on when to unlock bitcoins and where to send the unlocked bitcoins to. The votes can be cast by digital signatures, hashing power (PoW), memory space (Proof-of-space), or cryptocurrency holdings (Proof-of-Stake), or whatever consensus system the blockchains have. We can change the weight of each party vote, the number of parties that vote, the conditions in which a party is allowed to vote, allowing or not voting for more than one candidate, and so on, but we cannot change that the system is essentially a poll.

We’ll present the most common 2WP designs: sidechain, drivechain and multi-sig custody and hybrid designs. To simplify the explanations, we’ll call secoins to the bitcoins that have been transferred to the secondary blockchain.

Single Custodian

One possible option to implement the 2WP is having an exchange holding custody of the locked bitcoins and holding custody of unlocked equivalent tokens. The exchange would manually enforce the promise of locking bitcoins before unlocking secondary tokens either manually or by means of a protocol executed in software. This setup is depicted here:

Multi-sig federation

A better way to implement a 2WP is having an group of notaries control of a multi-signature, where the majority of them has to approve the unlock of funds. This setup is better than having a single controller of the funds, but may still centralize control. To achieve true decentralization, the notaries should be carefully selected so they are located in different jurisdictions, different geographies, and each having good reputation and good security. Also they must not be too few, nor too many. This setup is depicted here:

Sidechains

Trying not to involve more third parties in the 2WP, each blockchain can enforce the premise by implementing a protocol validated by consensus. Each blockchain must understand the consensus system of other blockchain and can therefore automatically release bitcoins when given proof of a lock transaction in the other blockchain, as depicted here:

However, there are several problems when using sidechains for Bitcoin:

• Most public blockchains do not have settlement finality. If the secondary blockchain does not have it, then the Bitcoin blockchain can never be sure if a secondary transaction has been accepted by the secondary network (e.g. locking secoins). All it can get is a probabilistic assurance: more proof-of-work confirming a transaction means it is more probable it has been accepted.
• Even if the secondary blockchain has settlement finality, without blockchain entanglement (see next section) then the secondary blockchain suffers the same problem about the Bitcoin blockchain. If there is entanglement, then the secondary blockchain block rate cannot be higher than Bitcoin’s rate.
• Sidechains in Bitcoin requires a soft-fork or hard-fork to add new complex opcodes. Blockstream proposal is currently incomplete and does not address the validation of proof-of-work of SPV proofs.

Entangled Blockchains

One way to overcome the lack of transaction finality for the 2WP is to entangle both blockchains such as the reversal of the lock transaction in the primary blockchain implies the reversal of the unlock transaction in the secondary blockchain. There are several ways to entangle blockchains:

1. The transactions of the secondary blockchain are embedded in transactions of the primary blockchain (e.g. in OP_RETURN payload, such as in Counterparty)
2. Secondary blocks have two parents, one in the secondary blockchain and one in the primary blockchain. Secondary blockchain nodes verify that primary parents belong to the same Bitcoin best chain.
3. Secondary blocks are anchored by cryptographic commitments in primary blockchain transactions.

The first two options allow the secondary chain to verify an SPV proof without requiring the prover to provide confirmation headers because the secondary blockchain client also maintains a copy of the Bitcoin blockchain (a full blockchain in the first option, and only the headers in the second option). The third option does not allow this.

The following diagram shows a sidechain transferring bitcoins into the secondary blockchain without additional confirmations (at the fastest possible Bitcoin speed):

Entangling blockchains have several drawbacks:

• It prevents the secondary chain from creating blocks at a higher rate that Bitcoin because of the uncertainty in the acceptance of blockchain branches before anchoring. Should a short anchored branch be taken as the best chain over a longer non-anchored chain?
• When embedding secondary transactions in Bitcoin transactions, all users of the secondary blockchain need to process the transactions of both chains.
• Entangling solves one direction of the problem of settlement finality, but does not solve the problem of custody of the primary blockchain locked bitcoins.

Drivechains

A drivechain gives custody of the locked btc to the Bitcoins miners, and allows Bitcoin miners to vote when to unlock bitcoins and where to send them. The miners vote using the bitcoin blockchain, and votes are cast in some part of the block (e.g. the coinbase). The greater the participation of honest miners in the drivechain, the more secure it is. The following diagram depicts a drivechain:

Hybrid Models

All the designs presented so far are symmetric: the method used to unlock secoins is the same used to unlock bitcoins. But the primary and secondary blockchains are essentially different: the primary issues new native tokens and the secondary does not. This has huge consequences in terms of security and it suggests that a symmetric 2WP model may not be adequate. A hybrid 2WP is a 2WP using a different unlocking method for each side, such as using a sidechain on the secondary blockchain and using a drivechain on the primary network.

The case of RSK is special. RSK relies on a fundamental design choice: it must allow merge-mining with Bitcoin. Therefore we must analyze which is the best design for such case. We take into consideration:

• which parties control the locked bitcoins
• what is the cost of an attack
• what are the consequences of an attack
• what incentives are at play

If the involvement of Bitcoin miners in merge-mining is almost total, we found that the actors that have the highest incentive to be honest when being custodial are the Bitcoin miners, but only when almost all of them are engaged. In case of merge-mining, both drivechains and sidechains rely entirely on the honesty of Bitcoin miners, and both offer the same security. However sidechains are much more complex to implement on the Bitcoin side, so for the Bitcoin side, the best choice for RSK is using a drivechain. On the RSK side, we implement a sidechain. So the RSK hybrid model at this point could be defined as Drivechain/Sidechain.

When the merge-mining engagement is low, drivechain/sidechain offer little security. Therefore, we propose a hybrid model where the security of locked bitcoins is based on a drivechain plus a set of notaries. The miners and the notaries vote (with different weights) on which bitcoins to unlock. Notaries vote with their digital signature, while miners vote by adding a special tag in their coinbase transactions. This is a trade-off between centralization and security. The final RSK 2WP design can be defined as Drivechain+Notaries/Sidechain. To set the votes weights, we use of a dynamic method based on the merge-mining engagement. At first, only the notaries will vote, in a classical multi-sig transaction. In the mid-term, when drivechains capabilities are added to Bitcoin, both the notaries and the miners will vote along each other. In the long-term, when the merge-mining engagement reaches 90%, the notaries will cease to vote, and only the miners will. This evolution is depicted in the following figure:

In essence we propose that the security of the locked bitcoins rests on the miners and a set of notaries, but the amount of power between these two groups is dynamically adjusted in relation to the amount of merge-mining engagement.

In the following posts we’ll show that the drivechain+notaries design can be realized on Bitcoin by implementing a single opcode OP_CHECK_VOTES_MULTISIG_VERIFY which is conceptually and programmatically simple, and can be deployed as a soft-fork.