Work to natively integrate Eth1 into Eth2

TLDR: We outline considerations for a native integration of Eth1 into an Eth2 shard.

Single shard

Below are possible work items to “premine” the Eth1 consensus and state into a shard.

  1. BLS vs ECDSA: Add BLS12-381 opcode or precompile to EVM to verify signatures of Eth2 consensus objects.
  2. Keccak256 vs SHA256: Reduce gas cost of calls to SHA256 precompile (and possibly to all precompile calls) to facilitate checking Eth2 consensus Merkle paths.
  3. roots: Add EVM opcode to read beacon chain block roots (alternatively, an opcode to read state roots). This could be useful, for example, to prove that a given Eth1 block has been finalized without adding an ad-hoc finality opcode.
  4. SSZ vs RLP: Add support for SSZ and consider deprecating RLP.
  5. sparse tree: Consider removing the hexary Patricia tree in favour of a sparse binary tree.
  6. Casper FFG: As part of an intermediate hybrid PoW/PoS step, update PoW fork choice rule to respect beacon chain finality.
  7. light clients: Replace PoW-based Eth1 light clients with PoS-based beacon chain light clients.
  8. randomness: Find a migration path for dApps that rely on the nonce header field for randomness. RANDAO only provides a decent random number every epoch, not every block as with PoW.
  9. Eth1 headers: Consider redefining Eth1 header fields which may no longer be relevant (e.g. ommersHash, difficulty, beneficiary, nonce, gasLimit) and make sure no significant dApps break as a result.
  10. incentivisation: Remove PoW rewards.
  11. difficulty bomb: Remove difficulty bomb.
  12. statelessness: Build statelessness support into Eth1 clients (Geth, Parity, etc.). Also implement logic to produce Eth2-compliant shard blocks.
  13. new liveness invariant: Make sure that there are no significant dApps that break when moving to regular 3-second slots (as opposed to the current Poisson distribution for blocks, with a ~15sec average block time).
  14. libp2p vs devp2p: Migrate Eth1 clients from devp2p to libp2p.
  15. Eth1 gas limit: Consider removing the Eth1 gas limit to avoid having two gas limits (Eth1 gas limit under Eth2 gas limit).
  16. Eth2 gas limit: Make sure that 8,000,000 “Eth1 EVM gas” when translated to “Eth2 WASM gas” fits within the Eth2 gas limit. Significantly reducing the effective limit below 8,000,000 gas may cause unacceptable congestion. Check that the Eth2 gas mechanism (which would not have miner voting) is otherwise acceptable for Eth1.
  17. WASMify Eth1 consensus: Formalise the Eth1 state transition function—including all precompiles—as WASM code. Split the WASM code into small chunks that fit within the Eth2 code limit (possibly 16kB per code chunk). This formalisation risks introducing consensus bugs on a $20B+ network so extensive fuzzing and formal verification may be required. We also want the WASM formalisation to be consistent with the wider WASM-for-blockchains standardisation effort.
  18. premine load imbalance: Consider the negative consequences of the load asymmetry from premining the Eth1 state into a single shard with the other 1023 shards empty.
  19. hard forks: Negotiate a timely hard fork schedule with the existing Eth1 ecosystem.
  20. Eth2 consensus pollution: Consider disruptions to Eth2 whenever Eth1 will need to hark fork. Indeed, the Eth1 consensus would likely have “too big to fail” status within the Eth2 ecosystem (inconsistent with the expectation that execution engines are application-layer, not consensus-layer) which imposes an Eth2 hard fork for every Eth1 hard fork.

All shards

Below are further considerations to put Eth1 consensus logic on all shards.

  1. state growth: Make sure that the ecosystem can handle 1024 privileged copies of the Eth1 consensus. In particular, the current no-rent approach may make the maintenance costs of tracking all shards too high for services such as exchanges and Etherscan.
  2. shard number: Consider adding a shard number field in Eth1 headers to easily differentiate Eth1 execution engines running on different shards.
  3. yanking: Add support for contracts to move between shards and make sure that the asynchronisity introduced does not break existing Eth1 dApps.

