skip to content

Ethereum All Core Developers Execution Call #165 Writeup

Ethereum All Core Developers Consensus Call #136 Writeup - Galaxy Research

On July 6, Ethereum developers gathered over Zoom for All Core Developers Execution (ACDE) call #165. Normally 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, the call was chaired by Ethereum Foundation researcher and chair of the All Core Developers Consensus (ACDC) calls Danny Ryan. On ACDE #165, developers discussed:

SSZ Impact Analysis

The Ethereum Foundation commissioned an impact analysis on EIP 6466 and 6406 from Dedaub, a blockchain security and auditing firm. A few months ago, Dedaub was also commissioned to conduct an impact analysis on EIP 4758 and 6780. The results of this analysis were shared on ACDE #162. EIP 6466 and 6406 are code changes that update the encoding of data from RLP to SSZ in two block header fields, “transactions_root” and “receipts_root”. For more background on the rationale for updating the block serialization format to an SSZ data structure, read prior call notes here.

The goal of Dedaub’s analysis of EIP 6406 and 6466 was to determine the impact of these code changes on smart contracts already deployed and actively used on Ethereum. The analysis found that three major projects would be impacted by the update to SSZ: LayerZero, zkBridge, and Telepathy. LayerZero is a blockchain interoperability protocol that facilitates interactions between applications on Ethereum and other general purpose blockchains. zkBridge like Layer Zero is a cross-chain bridge that relies on LayerZero for various oracle functions. Finally, Telepathy is a blockchain data oracle that facilitates communication between multiple Layer-1 and Layer-2 protocols.

Despite the impact on these applications, Neville Grech, Director of Dedaub, said that all three applications could be upgraded to accommodate the code changes implemented through EIP 6466 and 6406. “The impact is overall moderate. In all three cases, we found upgradeability possibilities. Now, I have to stress that RLP encoding and proving [Merkle Patricia Tree] commitments happen a lot on-chain and it took quite a bit of time to go through and filter out the cases where this was going to be affected versus not. Most instances were indeed unaffected,” said Grech. Grech added that high-profile dapps including Optimism and Polygon were flagged as false positives during their study.

Common reasons for false positives were:

  • the application does not actually perform Merkle Patricia Tree (MPT) proofs over RLP encoded data,

  • the application does perform MPT proofs over RLP encoded data, but the data does not originate from Ethereum, but rather from Layer-2 side chains,

  • the application does perform MPT proofs over RLP encoded data and the data originates from Ethereum, but it is not data from block header fields impacted by EIP 6406 and 6466 or the proofs are performed over custom data structures that would not be affected by the code changes.

Developers briefly discussed their thoughts on next steps considering Dedaub’s impact report. Danny Ryan said that a decision around the implementation or timing of the transition from RLP to SSZ did not need to be made on this call and that the information shared by the Dedaub team should be considered for a future discussion.

Dencun Updates

Parithosh Jayanthi, DevOps engineer at the Ethereum Foundation, said that Devnet #7 for the Cancun/Deneb upgrade was successfully launched on Friday, June 30. The test network is finalizing smoothly and a few issues in client implementations have already been discovered. Jayanthi said that once the outstanding issues are patched by client teams, he will try spamming the network with blob transactions for longer durations of time to see how the network handles an increased load of 3 target blobs/block, up from a target of 2 blobs/block during the last testnet. Jayanthi highlighted that among the issues, there was one impacting staked ETH deposits that Teku and Prysm CL client teams should investigate further. Representatives from the Geth and Nethermind EL teams also shared issues that were being actively patched on their end in preparation for the next stage of testing on Devnet #7.

In preparation for the next testnet, Devnet #8, developers discussed testing the other finalized EIPs outside of EIP 4844. Up until now, the testnets have focused on client implementations of EIP 4844 exclusively. However, as discussed on ACDE #163 and ACDC #111, the upgrade will also include the activation of EIPs 6780, 1153, 4788, 5656, 7044, and 7045. Danny Ryan said that the specifications for Deneb already include the finalized scope of the upgrade and that he would want to see the full EIP set tested on Devnet #8. Marius van der Wijden, Geth (EL) developer, said that more time should be dedicated to stress testing Devnet #7 before moving on to a full-featured version of the Cancun/Deneb upgrade for Devnet #8. Jayanthi agreed to continue stress testing Devnet #7 but encouraged client teams to start working on including all Cancun/Deneb EIPs in their releases, and ensure these releases are passing the necessary Hive tests in preparation for the eventual launch of Devnet #8.

