The Eth1x64 experiment
Motivation
It has been mentioned multiple times in the past that one could just “put Eth1 on each shard” on Eth 2.0. The feasibility of this idea is yet to be proven.
Furthermore we think that this reduced design space aids a quicker turnaround and possibly the result can be reused for Phase 2 or it can reduce the to-be-explored design space.
Goal
Design a cross-shard protocol between “Eth1 shards” with least invasive means to the EVM and current DApp best practices.
Background
In Phase 0 there is a process for “depositing” Ether from Eth1 as “Beacon Ether”, but no further integration with Eth1 is explained.
One potential way to integrate Eth1 more closely is explained by the Phase 1.5 idea, to recap that briefly:
- Eth1 becomes Shard 0
- A list of Shard 0 validators is added to the beacon chain (
eth1_friendly_validators) and Shard 0 validators are only chosen from this subset
Vitalik also posted a larger diagram overviewing different areas of work on Ethereum.
Historically there has been a reluctance to introduce sizeable changes to the EVM. This has to be considered and attempt must be made to minimize changes.
Synopsis
Take Phase 1.5 as the baseline, but extend it as:
- Each of the 64 shards contain “Eth1”
- Shard 0 contains the current Eth1 mainnet state, while other shards start with an empty state
- Change
eth1_friendly_validatorsso that each shard has its own list
Furthermore:
- Consider current Eth1 (“Istanbul”), but assume “stateless ethereum” (e.g. block witnesses) and ignore “account abstraction” and EIP-1559
- Consider Ether on each shard to be the same token as “Beacon Ether”
- Shard validators are paid via the coinbase inside the shard and not via “Beacon Ether”
Planned features (in the following order):
- Cross-shard Ether transfer
- Cross-shard contract calls
- Moving Beacon Ether from the beacon chain into shards other than the 0 shard
- Moving Ether out of other shards than the 0 shard
Important to note that during 1) and 2) the existence of “Beacon Ether” is ignored.
Future work
Introduce account abstraction and Webassembly into the design, which leads into Phase 2.
Any feedback is appreciated. The Ewasm team will explore this and report our findings.