Conclusion

Safely integrating Eth1 into Eth2 is a significant engineering and governance effort. It seems doable on a long-enough (likely multi-year) timescale. The native integration should be compared to significantly cheaper medium-term alternatives. For example, a two-way bridge between Eth1 and Eth2 can be built using light clients.

6 Likes

A great start on a proposal.
I personally am against embedding Eth1.
Doing so has several issues you’ve noted (keeping them in sync with hardforks etc) that would slow down the evolution of Eth2.
It seems like running Eth2 as a “sidechain” (I’m using the wrong term there) is enough interop between 1 & 2. We really do want Eth1 to go away or be frozen at some point. Embedding Eth1 into Eth2 will keep people using for longer which is a bad idea in my opinion.
The biggest problem I see is moving to a storage rent model in the future with Eth1.

  1. BLS vs ECDSA : Add BLS12-381 opcode or precompile to EVM to verify signatures of Eth2 consensus objects.

Why is this technically needed for eth1 integration? I can see how it’s useful for the eth2-in-eth1 light client, but if eth1 is part of eth2 then what is the benefit?

  1. Keccak256 vs SHA256 : Reduce gas cost of calls to SHA256 precompile (and possibly to all precompile calls) to facilitate checking Eth2 consensus Merkle paths.

Seems reasonable regardless of the upgrade path.

  1. roots : Add EVM opcode to read beacon chain block roots (alternatively, an opcode to read state roots). This could be useful, for example, to prove that a given Eth1 block has been finalized without adding an ad-hoc finality opcode.

I expect the reduce function in the eth2 execution abstraction would have access to beacon chain block roots. So would the idea be to make an EVM opcode that redirects to calling that? If so, seems reasonable.

  1. SSZ vs RLP : Add support for SSZ and consider deprecating RLP.

Support!

  1. sparse tree : Consider removing the hexary Patricia tree in favour of a sparse binary tree.
  2. Casper FFG : As part of an intermediate hybrid PoW/PoS step, update PoW fork choice rule to respect beacon chain finality.
  3. light clients : Replace PoW-based Eth1 light clients with PoS-based beacon chain light clients.

Support!

  1. randomness : Find a migration path for dApps that rely on the nonce header field for randomness. RANDAO only provides a decent random number every epoch, not every block as with PoW.

You mean the BLOCKHASH opcode? It seems difficult to distinguish between BLOCKHASH for randomness and BLOCKHASH to verify historical Merkle proofs (though the latter will likely break regardless). If we expose historical blocks, most recent epoch RANDAOs should be easy to verify.

  1. Eth1 headers : Consider redefining Eth1 header fields which may no longer be relevant (e.g. ommersHash , difficulty , beneficiary , nonce , gasLimit ) and make sure no significant dApps break as a result.

gasLimit may remain relevant; not sure yet.

  1. incentivisation : Remove PoW rewards.
  2. difficulty bomb : Remove difficulty bomb.

Agree!

  1. statelessness : Build statelessness support into Eth1 clients (Geth, Parity, etc.). Also implement logic to produce Eth2-compliant shard blocks.

This should be starting to happen with @AlexeyAkhunov’s work soon/already, right?

  1. new liveness invariant : Make sure that there are no significant dApps that break when moving to regular 3-second slots (as opposed to the current Poisson distribution for blocks, with a ~15sec average block time).
  2. libp2p vs devp2p : Migrate Eth1 clients from devp2p to libp2p.
  3. Eth1 gas limit : Consider removing the Eth1 gas limit to avoid having two gas limits (Eth1 gas limit under Eth2 gas limit).
  4. Eth2 gas limit : Make sure that 8,000,000 “Eth1 EVM gas” when translated to “Eth2 WASM gas” fits within the Eth2 gas limit. Significantly reducing the effective limit below 8,000,000 gas may cause unacceptable congestion. Check that the Eth2 gas mechanism (which would not have miner voting) is otherwise acceptable for Eth1.

