Partnered With:

Summary of the latest meeting of Ethereum core developers: final progress of Dencun upgrade, scope of Pectra upgrade

Read this article in 18 Minutes

On March 7, all core developers of Ethereum participated in the 129th All Core Developers Consensus (ACDC) conference call.

Original title: "Ethereum All Core Developers Consensus Call #129 Writeup"

Original author: Christine Kim

Original compilation: Luccy, BlockBeats

Editor's Note:

The All Core Developers Consensus Call (ACDC) of Ethereum is held every two weeks to discuss and coordinate the development of Ethereum. Changes to the Consensus Layer (CL). This is the 129th ACDC conference call. During the meeting, developers shared the final update on preparations for the Dencun upgrade and discussed the scope and EIP of the next Ethereum upgrade, Pectra.

Christine Kim, Vice President of Research at Galaxy Digital, recorded the key points of this meeting in detail. BlockBeasts compiled the original text as follows:

On March 7, 2024, Ethereum developers gathered on Zoom to participate in the All Core Developers Consensus (ACDC) call #129 meeting. The ACDC call is a biweekly series of meetings hosted by Ethereum Foundation researcher Danny Ryan, where developers discuss and coordinate changes to the Ethereum Consensus Layer (CL). This week, developers shared a final update on preparations for the Dencun upgrade, which is scheduled to be activated on mainnet on Wednesday, March 13. They also discussed the scope of the next Ethereum upgrade, Pectra, as well as some research topics, one of which is block value standardization among CL clients.

Deneb

Ryan reminded everyone at the beginning of the call that the Dencun upgrade will be in less than Launched on Ethereum within a week. He also mentioned that for many Americans, it will begin the weekend of March 10, DST. Given that all ACD calls and upgrades are scheduled based on Coordinated Universal Time (UTC), which does not implement DST, those developers and those listening to the calls who are located outside the United States will need to adjust their schedules accordingly.

Some client teams on the call also shared that they will release recommended versions of software in the coming days to accommodate the Dencun upgrade, with Prysm, Lighthouse and Teku teams all expected to New version released before this weekend. Given that these versions are not required for upgrades, EF (Ethereum Foundation) protocol support lead Tim Beiko mentioned in a Zoom meeting chat that the Ethereum Foundation blog post compiling all Dencun-compatible versions will not be updated.

Chris Hager from the Flashbots team shared a quick update on MEV-Boost software readiness. Hager confirmed that MEV-Boost version 1.7, released last week, is stable and can be used by validator node operators. Flashbots builder software for Deneb is still in development and expected to be completed and merged sometime this week, he said. Regarding validators’ readiness for the upgrade, Hager expressed concern that not enough validators appear to have updated their MEV-Boost software to accommodate the Dencun upgrade. After double-checking his data, Hager said that roughly 50% of validators connected to Flashbots relays are using the latest MEV-Boost version, v1.7.

Beiko added that his source of information, Metrika and Ethernets, both show that about 50% of Ethereum nodes appear to be ready for the Dencun upgrade. Beiko also expressed his desire for a data tool that could track the readiness of validator nodes for the upgrade, not just all Ethereum nodes.

Electra

Ethereum developers discuss four code changes related to Pectra upgrade .

EIP 7459

The first is Ethereum Improvement Proposal (EIP) 7549, which enables CL clients to more efficiently aggregate votes for blocks (also known as attestations). Developer Consent PreviousRecommendation that EIP 7549 be included in Pectra. Teku developer Mikhail Kalinin shared further analysis on how EIP 7549 will be implemented on Ethereum and suggested some trade-offs or "negative impacts" that may be introduced as a result of the code changes. Ryan suggested that Kalinin summarize his proposed changes to the CL specification directly on GitHub for further feedback and review.

Prysm developer Terence Tsao said that he agreed with Kalinin's proposed EIP 7549 implementation, but suggested that further documentation and specifications be provided for the Beacon API changes, which is consistent with EIP is required. "Nowadays, if you have 10 aggregators in the same slot, you need to sign 10 attestations, then with this change you only need to send one message, so you may need to do some Beacon API changes," Tsao said, adding, "I think this part probably needs more thought on how to change The Beacon API validator is integrated to solve this problem." As background, the Beacon API is a specification for CL that enables nodes to query the network and obtain information about the network status.

Reducing issuance

Then, EF researcher Ansgar Dietrichs shared his thoughts on how to reduce issuance by reducing network A quick update on the proposal to reduce the issuance of staking rewards. He said that since the last ACDC conference call Since the proposal, "feedback from the community has been mixed." He reiterated that the proposal would be a small code change that could be included in a last-minute Electra upgrade by June or July, assuming the mainnet undergoes a hard fork in October. However, Dietrichs also said that conversations are "ongoing," meaning the idea needs to be discussed further before a decision is made.

EIP 7547

