Vitalik: On the two-way bridging of eth1 and eth2

Original author | Vitalik Buterin

The purpose of this paper is to illustrate some of the challenges of establishing a two-way bridge between the eth1 chain and the eth2 chain (for example, support for bidirectional conversion of ETH) and how to implement it.

One-way bridging of eth1-> eth2 is already included in the Eth2 proposal, which is necessary to be able to mortgage ETH in Eth1 to eth2. This one-way bridging is achieved by the eth1 data voting mechanism [1]. Note that this mechanism assumes that most PoS certifiers are honest and that the PoW chain is not attacked (specifically, the rollback in the PoW chain will not exceed 5 hours). If any of these two assumptions fails, the two chains eth1 and eth2 will no longer "consistent" with each other. There is an implicit “social contract” at the outset, that is, if any kind of accident has remedial measures, it is likely to be remedied by the soft fork of the PoS chain ; however, it is also possible that if the PoW chain rolls back more than 5 Hours, then the community may reach a consensus that the attack chain is invalid. It should be noted that in either case, the PoS chain failure is unlikely to require a PoW chain for soft bifurcation.

And if we want the eth1 chain to know the state of eth2 (that is, to implement bidirectional bridging of the two chains , which is a prerequisite for allowing ETH to be transferred from the eth2 chain back to the eth1 chain), there are two ways to do this:

• One is a light client that makes a PoW link subject to a PoS chain ;
• The other is to make the PoS final state also finalize the PoW chain .

The first method requires the eth2 client to be implemented in eth1 (see the figure below) . This will require a webassembly or native support for BLS-12-381 verification, and don't expect this support to be implemented very quickly. In addition, this approach only provides security at the light client level .

• Which block is the first benefit to the blockchain?
• What are the points worth noting in the Jianan Zhizhi prospectus?
• Why is the blockchain that has been blushing overnight a representative of "an important breakthrough" and "a new round of information technology"?

The second method can be implemented by adding a mechanism that if a PoS block Bs voted via eth1_data contains a reference to the PoW block Bw , the Bw block is also visible when the block Bs is confirmed. To be confirmed (see the figure below). But this means that PoW miners (and clients) also want to run the eth2 implementation so they know which eth2 chains are confirmed.

The second method is more interesting because it provides a "native" version of the rollback limit for eth1 (commonly referred to as "finality gadget proposal"). Note that this is different from the first method because although it does make eth1's fork selection known to eth2, it does not immediately make eth1 aware of the state of eth2. For example, it is theoretically possible for two competing eth2 chains to identify the same eth1 block (which means that eth2 has failed, but in theory it is still possible). The more common case is the two blocks identified by the eth2 chain, one of which is the other of the sub-blocks, and both blocks support the same eth1 block, so some miners may know the two eth2 areas. The recent state of the block, while other miners do not know. This is not a problem for "eth2 as a final gadget", but it does mean that we need more underlying design to make eth1 aware of the block state of eth2 in order to allow ETH to be extracted from the Deposit Contract.

One possible solution is to simply create an eth2_data voting mechanism in eth1; essentially, it is the same mechanism that makes eth2 aware of the eth1 state. It can be combined with the above scheme to ensure consistency: eth1 miners will only vote for the eth2_data block, provided that only those blocks satisfy (i) have been confirmed, and (ii) the referenced eth1_data block is the miner The ancestors of the packaged eth1 block .

Challenge

Both methods require changes to the eth1 aspect . The eth2 roadmap has not changed on eth1 until the "final conversion" of eth1->eth2. And if eth2 is interrupted, both methods require eth1 to take urgent remedies. The second method will require all eth1 miners to also run the eth2 node . Therefore, although the two methods are absolutely feasible, they will not be implemented very quickly . However, as eth2 continues to run and proves its robustness, it is certainly a meaningful phase to implement this two-way bridge . To reduce risk, you can do something:

• There is a week of voting time when running eth2 votes on eth1 to allow time for manual intervention in the event of a problem;

• For the same reason, when eth1 knows the block that has been finalized in eth2 through the light client, the extraction of ETH will also have a delay of one week;
• This bridge is only turned on when the number of ETHs collateralized is sufficient (eg, greater than 5 million);
• Set the voting threshold to be higher than 50% (for example, 80%); and make the system more inclined to not include any eth2 blocks (unless these blocks have a strong consensus).

Original link:

Https://ethresear.ch/t/two-way-bridges-between-eth1-and-eth2/6286

Reference link:

[1]: https://github.com/ethereum/eth2.0-specs/blob/fffdb247081b184a0f6c31b52bd35eacf3970021/specs/core/0_beacon-chain.md

We will continue to update Blocking; if you have any questions or suggestions, please contact us!