On October 12th, Ethereum developers gathered on Zoom for a conference call. The meeting was hosted by Tim Beiko, the protocol support lead at the Ethereum Foundation, and developers discussed and coordinated changes to the Ethereum execution layer (EL).

On October 12th, Ethereum developers gathered on Zoom for the All Core Developers Execution (ACDE) Call #172 meeting. The ACDE conference call is a bi-weekly series of meetings, hosted by Tim Beiko, the protocol support manager of the Ethereum Foundation, where developers discuss and coordinate changes to the Ethereum execution layer (EL). This week, developers focused on the progress of the following issues:

Cancun/Deneb (Dencun) test

Ethereum Virtual Machine (EVM) Object Format Development.

Dencun Test

Ethereum Foundation's DevOps engineer Barnabas Busa recently shared some updates about the release of Devnet #9 on September 29th.

Devnet #9 currently has a participation rate of 93%, which means that 93% of validators are actively participating in network consensus.

7% of the inactive validators are mainly composed of Geth (EL)/Teku (CL) validator nodes.

Erigon (EL)/Prysm (CL) client combination and EthereumJS (EL) client also have issues.

Flashbots team is testing MEV-Boost relays and builders on Devnet #9. Busa encourages other relays and builders operators to reach out to him so that more MEV infrastructure can be tested on Devnet #9.

The Blob transaction has not yet been tested with the MEV-Boost builder. In this case, the Blob was discarded by the builder, but developers are not yet sure if this is because the Blob is actually invalid, does not meet the minimum basic fee requirements, or for some other reason.

Busa and his colleague Parithosh Jayanthi at the Ethereum Foundation shared the latest updates on the upcoming Devnet #10.

This week's Devnet #10 is not yet ready, but it is expected to be ready next week.

For Devnet #10, developers plan to test the trusted setup file in the EIP 4844 KZG ceremony.

Devnet #10 will have a large validator group, including 330,000 active validators. When the development network just starts, a large number of deposits and withdrawals from validators will flood in. It is expected that the entry and exit restrictions for validators will be reduced from 5 times to 4 times within one or two days after the network starts. Although the actual maximum entry and exit restrictions on the main network are 8, developers will use a limit of 4 to test EIP 7514 on Devnet #10.

Busa emphasized that developers are still working on resolving some critical issues during the Dencun testing process. Until these issues are properly addressed, the development team will not launch Devnet #10, which is likely to be the final development network for Dencun before activation on public Ethereum testnets such as Goerli. Jayanthi outlined in the Zoom chat box the key issues that developers need to address before launching Devnet #10:

Update EIP 4844 KZG trusted setup file for ceremony.

Better visualization of Blob transactionsThe improvement of the MEV pipeline.The improvement of network stability.

During the conference call, Jayanthi encouraged the client team to increase support for the Beacon API to improve visibility of Blob transactions. Beiko asked if developers were willing to upgrade the Goerli test network after Devnet #10 was launched. Busa suggested observing the performance of Devnet #10 before deciding on the next steps for upgrading the test.

In addition, Jayanthi confirmed that during a period of time after the release of Devnet #10, developers may conduct a shadow fork of the Ethereum mainnet on the public test network to further test the Dencun upgrade. However, Jayanthi pointed out that the practicality of the shadow fork may be limited, as most of the errors discovered during the Dencun testing period were at the peer-to-peer network level.

Geth (EL) developer Marius van der Wijden stated that his colleague Péter Szilágyi successfully ran his own node on Devnet #9 and discovered a serious issue related to blob spam.

It is reported that in order to prevent node crashes, Szilágyi has implemented a transaction processing program to limit the number of blobs he sees on the development network. Van der Wijden suggested that the CL team re-examine the 3/6 maximum blob target/limit in EIP 4844 and let the EL team carefully consider the node bandwidth requirements and methods to address blob spam.

In order to further discuss these issues, Beiko encourages developers to participate in the Dencun interoperability testing conference call on October 16th.

EVM Object Format Development

Later, developers discussed the latest progress of the EVM Object Format (EOF). EOF is a set of EIPs focused on changes to the EVM, which is a virtual machine based on Ethereum used to execute smart contract code. One of the advocates of EOF, Danno Ferrin, summarized and concluded the work on EOF over the past few months.

At the beginning of the speech, Ferrin emphasized that he hoped EOF could become the main code change in the upgrade after Cancun/Deneb (referred to as Prague/Electra). Ferrin stated that there are currently four main teams working on EOF.

Team Ipsilon: A development team funded by the Ethereum Foundation, focusing on improving the EVM.

EL client team: such as Geth, Besu, and Nethermind.