Third, EF researcher Mike NeuderProposed EIP 7547, including a list for further discussion. He said a second breakout session to discuss the "exact characteristics" of the EIP design would be useful and he was considering organizing one next Friday, March 15. He also mentioned that the EIP has a dedicated Discord channel called "Inclusion List" that people interested in learning more about the proposal or asking questions should use. Tsao also stated that since February 16th the first time it was included Since the inventory breakout meeting, the specifications for the proposal have been largely fleshed out. “I think the specification is probably about 75% complete,” Tsao said, adding that there are some other components of the specification that need improvement, such as changes to the execution API and specifications around honest validators.

EIP 7251

Finally, Lighthouse developer Mark Mackey expressed his support for EIP 7251 , the maximum effective balance (maxEB) is increased. "We've almost prototyped it in Lighthouse. There's still some work to be done on the spec, but it doesn't really look like a lot of work, and considering the size of the validator set is a bit of a ticking time bomb, we've proposed releasing Tune suggestions, release changes are always controversial, so there's no guarantee the community will accept it. If they don't like it, then the only thing we can really do is maxEB," Mackey said. Ryan said the main resistance to incorporating maxEB into Electra was due to the complexity of the code changes, as expressed in previous calls with the Prysm team. “Potuz,” an anonymous developer on the Prysm team, said in a Zoom meeting chat that his team will review the EIP again and reassess the complexity of the proposal. Ryan asked account teams to prepare for the next ACDC call in two weeks to make a "firm decision" on EIPs 7547 and 7251.

Key Manager API Standardization

EF Developer Operations (DevOps) Engineer Barnabas Busa explains that all CL clients all appear to have slightly different methods of generating validator keys, which are the cryptographic keys required to operate and revoke validators. There is some API called "Keymanager API" that can help Validator node operators perform key management and join and exit validators. Busa explained that subtle differences between clients when it comes to returning values for this API do make testing API endpoints difficult. He also mentioned that his team has started basic testing of hybrid validators, meaning validator node operators use a different client for their beacon nodes than the validator client. Beacon nodes are clients that maintain the CL state but do not manage the key pairs required by validators to participate in consensus. Validator clients are clients that utilize key pairs to generate blocks and sign proofs on the chain. Ryan suggested that Busa start a documentation or pull request with a proposal to standardize the key manager API. Developers on the call also support further testing to ensure the hybrid validator works on all CL client combinations.

Block Value Beacon API Standardization

A person named "Dustin" Nimbus developers also standardized the CL representation of the Beacon API endpoints "productBlockV3" and "getBlockRewards" Worry. Dustin explained that some areas of the Beacon API are not clearly defined and "not universally implemented" among clients. Specifically, when it comes to endpoints that should return block values, the calculation should at least include the change in validator balances before and after the proposed block. However, the specification does not detail whether clients should include rewards and penalties for changes in a validator's balance due to the actions of another validator. These include, for example, simultaneous committee duty awards or penalties, proposer or certifier self-reductions, and whistleblower awards. Ryan agrees that instructions should be added to the Beacon API. However, other developers on the call, including Radosław Kapka and Potuz from the Prysm team, were less confident. Potuz expressed concern that the number of people using these endpoints is small and able to use their own tools to normalize block values from different CL clients. "I don't even understand why we would agree to support this if consumers are restricted. I would try to look at these markets and see if we can actually send this work to the people using these endpoints instead of ourselves ," said Potuz.

Nimbus developer Jacek Sieka refuted this view, saying that due to the existence of the "productBlockV3" endpoint, developers need to resolve inconsistencies between clients or deprecate it. Endpoint, use "V4" instead. Furthermore, Sieka added: "I think this endpoint is just very basic functionality. If we envision a future where we have multiple block sources and you need to compare them, then this makes sense. It's that simple." Ryan advised Dustin Create a proposal to standardize V3 and the "getBlockRewards" endpoint. After the proposal is created, the account team will revisit whether to continue supporting them.

The rest

Potuz flagged two projects for further developer feedback and discuss. The first one is about the current late block that is not specified in the engine APIExecution Layer (EL) client behavior, this API specifies the communication between EL and CL. “If this could be specified in the engine API, it would make it easier for us when reorganizing later blocks,” Potuz said. The second item Potuz flagged was regarding his analysis of the Proposer Builder Separation (ePBS) payload upgrade, an upgrade that would eliminate the need for trusted relays on Ethereum. Potuz requested relevant analysis and More feedback on other ePBS design constraints.

Finally, Pooja Ranjan from the Ethereum Cat Herder team announced a project called "Women in the Ethereum Protocol (WiEP)'s new working group is established. WiEP is a new organization from the Ethereum Foundation dedicated to encouraging and developing more female Ethereum protocol developers. Ranjan said the group will hold an hour-long webinar on March 8 will discuss with several female Ethereum protocol contributors.

Ryan then noted that he will be taking a three-month break starting on April 1. In his absence, EF Fellow Alex Stokes will moderate the ACDC call.