- A proposal by an Ethereum developer wants to change the Eth1 blockchain validation process and embed it to the Beacon Chain.
- The modifications could present complications for the DeFi sector.
After the threshold of 524,288 required ETHs has been reached, the deployment of Ethereum 2.0 with phase 0 will begin on December 1. However, there are still about two years left to complete the full deployment of all phases of Eth 2. The ease the process, Mikhail Kalinin has made a proposal on how the Beacon Chain could interact with the “Eth 1” blockchain.
Titled “Executable Beacon Chain“, the proposal rethinks the initial strategy of keeping the blockchain with the Proof-of-Work consensus operating in a dedicated shard. Kalinin considers that this would “put unnecessary complexity into the consensus layer” and create problems in accessing the data in eth1, as Kalinin states:
We propose to get rid of this complexity by embedding eth1 data (transactions, state root, etc) into beacon blocks and obligating beacon proposers to produce executable eth1 data. This enshrines eth1 execution and validity as a first class citizen at the core of the consensus.
In this way, the “Eth1-engine” would be maintained by the validators of Eth2. Each time a validator proposes a block, it would interact with the eth1-engine to create “eth1 data”. Then, the information would be added to the “body of the beacon block”. The eth1 data is invalid if the eth2 block is invalidated.
Consequently, the Ethereum 1.0 blockchain would no longer work as it currently does. Its clients could become “eth1-engines” and the “notion of eth1 block” or the need to maintain the PoW protocol would be eliminated. They would become an unnecessary component for transaction processing. Regarding this, the proposal states the following:
We use term executable data to denote data that includes eth1 state root, list of transactions (including receipts root and bloom filter), coinbase, timestamp, block hashes and all other bits of data required by eth1 state transition function.
Possible issues for Ethereum’s DeFi
In short, the tasks of the eth1-engine would be similar to those the developers of the Ethereum Core had planned for the Eth 1 Shard, Kalinin says. However, In response to the proposal, several Ethereum Core developers have raised their voices and have warned of difficulties.
For example, some smart contracts may stop working if there is a change in the BLOCKHASH function of the Ethereum 1 blockchain. This could cause difficulties for the Ethereum DeFi sector and thus thousands of users. Furthermore, Ethereum 2.0 developer, Justin Drake, has raised additional concerns about the validation of the data as proposed by Kalinin:
This would require validators to run an Eth1 full node to validate. This goes against the design goal of allowing validators to run on cheap hardware (e.g. entry-level laptops, NUCs, Raspberry Pis, phones, etc.). This is especially relevant for validators that are staking a small amount of ETH through an m-of-n pooled validator.
The inventor of Ethereum, Vitalik Buterin, congratulated Kalinin’s work in progress. Although he also expressed some concerns about the interaction of the Eth1 run with the beacon chain, Buterin also said:
(…) even if executable data is directly inside beacon blocks I’d be inclined to favor keeping the communication between the executable data and the beacon chain logic fully asynchronous.