At the end of the speech, Ferrin reiterated his hope to see EOF as the main code change in the Prague/Electra upgrade. He also stated that it is feasible to test and execute a series of code changes for EOF on the mainnet within three to six months after the Dencun upgrade is completed. The latest specification for EOF can be found here. Unresolved issues regarding these specifications have been compiled by the Ipsilon team here. Certain parts of the EOF specification still need improvement. We encourage developers who participated in the conference call to share their views on the latest developments and specifications for EOF in the "#EVM" channel of the Ethereum Research and Development Discord.

EVM Object Format Debate

Ferrin's speech has sparked widespread discussion among developers. During the conference call, developers expressed several concerns about EOF, including:

Time Schedule: Several developers, including Tim Beiko, are hesitant about the three to six month schedule for implementing EOF after the Dencun upgrade.

Urgency: Developers are considering incorporating Verkle into another major code change for Prague/Electra. In early August, Guillaume Ballet, a developer at the Ethereum Foundation, shared the latest progress on Verkle. During this week's conference call, Ballet emphasized that Verkle is a more urgent upgrade for Ethereum compared to EOF and should therefore be given priority. Ballet also stated that if the complexity of EOF can be reduced and the number of code changes minimized so that its implementation does not affect the Verkle timeline, he will support the upgrade.

Benefits: Van der Wijden and Nethermind (EL) developers, including Lukasz Rozmej, questioned the direct benefits of EOF versus the complexity of upgrading. Concerns about the lack of strong demand for such a significant change to the EVM were expressed. Ferrin stated that the EVM was written "over the weekend" by Ethereum's original development team and can be significantly improved to ensure that it remains competitive with rivals such as the new alternative Layer-1 blockchain, Sui. "This is not a security risk," Ferrin said. "It's more like an existential transaction."

Increased complexity and risk: Van der Wijden emphasized that EOF will increase protocol complexity and risk. The burden on the client team will increase as they must maintain two versions of EVM and ensure their interdependence is considered during future hard fork periods. Wijden believes that Layer-2 teams should not attempt to parallelize the maintenance of EVM and EOF work to the client team, but should focus on implementing improvements to EVM on their own protocol.

Backward Compatibility: Another major issue with EOF is that it may bring backward compatibility issues to legacy smart contracts. The design of EOF will ensure continued support for legacy smart contracts that do not use the EOF container. However, developers such as Ferrin and Ansgar Dietrichs, a researcher at the Ethereum Foundation, suggest that over time, old smart contract functionalities may be phased out and specifically upgraded for EOF.

EVM Governance: Dietrichs also expressed concerns about the impact of EOF on EVM governance. Ethereum is constantly evolving to support smart contract execution on alternative networks called Layer-2. Assuming that most user activity and smart contract execution will occur off-chain in the future, and Ethereum will primarily serve as a data availability layer, changes to EVM should be most important for Layer-2 protocols rather than the Ethereum mainnet. Dietrichs suggests that developers carefully consider and discuss how to decide on changes to EVM in the constantly expanding Layer-2 ecosystem.

Ferrin and his team have been dedicated to researching EOF since 2021. Earlier this year, due to the multi-stage roadmap of EOF, it was rejected by the Shanghai hard fork. To address this issue, supporters of EOF created an updated design for the upgrade, which will introduce all changes related to EOF in a major upgrade. However, the complexity of this upgrade was one of the main concerns raised about EOF during this week's conference call. Van der Wijden emphasized that developers should carefully consider whether EOF should be implemented on Ethereum instead of continuing to postpone the decision regarding EOF.

"I know that the Ipsilon team and Danno have spent a lot of time solving this problem. It would be quite severe to say that we may not deliver it after so long. But I think it's worse to say, 'Let's see,' and then we postpone it for another two years, and then we say, 'Oh, we're not going to ship it after all.' Therefore, I think we should make a decision at Devconnect," said van der Wijden, adding, "If this is what we want to do, then we will do it, unless we encounter similar technical challenges. If we say we're not going to do it, then we won't. I don't think that will happen. It's fair for everyone on the team who has been working hard to make clear decisions."

Rozmej added that, in addition to EOF and Verkle, developers may need to reconsider code changes such as EIP 4444 to address the increasingly serious problem of historical chain data growth. According to Rozmej, the historical chain data growth rate is 20GB per month. Beiko agreed that developers should continue to discuss EOF, Verkle, and Prague/Electra on Devconnect. Beiko also emphasized that a second-layer protocol similar to EVM will be specifically convened on Wednesday, October 18 to encourage collaboration between these teams. An EOF implementer conference call will also be held on the same day. Finally, Beiko mentioned the Layer2 Day event organized by L2Beat on Devconnect.