Let’s talk about: Sidechain, Drivechain and Rootstock two-way hook design

In a recent technical paper, we analyzed different approaches to implementing a two-way peg. In this post, we will summarize what a two-way peg is and how it is implemented.

What is a 2-way peg (2WP)?

Two-way pegs (2WP) allow bitcoins to be transferred from the bitcoin blockchain to a secondary blockchain and vice versa. The “transfer” is actually an illusion: bitcoins are not actually transferred, but are temporarily locked on the bitcoin blockchain while an equal number of equivalent tokens are unlocked on the secondary blockchain. When the equal number of tokens are locked again on the secondary blockchain, the original bitcoins are unlocked. This is essentially what the two-way peg is supposed to do. The problem with this functionality is that it can only be achieved in theory when the secondary blockchain is finally settled. Therefore, any two-way peg system must make compromises and rely on assumptions that the participants involved in the two-way peg are honest. The most important assumptions are that the primary blockchain is uncensorable and that most bitcoin miners are honest. Another assumption that may be required is that most third parties who supervise the locked bitcoins are also honest. If these assumptions are not true, then bitcoins and equivalent secondary blockchain tokens can be unlocked at the same time, making malicious double spends feasible. Any two-way peg system must choose a measure that gives the parties assumed to be honest an economic and legal incentive to act in accordance with the rules. This includes analyzing the costs and consequences of attacks on the blockchain network by these key parties. The security of a two-way peg implementation depends on an incentive mechanism so that the key parties participating in the two-way peg system can actually perform the functions that the two-way peg is supposed to achieve.

So, what is not a two-way peg?

Bonded Escrow Contracts (BECs) are a method proposed by bitshares that, if adopted by other platforms, would allow bitcoin (or fiat currencies) to be traded on smart payment platforms with different tokens. To implement this method, issuers need to lock up a local currency bond in an amount equal to or generally greater than the amount of "bitcoins" they have created, and then they create IOUs and sell them on the platform. The bond amount is dynamically adjusted using the bitcoin price announced by querying the platform. Obviously, this does not meet the definition of a two-way peg, as new "bitcoins" are created and there is no equivalent locked bitcoin on the bitcoin blockchain. The security model of bonded escrow contracts is generally weaker than a two-way peg, as users must trust the announcement, which may not be very incentivized to be honest. There is also little or no economic incentive for stockbrokers to hold such large bonds in a native token with high variability.

Any two-way peg is just a voting system

To simplify the security model of any two-way peg, we can say that all two-way peg systems have a set of custodians who vote on when and where to unlock the bitcoins when the auxiliary chain does not reach final settlement. Voting can be done through digital signatures, hash power (proof of work), storage space (proof of capacity), cryptocurrency holdings (proof of stake), or any other consensus system that the blockchain has. We can change the weight of each party's vote, the number of voting parties, the conditions under which any party is allowed to vote, whether voting for more than one candidate is allowed, and so on, but what we cannot change is that the system is essentially a vote.

Two-way hook design

We will cover the most common two-way peg designs: sidechains, drivechains, multi-signature custody, and hybrid designs. To simplify the explanation, we will refer to bitcoins that have been transferred to the secondary blockchain as SE coins.

Single regulator

One possible option for implementing a two-way peg is to have an exchange oversee the locked bitcoins and unlocked equivalent tokens. The exchange would lock the bitcoins before unlocking the secondary tokens, either manually or through a software protocol. Here is a description of such a setup:

Multi-signature federation

A better way to achieve a two-way peg is to have a group of notaries that control multiple signatures, with the majority having the power to unlock the funds. This setup is better than a single controller of the funds, but can still lead to centralized control. To achieve true decentralization, notaries should be carefully selected so they are in different fields, different regions, and have good reputations and security. In addition, the number of notaries should never be too few, but also not too many. Here is a description of this setup:

Sidechain

In order to minimize the involvement of more third parties in a two-way peg, the prerequisite is that each blockchain executes the relevant verification protocol, and the protocol needs to be confirmed through consensus. Each blockchain must understand the consensus system of other blockchains, and can automatically release Bitcoin when receiving a lock transaction proof from other blockchains, as shown here:

However, there are several problems when using Bitcoin sidechains:

• Most public blockchains do not have final settlement. If the auxiliary blockchain does not have final settlement, then the Bitcoin blockchain cannot be sure whether the transaction on the auxiliary chain has been accepted by the auxiliary chain network (such as locking SE coins). All it can get is a probabilistic guarantee: the more proof of work confirming the transaction, the more likely it is to be accepted.

• Even if the auxiliary blockchain has final settlement, but there is no blockchain entanglement, then the auxiliary chain will face the same problems as the Bitcoin blockchain. If there is blockchain entanglement, the auxiliary blockchain's block rate will not be higher than Bitcoin's rate.

• Bitcoin sidechains require soft or hard forks to add complex new opcodes. Blockstream’s solution is not yet complete, and the proof-of-work confirmation of SPV (Simplified Payment Verification) has not been resolved.

Tangle blockchain

