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

Compiled by: Luccy, BlockBeats

The Ethereum Core Developer Consensus Call (ACDC) is held regularly to discuss and coordinate changes to the Ethereum Consensus Layer (CL) Adjustment. The most recent ACDC call was the 129th, where developers shared the latest progress on preparations for the Dencun upgrade and discussed the scope and EIP of Pectra, the next Ethereum upgrade.

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

On March 7, 2024, Ethereum developers gathered on Zoom to participate 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 start of the conference call that the Dencun upgrade would go live on Ethereum in less than a week. He also mentioned that for many Americans, it would begin this weekend on March 10th, with the start of DST. Given that all ACD conference calls and upgrades are scheduled based on Coordinated Universal Time (UTC) without observing DST, developers and call participants outside the U.S. will need to adjust their schedules accordingly.

During the conference call, some client teams revealed that they plan to release updated versions of the software in the coming days to coincide with the Dencun upgrade. The Prysm, Lighthouse and Teku teams are expected to release new versions by the end of the week. Although these updated versions are not mandatory upgrades, the Ethereum Foundation’s Tim Beiko noted during the Zoom meeting that they will not be updating the blog post summarizing all Dencun-compatible versions.

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 further pointed out that his sources Metrika and Ethernets show that about half of the Ethereum nodes are ready to upgrade to Dencun. He also expressed hope for a data tool that can track the readiness of validator nodes for upgrades, not just all Ethereum nodes.

Electra

Ethereum developers discussed four code changes related to the 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). The developers agree with previous recommendations to incorporate EIP 7549 into 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 he agrees with Kalinin's proposed implementation of EIP 7549, but recommends further documentation and specification for the Beacon API changes that are necessary with this EIP. "Today, 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 make some Beacon API changes," Tsao said, adding Dao, "I think this part may need more thought on how to change the Beacon API validator integration to solve this problem." As background, the Beacon API is a specification of CL that enables nodes to query the network and obtain information about the status of the network.

Reduce Issuance

Then, EF researcher Ansgar Dietrichs shared a quick update on his proposal to reduce staking rewards by lowering network issuance. He said there has been "mixed feedback from the community" since the proposal was presented during the last ACDC call. 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 Neuder presented EIP 7547, containing lists 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 said that the specifications for the proposal have been largely fleshed out since the first inclusion list breakout meeting on February 16. “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 support for EIP 7251, which increases the maximum effective balance (maxEB). "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 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 explained that all CL clients seem to have a slightly different method of generating validator keys, and the validator The key is the cryptographic key required to operate and revoke the validator. There are APIs called "Key Manager APIs" that help validator node operators with key management and joining and exiting 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 Nimbus developer whose screen name is "Dustin" also expressed concerns about the CL standardization of the Beacon API endpoints "productBlockV3" and "getBlockRewards". 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 the endpoint and use "V4" ”. 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. Once 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 discussion. The first is about the execution layer (EL) client behavior of late blocks that is not currently specified in the engine API that specifies 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 additional feedback on the analysis and other ePBS design limitations.

Finally, Pooja Ranjan from the Ethereum Cat Herder group announced the formation of a new working group called Women in the Ethereum Protocol (WiEP). WiEP is a new organization from the Ethereum Foundation dedicated to encouraging and developing more female Ethereum protocol developers. Ranjan said the group will host an hour-long webinar on March 8 to 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.

The above is the detailed content of Summary of the latest meeting of Ethereum core developers: final progress of Dencun upgrade and discussion of Pectra upgrade scope. For more information, please follow other related articles on the PHP Chinese website!