The new proposal aims to facilitate the PoS transition

• A proposal from an Ethereum developer wants to change the validation process of the Eth1 blockchain and incorporate it into the Beacon Chain.
  
• The changes could present complications for the DeFi industry.

After the threshold of 524,288 ETH required has been reached, the deployment of Ethereum 2.0 with phase 0 will begin on December 1st. However, there are still about two years left to complete the full deployment of all phases of Eth 2. The ease of the process, Mikhail Kalinin made a proposal on how the Beacon Chain could interact with the “Eth 1” blockchain.

Entitled “Executable Beacon Chain”, the proposal rethinks the initial strategy of maintaining the blockchain with the Proof-of-Work consensus operating in a dedicated shard. Kalinin believes this “would put unnecessary complexity in the consent layer” and create problems in accessing data in eth1, as Kalinin states:

We propose to get rid of this complexity by embedding eth1 data (transactions, state roots, etc.) into beacon blocks and forcing beacon proponents to produce executable eth1 data. This enshrines the execution and validity of eth1 as a first-class citizen at the center of consensus.

In this way, the “Eth1 engine” would be maintained by the Eth2 validators. Whenever a validator proposes a block, it interacts with the eth1 engine to create “eth1 data”. Then, the information would be added to the “beacon block body”. The eth1 data is invalid if the eth2 block is invalidated.

As a result, the Ethereum 1.0 blockchain would no longer function as it currently does. Its customers 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. In this regard, the proposal states the following:

We use the term executable data to mean data that includes the eth1 state root, the transaction list (including the receipt root and bloom filter), coinbase, timestamp, hash of blocks, and all other data bits required by the state transition function eth1.

Possible problems for Ethereum’s DeFi

In short, the tasks of the eth1 engine would be similar to what the Ethereum Core developers had planned for the Eth 1 Shard, Kalinin says. However, in response to the proposal, several Ethereum Core developers raised their voices and warned of difficulties.

For example, some smart contracts may stop working if a change is made to the BLOCKHASH function of the Ethereum 1 blockchain. This could cause difficulties for Ethereum’s DeFi sector and therefore thousands of users. Additionally, Ethereum 2.0 developer Justin Drake raised additional concerns about data validation as proposed by Kalinin:

This would require validators to run an Eth1 full node for validation. This goes against the design goal of allowing validators to run on inexpensive hardware (e.g. entry-level laptops, NUCs, Raspberry Pis, phones, etc.). This is particularly relevant for validators who are aiming a small amount of ETH through a pooled m-of-n validator.

Ethereum inventor Vitalik Buterin congratulated Kalinin’s ongoing work. Although he also expressed some concerns about the interaction of the Eth1 run with the beacon chain, Buterin also said:

(…) Even if the executable data is directly inside beacon blocks I would be inclined to favor the maintenance of communication between the executable data and the logic of the completely asynchronous beacon chain.