One way to overcome the lack of finality in a two-way peg is to tangle the blockchains so that, for example, the reversal of a locking transaction in the primary blockchain implies the reversal of an unlocking transaction in the secondary blockchain. There are several ways to tangle the blockchains:

1. Transactions from the secondary blockchain are embedded into transactions on the primary blockchain (e.g., embedded in an OP_RETURN payload, as is the case with Counterparty)

2. The blocks in the secondary blockchain have two parent blocks, one in the secondary blockchain and one in the primary blockchain. The secondary blockchain nodes verify whether the parent block in the primary blockchain belongs to the longest chain of Bitcoin.

3. Blocks on the secondary blockchain are anchored by cryptographically secured transactions on the primary blockchain.

The first two methods allow the auxiliary chain to verify the SPV proof without the need for the verifier to provide a confirmation header, because the auxiliary blockchain client also stores a copy of the Bitcoin blockchain (the entire blockchain in the first method, and only the header in the second method). The third method is not feasible.

The following diagram shows the transfer of Bitcoin to a secondary blockchain via a sidechain without additional confirmations (at the fastest speed possible with Bitcoin):

The Tangle blockchain has several disadvantages:

• It makes the rate at which the auxiliary chain creates new blocks slower than Bitcoin, limited by the Bitcoin blockchain, because there is uncertainty about the acceptance of the blockchain branch before anchoring. Should the anchored short chain be considered the longest chain instead of the longer unanchored chain?
• When embedding transactions from an auxiliary chain in a Bitcoin transaction, all users of the auxiliary blockchain need to process transactions from both chains simultaneously.
• The Tangle blockchain solves the problem of final settlement to some extent, but does not solve the problem of custody of Bitcoins locked on the main blockchain.

Drive chain

Drivechain gives custody of locked bitcoins to bitcoin miners, and allows bitcoin miners to vote on when to unlock bitcoins and where to send them. Miners vote using the bitcoin blockchain, and they vote at certain places within the block (such as coinbase). The more honest miners participate in drivechain, the greater the security. The following figure is a description of drivechain:

Hybrid

All designs proposed so far are symmetric: the method used to unlock SE coins is the same as the method used to unlock Bitcoin. However, the primary and secondary blockchains are fundamentally different: the primary blockchain is still issuing new native tokens while the secondary chain is not. This poses a huge security risk and shows that the symmetric two-way peg model may be incomplete. A hybrid two-way peg uses a different unlocking method for each side, such as using a sidechain on the secondary blockchain and a drivechain on the primary blockchain network.

RSK Case

The case of RSK, or Rootstock, is unique. RSK relies on a fundamental design choice: it must allow for merged mining with Bitcoin. Therefore, we must analyze the best design for this situation. We have to consider:

• Which party controls the locked bitcoins • What is the cost of attacking the blockchain network • What are the consequences of an attack • What are the incentives involved

If almost all Bitcoin miners participate in merged mining, we found that participants are most likely to remain honest when the regulator is a Bitcoin miner, but only when almost everyone participates. In the case of merged mining, both drivechains and sidechains rely entirely on the honesty of Bitcoin miners and both provide the same security. However, sidechains are much more complex to implement on the Bitcoin side, so for the Bitcoin side, RSK's best option is to use drivechains. On the RSK side, we can implement the sidechain approach. So at this point RSK's hybrid model can be defined as "drivechain/sidechain".

When the participation in merged-mining is low, “drivechain/sidechain” can only provide low security. Therefore, we propose a hybrid model where the security of locked bitcoins is based on the drivechain plus a set of notaries. Miners and notaries (with different weights) vote on which bitcoins to unlock. Notaries vote using their digital signatures, while miners vote by adding a special marker to their coinbase transaction. This is a trade-off between centralization and security. The final RSK two-way peg design can be defined as “(drivechain+notaries)/sidechain” (the former for the Bitcoin chain, the latter for the auxiliary chain). To set the weight of the vote, we use a dynamic approach based on the participation in merged-mining. Initially, only notaries vote in traditional multi-signature transactions. In the medium term, when the drivechain feature is added to Bitcoin, both notaries and miners will vote step by step. In the long term, when the participation in merged-mining reaches 90%, notaries will stop voting and only miners will continue to vote. This evolution is shown in the following figure:

In essence, we propose that the security of locked bitcoins relies on miners and a set of notaries, but the amount of power between these two voting parties is dynamically adjusted relative to the amount of merged-mining participation.

In a later post, we will show how the Drivechain+Notary design can be implemented on Bitcoin by executing a single opcode, OP_CHECK_VOTES_MULTISIG_VERIFY, which is conceptually simple to understand and program, and can be deployed on the network as a soft fork.

Original article: http://www.rootstock.io/blog/sidechains-drivechains-and-rsk-2-way-peg-design
Author: Rootstock
Translator: Peterhon
Editor: Kyle
Reward address: 16V6PW9wu1pFVb1R3LiGJKEwZAFHu9MMtA
Source (translation): 8btc Information (http://www.8btc.com/sidechains-drivechains-and-rsk-2-way-peg-design)