Agree!

  1. WASMify Eth1 consensus : Formalise the Eth1 state transition function—including all precompiles—as WASM code. Split the WASM code into small chunks that fit within the Eth2 code limit (possibly 16kB per code chunk). This formalisation risks introducing consensus bugs on a $20B+ network so extensive fuzzing and formal verification may be required. We also want the WASM formalisation to be consistent with the wider WASM-for-blockchains standardisation effort.

Could we FV this using the existing EVM formalizations that have been created with K and the like?

  1. premine load imbalance : Consider the negative consequences of the load asymmetry from premining the Eth1 state into a single shard with the other 1023 shards empty.

What are some concrete negative consequences that we might expect to see? Imbalance is not itself bad; blocks are imbalanced already all the time.

  1. hard forks : Negotiate a timely hard fork schedule with the existing Eth1 ecosystem.

Note that it’s likely that the HF will require a 1-2 hour “chain shutdown” period. This is NOT unprecedented; it happened chaotically/involuntarily during the consensus failure in Nov 2016, but it is something that would need to be signalled beforehand.

  1. Eth2 consensus pollution : Consider disruptions to Eth2 whenever Eth1 will need to hark fork. Indeed, the Eth1 consensus would likely have “too big to fail” status within the Eth2 ecosystem (inconsistent with the expectation that execution engines are application-layer, not consensus-layer) which imposes an Eth2 hard fork for every Eth1 hard fork.

Agree!

All shards

Below are further considerations to put Eth1 consensus logic on all shards.

  1. state growth : Make sure that the ecosystem can handle 1024 privileged copies of the Eth1 consensus. In particular, the current no-rent approach may make the maintenance costs of tracking all shards too high for services such as exchanges and Etherscan.

My expectation is that the cost for exchanges’ storage largely comes from history, not state, as they have to store both and history is much bigger, and sharding is going to add a HUGE amount of history (10 MB/sec ~= 6 TB/week) regardless.

  1. shard number : Consider adding a shard number field in Eth1 headers to easily differentiate Eth1 execution engines running on different shards.

Shouldn’t we just make SHARD_NUMBER an opcode?

  1. yanking : Add support for contracts to move between shards and make sure that the asynchronisity introduced does not break existing Eth1 dApps.

Support!

Yes, I am still on it. Have just done some simplifications and optimisations, to get more data, quicker, and now forcing my brain to gets some initial specs out…

Will Ethereum 2.0 be using different algorithm to generate new private keys? In other words, will users with ETH stored in Ethereum 1.0 be in need to generate new public addresses and private keys and transfer ETH from Ethereum 1.0 to new Ethereum 2.0-based public addresses in order to participate in Ethereum 2.0 blockchain? Otherwise, why not just do a short cool down of the network in which during the cool down, a snapshot of all public addresses of the Ethereum 1.0 blockchain be taken, and correspondingly issue the same amount of ETH on Ethereum 2.0’s public addresses, where such Ethereum 2.0 addresses can be accessed with the same private keys generated from Ethereum 1.0? The same is with the dapps. Ethereum 1.0 transaction histories will just be maintained for the record.

Currently, two different private keys may lead to the same public key. So this may be a chance for Ethereum 2.0 to generate a much longer and different public address, so that a single private key may only lead to a single public address and not two with Ethereum 2.0. Users do not need to do anything extra except regenerate a new public address with a new Ethereum 2.0-based wallet generator, offline, and update their public addresses. Old public addresses from Ethereum 1.0 would be unusable in Ethereum 2.0 transactions. Cold storaged ETH since Ethereum 1.0 would remain cold thereafter. One problem is how to figure out what new public address to generate based on the old Ethereum 1.0 address alone. But this part is just optional.

The whole process will transition Ethereum 1.0 to Ethereum 2.0 layer 1 without being a shard.

Just my opinion.

I think the goal is to move toward account abstraction, where you can have addresses using whatever signature / anti-replay scheme you want.