Once more data is collected on how Devnet #7 is responding to stress tests, developers agreed to also continue the discussion on whether to increase the target blob number from 2 to 3. Danny Ryan said that they would revisit this issue on the next EIP 4844 implementers’ call and the next ACDC call.

Builder Override Flag

Mikhail Kalinin, Teku (CL) developer, asked EL client teams whether they would be comfortable with the inclusion of a change to the Engine API for the Cancun upgrade. The change, as discussed on prior ACDC calls, is designed to create Boolean flag in the “get_payload” API command that returns true if the EL client of an Ethereum validator node detects censoring behavior. The EL client will base their detection of censorship on certain heuristics about the activity of the Ethereum mempool or block reorgs. It is up to the CL client on what to do with this information, either falling back on local block production or simply ignoring the flag and carrying on with block production through an MEV relay and third-party builder. The heuristics and responses to the builder flag are intentionally left open-ended so that EL and CL client teams can each ideate their own protection measures against censoring activity. Kalinin stressed that the complexity of including the builder flag is quite low but the potential utility of it high.

Lukasz Rozmej, Nethermind (EL) developer, questioned what types of heuristics had already been prepared or tested around this builder flag. Danny Ryan suggested that one possible heuristic could detect if an eligible transaction with necessary fees has been held in the mempool over a long period of time and not included in a block. Marius van der Wijden said that he implemented a heuristic where the flag returns positive if a transaction is consistently reorged out of a block three consecutive times. Reorg refers to a re-organization of blocks that usually results in an orphaned block, or a block left out of canonical chain history. Rozmej noted that returning a positive flag indefinitely after detecting one instance of censoring behavior would not be ideal. Van der Wijden agreed, saying that the heuristics for the builder flag he implemented would need to be further researched, tested, and optimized.

“The concept is great, and we should implement it ASAP. It’s very simple because we can right now, just return false from some time,” said Rozmej. “[But] I just wanted to highlight that this opens up not trivial problems [in terms of implementation] that may have better or worse solutions that could be helpful to have some research.” Adding to Rozmej’s sentiments around the need for research around practical heuristics that could be implemented with this flag, Ethereum Foundation Researcher Dankrad Feist was adamant that heuristics involving block reorgs did not make sense for detecting censoring behavior and that the heuristics should primarily monitor the Ethereum mempool. Feist went further saying that a heuristic monitoring the Ethereum mempool would have to make a subjective judgement call on whether censoring activity is happening based on priority tips, that is the additional fees attached to transactions to get them prioritized for inclusion in a block.

Ryan stressed that the flag is purely designed to create opportunities for client to make robust heuristics but not necessarily to dictate the specifics of the heuristics in advance. It was clear from the discussion that the necessary research for applicable heuristics to use with this flag had not been fleshed out. Kalinin asked client teams to review the builder flag Engine API change on GitHub and speak up if they are opposed to including it for Cancun before Monday, July 10. If there is no opposition to the change, Kalinin said that he would merge the necessary changes into Engine API specifications for inclusion in the Cancun/Deneb upgrade. Changes to the Engine API are not documented as EIPs.

EIP 4788 Progress

As discussed on ACDE #164, the implementation of EIP 4788 will be modified slightly to prevent an excessive use of storage space through the code change. EIP 4788 introduces a new precompile, that is a cost-effective smart contract operation, that will expose information about the CL on the EL. This functionality will unlock many use cases for decentralized applications such as staking pools and restaking protocols that would benefit from trust-minimized access to the CL state. The modification to EIP 4788 proposes bounding the storage growth of the precompile using two ring buffers. In programming, ring buffers are a common implementation for queuing data in a fixed-length array. Ethereum Foundation Researcher Alex Stokes said that the modification would be merged into final EIP 4788 specifications for implementation in Cancun posthaste.