On ethresear.ch, a forum dedicated to research efforts on the Ethereum blockchain, Ethereum Co-founder Vitalik Buterin put up a post to illustrate the challenges involved in the two-way bridging of eth1 and eth2 networks, along with possible implementation proposals.
According to Buterin, an eth1 to eth2 link already exists as part of the eth2 proposal, one that is necessary to allow deposits. This link is implemented using a mechanism that assumes that Proof-of-Stake (PoS) validators are an honest majority, and that the Proof-of-Work (PoW) chain will not get attacked.
In order to allow ETH to move from eth2 to eth1, the original chain needs to be aware of the new chain’s state. While one method of implementing this would be to have the PoW chain contain a light client of the PoS chain, another solution which the Ethereum Co-founder thought up was to finalize blocks on the PoW chain, when the block on the PoS chain which references them is finalized.
Essentially, if a PoS block Bs references a PoW block Bw, then Bw will be finalized along with Bs.
Buterin added that the former method of implementation wouldn’t be ideal because it would only provide a light-client layer of security, while requiring webassembly or native BLS-12-381 verification support, both of which are not expected to happen soon. However, while the second idea does make the eth1 fork choice aware of eth2, it does not immediately make eth1 aware of eth2’s state.
Buterin wrote,
“It’s theoretically possible for two competing eth2 chains to finalize the same eth1 block (this would imply eth2 has broken, but it is still theoretically possible). More commonly, there could be two eth2 finalized blocks where one is a child of the other, both of which support the same eth1 block, and some miners could be aware of the more recent of the two eth2 blocks and the others not aware.”
He added that this isn’t a problem for eth2 as finality gadget, adding that it did mean that more infrastructure to make eth1 explicitly aware of eth2 block state for the purposes of allowing withdrawals from the deposit contract, was needed.
Buterin went on to expand on a possible solution to this by implementing eth2’s voting mechanism inside eth1 to make it aware, essentially using the same method by which eth2 becomes aware of the eth1 chain state. But, while these proposals do paint a relatively organized and stable picture for the future of Ethereum, they do not come without issues.
“Both of these proposals would require emergency remedial action on the eth1 side if the eth2 side breaks. The latter proposal would require all eth1 miners to also be running an eth2 node. Hence, while both proposals are absolutely feasible, they are not something that should be implemented quickly.”
Further, Buterin expanded on some steps that could be taken to reduce risks such as running eth2 voting on eth1 with a one-week voting period to allow time for human intervention and setting the voting threshold higher than 50% to bias the system to not include any eth2 blocks, unless there is strong agreement.
Just yesterday, Buterin had also posted a migration plan from eth1 to eth2. Soon after its publication, Block.one CTO and EOS developer Daniel Larimer had tweeted that the plan would make all eth1 apps significantly less scalable by increasing gas costs and throttling contracts that access the same state multiple times per block. The Ethereum Co-founder responded, stating that this wouldn’t be the case.
Implementation of a simple counter that anyone can increment creates contention on the witness state such that two people cannot construct valid increment transactions in parallel.
— Daniel Larimer (@bytemaster7) October 10, 2019
