On November 27th, Ethereum developer Mikhail Kalinin proposed an Eth1-Eth2 transition proposal called “executable beacon chain”. It is reported that the original idea of the proposal came from Ethereum co-founder Vitalik Buterin, which aims to Embed eth1 data (transactions, state roots, etc.) into the beacon block, and force the beacon chain proposer to generate executable eth1 data to eliminate complexity.
The following is the specific content of the proposal:
Special thanks to Vitalik Buterin for his creativity, djrtwo, zilm and others for their comments and useful contributions.
The recently proposed rollup-centric roadmap proposes data sharding as the main expansion factor implemented in Ethereum 2.0, allowing expansion on a single execution shard and simplifying the overall design.
The Eth1 fragmentation design assumes communication with data fragments through the beacon chain. If the second phase (Phase 2) with multiple execution shards is introduced later, then this approach will make sense. Due to the current focus on the rollup-centric roadmap, putting Ethereum 1.0 on a dedicated shard (that is, independent of the beacon chain) brings unnecessary complexity to the consensus layer and increases This reduces the delay between publishing data on shards and accessing them in Eth1.
We propose to eliminate this complexity by embedding eth1 data (transactions, state roots, etc.) into the beacon block and forcing the beacon chain proposer to generate executable eth1 data. This will treat the implementation and validity of eth1 as a first-class citizen of consensus.
Proposal overview
The Eth1 engine is maintained by each verifier in the system.
When the verifier intends to propose a beacon block, it will ask the eth1 engine to create eth1 data. Then, Eth1 data will be embedded in the beacon block being generated.
If the eth1 data is invalid, it will also invalidate the beacon block that carries it.
Eth1 engine modification
According to the previous scheme, the Eth1 sharding hub, Eth1 engine, and eth2 client are loosely combined and communicate through the RPC protocol (please check the Eth1+eth2 client relationship for more details). The Eth1 engine continues to maintain the transaction pool and the state downloader that needs its own network stack. It should also save the storage of the eth1 block.
The current proposal removes the concept of the eht1 block, and the eth1 engine has two potential methods to handle this change:
Synthesize the eth1 data carried by the beacon block to generate the eth1 block;
Modify the engine so that transaction processing does not require eth1 blocks, but uses eth1 data;
The former seems to be easier to implement than the latter, it allows faster conversion of the eth1 client to the eth1 engine, and has been proven by the eth1 fragment poc. We use the term “executable data” to refer to data including eth1 state root, transaction list (including receipt root and bloom filter), coinbase, timestamp, block hash, and all other data bits required for the eth1 state transition function .
The responsibilities list of the eth1 engine is similar to our previous responsibilities for eth1 sharding. The main observation items are:
For transaction execution, the eth2 client sends executable data to the eth1 engine. The eth1 engine updates its internal internal state by processing data. If the consensus check passes, it returns true, otherwise it returns false. Advanced use cases, such as instant deposit processing, may also require complete transaction credentials in the results.
For transaction pool maintenance, the Eth1 engine uses the ETH network protocol to broadcast and track transactions in the network. Waiting transactions are stored in mempool and used to create new executable data.
Executable data creation, the Eth2 client sends the previous block hash and eth1 state root, coinbase, timestamp, and all other information needed to create executable data (except the transaction list). The Eth1 engine returns an instance of ExcecutableData.
State management, Eth1 engine maintains state storage to be able to run Eth1 state execution functions. 4. 1 It involves the state trie pruning mechanism that is finally triggered, which requires the state trie version control based on the beacon blockchain; Note: If there is no final result for a long time, it will cause a lot of garbage in the storage, which will consume additional disk space. . 4.2 When stateless execution and “block creation” are ready, the eth1 engine can choose to run as a pure state transition function, which can disable state storage, thereby reducing the demand for disk space.
JSON-RPC support. For ease of use and adoption, it is very important to retain support for Ethereum JSON-RPC. This responsibility will be shared between the eth2 client and the eth1 engine, because the eth1 engine may lose the ability to independently handle a subset of JSON-RPC endpoints, such as calls based on block numbers and hashes. This separation will be resolved later.
Beacon block processing
The ExecutableData structure replaces the Eth1Data in the beacon block body. In addition, the synchronization of the beacon chain and eth1 can be stored in real time. Therefore, the deposit can be removed from the beacon block body. It is reasonable to process executable data after process_operations is completed, because in many places, operation processing may invalidate the entire block. However, this method may be sub-optimal, which leaves room for client optimization.
Access beacon state in EVM
We changed the semantics of the BLOCKHASH opcode used to return the eth1 block hash. Now, it returns the beacon block root, which allows to check the beacon status from 256 slots to the previous slot or the proof of the data contained in the block.
Asynchronous status reading has a major disadvantage. The client must wait for a block before it can create a transaction with a proof linked to the block or the state root it generates. In short, asynchronous state access must be delayed by at least one slot.
Direct status access
Assume that the eth1 engine can access the merkle tree representing the state of the entire beacon. Then, the opcode READBEACONSTATEDATA (gindex) can be used to provide EVM functionality to provide direct access to any beacon state. This opcode has several nice properties. First, the complexity of this reading depends on the gindex value and is easy to calculate, so the gas price can be easily inferred. Second, the size of the returned data is 32 bytes, which is completely suitable for EVM.
With this opcode, people can create a higher-level beacon state accessor library to provide a convenient API for smart contracts. E.g:
v=create_validator_accessor(index)#creates an accessor v.get_balance()#returns balance of the validator v.is_slashed()#returns the value of slashed flag This model eliminates the state access delay. Therefore, by performing appropriate sequencing on the beacon chain operation and eth1, the crosslink of the data in slot N-1 can be accessed in slot N, allowing rollup to prove that the data is included in the fastest way. Moreover, this method also reduces the data and computational complexity of beacon status reading.
Note: It may be worth making the semantics of the READBEACONSTATEDATA opcode independent of the specific commitment scheme (ie, the merkle tree) from the start to facilitate easy upgrades.
The cost of direct access adds to the complexity of the eth1 engine. The ability to read the beacon status can be achieved in different ways:
Transfer status and executable data. The main problem with this approach is to deal with large state copies. If direct access is restricted to a subset of state data that requires a small portion of state to be passed to execution, then it might work.
Duplex communication channel. With a duplex channel, the eth1 engine will be able to request the state segment of the EVM synchronization request from the beacon node. It will be able to ask the beacon node about the status of the EVM request synchronously. Depending on how the channel is set up, latency may become a bottleneck in executing transactions with beacon status reads.
Embedded eth1 engine, if the eth1 engine is embedded in a beacon node (for example, as a shared library), it can read the state from the same memory space through the host function provided by the node.
analysis
1. The current proposal of network bandwidth expands the beacon block by the size of executable data. However, because the proposal allows the use of advanced deposit schemes, it is possible to delete the Deposit operation. Based on the block utilization and the average eth1 block size, the expected growth is between 10% and 20%, which has little impact on network interface requirements.
It is worth noting that if rollup uses CALLDATA, the size of the eth1 block may increase to 200kb in the worst case (gas limit is 12 million), so that the executable beacon block size is around 300kb, which increases 60%.
2. Block processing time The average processing time is as follows:
Beacon block 12 ms
Epoch 64 ms
Ethereum mainnet block 200 ms
It is difficult to deduce the processing time of the beacon chain, especially when the validator set and crosslink processing are relatively large (because sharding has been launched). Perhaps at some point, epoch processing will be performed almost simultaneously with eth1 execution. A potential way to reduce the processing time at the epoch boundary is to process the epoch in advance without waiting for the start of the next slot when the last block of the epoch arrives in time. The asynchronous state access model allows another optimization. In this case, process_executable_data can run in parallel with the main process_block or even process_epoch payload.
Improve this design
One might say that the current proposal sets the execution model to be immutable and reduces the ability to introduce more executable fragments when needed.
On the other hand, some executable shards introduce problems such as cross-shard communication, shared account space, etc., and these problems are as important and difficult to solve as the expected shift in the execution model.
Regarding the proposal, Vitalik Buterin commented:
“Good job! I am really worried about the synchronization interaction between the eth1 execution and the beacon chain. The reason is that although it is simpler to use the synchronization interaction, it will permanently stipulate the requirements for validating the eth2 block to run the corresponding eth1 execution. For example, It excludes alternative methods such as allowing eth2 nodes to become eth1 stateless clients, and only verifies whether the eth1 party is part of the designated committee. Therefore, even if the executable data is directly in the beacon block, I would tend to remain executable The communication between the data and the beacon chain logic is completely asynchronous.”
