The ideas in this thread are referenced by a tweet of pics from a talk by @djrtwo, which says that a two-way bridge would encumber eth2 and eth1 protocol development.
But these ideas can also be used to enable a two-way bridge that is entirely at the application-layer, so eth2 and eth1 protocol development can continue unencumbered.
I tried filling in some detail to see at which point the bridge becomes encumbering.
option A: implement an eth2 light client as an EVM contract on eth1.
- to update the light client state, users must submit transactions to the contract (like the old btcrelay contract)
- no action or HF’s required for eth1 (except to add a BLS12-381 precompile; alternatively, add support for fast 384-bit or 512-bit multiplication to EVM)
option B: add an “eth2 bridge” to eth1 implemented natively in clients
- e.g. a new value is added to EVM: either as a field in the block header, or as the value returned by a new opcode
ETH2_LAST_FINALIZED_BEACONBLOCKHASH. All eth1 miners run eth2 light clients to support this opcode. The valueis not entirely deterministic, as two blocks with different values may both be considered valid (like the Timestamp field in a block). - HF is required on eth1
- effectively the same as option B, but better DevEx (a cheap and reliable opcode to read the relayed Eth2 finalized beacon block hash, instead of a contract which needs users to pay gas to update the relayed state)
The PoS chain already implicitly finalizes the PoW chain, by using eth1 block hashes for the eth1_data (to read the deposit contract). It would require an Eth1 soft fork to get miners to respect the PoS finality: the majority of miners can simply adopt a fork choice rule prohibiting reorgs at depths beyond the block finalized on the PoS chain.
To support a bridge, eth2 needs some way of transferring bETH between accounts (whether validator accounts or EE’s), and some way of reading eth1 contract state. Reading eth1 contract state could be done in eth2 at the protocol-level, like the deposit_count value read from the eth1 deposit contract. Or it could be done at the application-level, e.g. with Ewasm execution an eth1 light client could be implemented in Ewasm and state could be read from any contract on the eth1 chain by users submitting proof data in blocks (in beacon blocks or shard blocks).
At this point, we have all the features needed to implement a “two-way bridge”, which would enable two-way conversion between ETH on the eth1 chain and bETH on the eth2 chain.
What’s left unclarified is how the bridge would be implemented on Eth1. Here’s two possibilities:
-
protocol-layer bridge:
- the “bridge contract” is a contract on eth1 (a beacon chain block hash relay contract). possibly a “system contract” resembling the blockhash refactoring proposal
- bridge contract could be implemented using either option A (with relay logic implemented in EVM) or option B (relay logic implemented in eth1 clients, simplified usage as an EVM opcode
ETH2_LAST_FINALIZED_BEACONBLOCKHASH) - the bridge contract wraps bETH held on the eth2 chain as wbETH (wrapped-beacon-ETH). wbETH can be burned on the eth1 side to redeem bETH on eth2. Or it could issue new wbETH if a proof-of-burn on the eth2 side is provided
- an Eth1 HF is needed to make ETH and wbETH equivalent in the Eth1 protocol
-
application-layer bridge:
- the “bridge contract” is a contract on eth1 (a beacon chain block hash relay contract). possibly a “system contract” resembling the blockhash refactoring proposal
- bridge contract could be implemented using either option A (with relay logic implemented in EVM) or option B (relay logic implemented in eth1 clients, simplified usage as an EVM opcode
ETH2_LAST_FINALIZED_BEACONBLOCKHASH) - the bridge contract wraps bETH held on the eth2 chain as wbETH (wrapped-beacon-ETH). wbETH can be burned on the eth1 side to redeem bETH on eth2.
- users could do two-way conversion of wbETH back into ETH by trading with someone who wants to convert ETH into wbETH
Notice that for the most part, a protocol-layer bridge and an application-layer bridge are implemented in the same way. The difference is that a protocol-layer bridge requires an Eth1 HF to make ETH and wbETH equivalent.