Ethereum All Core Developers Execution Call #165 Writeup
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:
an impact analysis on EIP 6466 and 6406,
progress on Cancun/Deneb testing efforts,
the inclusion of a builder override flag to the Engine API, and
the inclusion of two ring buffers to the specifications for EIP 4788.
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.
Legal Disclosure:
This document, and the information contained herein, has been provided to you by Galaxy Digital Holdings LP and its affiliates (“Galaxy Digital”) solely for informational purposes. This document may not be reproduced or redistributed in whole or in part, in any format, without the express written approval of Galaxy Digital. Neither the information, nor any opinion contained in this document, constitutes an offer to buy or sell, or a solicitation of an offer to buy or sell, any advisory services, securities, futures, options or other financial instruments or to participate in any advisory services or trading strategy. Nothing contained in this document constitutes investment, legal or tax advice or is an endorsementof any of the digital assets or companies mentioned herein. You should make your own investigations and evaluations of the information herein. Any decisions based on information contained in this document are the sole responsibility of the reader. Certain statements in this document reflect Galaxy Digital’s views, estimates, opinions or predictions (which may be based on proprietary models and assumptions, including, in particular, Galaxy Digital’s views on the current and future market for certain digital assets), and there is no guarantee that these views, estimates, opinions or predictions are currently accurate or that they will be ultimately realized. To the extent these assumptions or models are not correct or circumstances change, the actual performance may vary substantially from, and be less than, the estimates included herein. None of Galaxy Digital nor any of its affiliates, shareholders, partners, members, directors, officers, management, employees or representatives makes any representation or warranty, express or implied, as to the accuracy or completeness of any of the information or any other information (whether communicated in written or oral form) transmitted or made available to you. Each of the aforementioned parties expressly disclaims any and all liability relating to or resulting from the use of this information. Certain information contained herein (including financial information) has been obtained from published and non-published sources. Such information has not been independently verified by Galaxy Digital and, Galaxy Digital, does not assume responsibility for the accuracy of such information. Affiliates of Galaxy Digital may have owned or may own investments in some of the digital assets and protocols discussed in this document. Except where otherwise indicated, the information in this document is based on matters as they exist as of the date of preparation and not as of any future date, and will not be updated or otherwise revised to reflect information that subsequently becomes available, or circumstances existing or changes occurring after the date hereof. This document provides links to other Websites that we think might be of interest to you. Please note that when you click on one of these links, you may be moving to a provider’s website that is not associated with Galaxy Digital. These linked sites and their providers are not controlled by us, and we are not responsible for the contents or the proper operation of any linked site. The inclusion of any link does not imply our endorsement or our adoption of the statements therein. We encourage you to read the terms of use and privacy statements of these linked sites as their policies may differ from ours. The foregoing does not constitute a “research report” as defined by FINRA Rule 2241 or a “debt research report” as defined by FINRA Rule 2242 and was not prepared by Galaxy Digital Partners LLC. For all inquiries, please email [email protected]. ©Copyright Galaxy Digital Holdings LP 2023. All rights reserved.