Ethereum All Core Developers Execution Call #163 Writeup
On June 8, Ethereum developers gathered over Zoom for All Core Developers Execution (ACDE) call #163. Chaired by the Ethereum Foundation’s Tim Beiko, the ACDE calls are a bi-weekly meeting series where Ethereum client teams discuss and coordinate changes to the execution layer (EL) of Ethereum. This week, developers discussed a potential change to the maximum number of blobs per block under Ethereum Improvement Proposal (EIP) 4844. They agreed to include EIP 4788 and EIP 5656 to the Cancun/Deneb upgrade and with the addition of these two EIPs, finalized the scope of Cancun.
The next Ethereum upgrade will include five code changes:
EIP 4844: Shard blob transactions
EIP 6780: SELFDESTRUCT only in the same transaction
EIP 1153: Transient storage opcodes
EIP 4788: Beacon block root in the EVM
EIP 5656: Memory copying instruction
All other proposed EIPs from prior calls have been rejected for the Cancun upgrade but may be reconsidered for a different upgrade in the future.
EIP 4844 Blob Limit
During ACDC #110, Ethereum Foundation researcher Dankrad Feist proposed increasing the maximum number of blobs per block under EIP 4844 from 4 to 6, and subsequently, increasing the blob target from 2 to 3. As background, blobs are a new type of transaction on Ethereum that post Cancun will offer a transient storage space for Layer-2 rollup operators. Feist conducted a data experiment on Ethereum to see how the network would respond to processing large blocks, that is blocks with an additional data load of anywhere between 1kB to 1MB. Feist said that sustained loads of up to 10 large blocks in a row were “no problem” for the network. Therefore, the blog target could safely be adjusted and increased.
While some developers on the call like Alex Stokes and Ansgar Dietrichs were in support of the change, others were more wary, saying the change would make certain types of denial-of-service (DoS) attacks on Ethereum less costly. “I still think this attack is extremely costly and cannot be sustained for very long,” said Geth (EL) developer Marius van der Wijden about the potential for a DoS attack. “But we just have to be clear about this. We’re making this more possible than it is right now and with increased blob count, we make it even easier to do. So my suggestion would be to start with 2/4, which is already kind of high in most cases and then if we see that this works reliable or can maintain it for a long time, we can increase it.”
Feist pushed back on van der Wijden’s comments saying that the developers on the call were “always much more conservative” on new code changes than existing standards and practices that is in view are already “pretty DoS-able.” Feist added, “It seems not fair that suddenly all core developers override the Ethereum community on this in the case of blob [limit increase].” Given the disagreement, Beiko recommended continuing the discussion on the EIP 4844 Implementors’ Call on Monday, June 12. Developers also agreed to increase the blob limit from 2/4 to 3/6 as Feist suggested for the next dedicated test network for EIP 4844, Devnet 6. Client teams are working towards relaunching Devnet 6 with updated software versions next week.
Final Cancun Scope
Developers finalized the scope of Cancun on ACDE #163. They agreed to include EIP 4788, which will expose data about the Beacon Chain to the EL for permissionless access by smart contracts. Developers agreed to design the EIP in such a way that the code change has bounded storage growth at roughly 80MB per year. EIP 5920, which would introduce a new opcode, PAY, to send ether to an address without calling any of its functions, was rejected from Cancun due to a lack of consensus among developers for the urgency or need for the opcode. EIP 5656, which introduces an instruction for copying memory areas in the Ethereum Virtual Machine (EVM), was accepted due to its simplicity and ease of implementation. That said, Beiko emphasized that EIP 5656 may be dropped from the upgrade if client teams run into difficulties preparing the code change for Cancun alongside the other four comparatively more higher priority code changes.
Other topics discussed on ACDE #163 included:
Engine API versioning: As discussed on ACDC #110, developers will move towards a one method, one structure approach for Engine API V3 to reduce the complexity of maintaining multiple versions of the same API method. The developer championing this approach, Mikhail Kalinin, encouraged interested client teams to review his proposal.
Honest validator duties: Teku (CL) developer Enrico Del Fante raised questions about how nodes should process blobs under EIP 4844 and more specifically, whether blobs should be processed prior to sending attestations. Chair of the ACDC meetings Danny Ryan said that he would create a pull request (PR) on GitHub to clarify the behavior and discuss the matter further on the next ACDC meeting.
Holesky Testnet Launch Coordination Call #0: Finally, Barnabas Busa, a DevOps Engineer at the Ethereum Foundation, gave a reminder about an upcoming coordination call for the Holesky test network. The Holesky testnet is meant to replace the Goerli testnet by the end of 2023. The goal is to make it larger in size in terms of the number of validators than both Goerli and Ethereum mainnet. Developers are tentatively looking at launching Holesky no later than September around the time of the Cancun upgrade. To discuss all these details, Busa asked at least one person from every Ethereum client team to participate in the call on Thursday, June 15.