Important Discussions in Recent Ethereum Core Devs Meeting

One year after the official implementation of The Merge upgrade, the Ethereum network is facing significant changes in its development roadmap. Specifically, these challenges and their solutions were discussed in the morning meeting on September 15 by the Ethereum Core Devs team.

Important Discussions in Recent Ethereum Core Devs Meeting

It's worth noting that the All Core Devs (ACDE/ACDC) meeting is a weekly gathering of the core development team for Ethereum. However, this morning's meeting (15/10) attracted more attention than usual, primarily due to multiple proposals directly impacting the upcoming Dencun upgrade being discussed concurrently.

Updates Related to Devnet
Firstly, updates on the Devnet-8 test network for the Dencun upgrade were discussed. Clients such as Besu, Prysm, and Geth are currently in the testing phase of a new change related to EIP-4844, which involves blob-transaction types.

Blob-transaction is a new transaction format that allows Layer-2 optimizations to manage gas fees from the process of recording and exchanging data with Layer-1. This is considered the key feature of EIP-4844 (the most anticipated proposal in the Dencun upgrade).

Read more: What's notable about the upcoming Dencun upgrade of Ethereum?
Proposal to Minimize Risks from Liquid Staking
The next important discussion pertained to integrating the proposal EIP-7514 into the Dencun upgrade. This proposal aims to limit the number of validators added to the network per Epoch (a unit of time on the blockchain).

Developer Dankrad Feist emphasized the necessity of this update, stating that with the current trend of deposits and withdrawals, the network is likely to accumulate a large proportion of liquid staking before Dencun is deployed, leading to unwarranted risks. Feist also addressed the issue of Lido Finance staking approximately 1/3 of the ETH stake amount.
According to current discussions, the Churn-Limit (the limit on new Validator additions) will be set at 8 validators per epoch.

Arbitrum and Data Compatibility Issues
Another proposal discussed was related to the EIP-4844 story of Arbitrum. Specifically, Arbitrum's current supported opcode is "BASEFEE". However, the Layer-2 network lacks a way to record fee information for blob data from Layer-1. Hence, proposal 7516 was discussed. This proposal aims to return data on the fee levels that Layer-2s must pay, facilitating easier Layer-2 compatibility when EIP-4844 is implemented.

If the addition of the "BLOBBASEFEE" opcode (EIP-7516) does not pass, Arbitrum will have only two cumbersome solutions:

Relying on an oracle to obtain fee data (which would reduce decentralization).
Committing direct evidence to Batch on Layer-1 (which would increase complexity and costs).
Other Updates
Lastly, adjustments were made to CALLDATA to optimize gas fees for networks post EIP-4844 upgrade.

Additionally, a demo for Reth (a new client written in Rust) was conducted.