Written by: Christine Kim
Compiled by: Luccy, BlockBeats
Editor’s Note: Ethereum All Core Developers Consensus Call (ACDC) every two weeks Held once to discuss and coordinate changes to the Ethereum Consensus Layer (CL). This is the 134th ACDC conference call. At this conference, developers discussed the implementation details and technical challenges of multiple key EIPs, including EIP 7549, EIP 7251, EIP 6110, EIP 7688, etc.
Additionally, developers also discussed in depth the implementation of PeerDAS, a data availability sampling technology expected to significantly improve the Ethereum network’s ability to support rollups and their data availability requirements. During the meeting, a proposal was made to split Pectra into two hard forks for upgrade, and issues of activation time and interdependence of different EIPs were discussed.
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 May 30, 2024, Ethereum developers gathered on Zoom to participate All Core Developers Consensus (ACDC) call #134 meeting. The ACDC call is a biweekly series hosted by Ethereum Foundation researcher Alex Stokes where developers discuss and coordinate changes to the Ethereum Consensus Layer (CL, also known as the Beacon Chain). This week, developers discuss experiences and open issues since the launch of Pectra Devnet 0. They also debated the feasibility of expanding the scope of the Pectra upgrade to include peerDAS and SSZ container code changes.
Based on the launch of Pectra on Devnet 0, the client team has agreed to keep the validation behavior affected by EIP 7549 unchanged during the hard fork activation. At a previous ACDC meeting, developers considered various options to ensure that the impact of EIP 7549 would not result in a large number of invalid verifications during the fork. To avoid complicating upgrades further, the client team decided to activate EIP 7549 in the same epoch as other Pectra EIPs, without changing validation behavior before and after the fork.
Regarding EIP 7251, developers are still unsure whether merges of staked ETH should be allowed to be triggered from the execution layer (EL). This would be an ideal feature for staking pools like Lido, so that the merging of stakes does not have to rely on node operators but can be achieved through smart contracts. Stokes recommended checking the progress of clients implementing validator staking merges in a few weeks before deciding whether they should be EL or CL operations.
The developers then discussed some unanswered questions regarding the final confirmation of validator deposits under EIP 6110. Teku developer Mikhail Kalinin summarized the directions for addressing these issues in a GitHub comment before the conference. Lighthouse developer "sean" raised a question about versioning of the "GetPayloadBodies" request in the Engine API. Stokes recommended that developers post their comments in a pull request created for the issue on GitHub.
Nimbus developer Etan Kissling suggested a small change to the implementation of EIP 7549. "This is about the stability of the generalized index. When we add a new field in the middle of the container, subsequent fields will be assigned a new index, which will break the proof based on EIP 4788 at the execution level (EL), and some Misleading. … Therefore, I recommend moving the new field to the end to avoid both problems," Kissling explained. There were no objections to this change. Stokes recommends developers check Kissling's pull request on GitHub.
Another change to EIP 7549 proposed at the meeting would be to design requests and other requests triggered by EL as appenders to EL blocks. Regarding this change, Kalinin said: "In my opinion, this is a very good design solution, it simplifies EL... and it is basically an alternative to generalized requests in the execution layer block." Stokes It is recommended that this topic be discussed again at the next CL meeting so that developers have more time to review the proposal on GitHub.
There are some EIPs focused on the Consensus Layer (CL) that have not been officially included or excluded from the Pectra upgrade. At this week’s meeting, developers discussed whether to add EIP 7688 and PeerDAS to Pectra. EIP 7688 adopts part of the "StableContainer" SSZ data structure to ensure forward compatibility of EIP 7549's attestation changes. As a background introduction, SSZ is a data structure used in CL, and developers want to use it in the execution layer (EL) as well. For more information on the SSZ transition, see previous meeting minutes. PeerDAS is an implementation of data availability sampling on Ethereum that is expected to greatly enhance the network's ability to support rollups and its data availability requirements. In practice, PeerDAS is expected to increase the number of blob transactions that validators can attach to a block from 3 to 64 or more per block.
Barnabas Busa, developer operations engineer at the Ethereum Foundation, said developers have launched an early iteration of PeerDAS on a development network. "I think a lot of clients have discovered a lot of problems, and when we make substantial progress, we can always restart a new development network," Busa said. Stokes asked developers if they would be willing to add PeerDAS to Pectra without causing upgrade delays.
A developer nicknamed "Nishant" has revived the suggestion to separate PeerDAS activation from activation of other EIPs in Pectra. Although this is feasible, another developer who goes by the nickname "atd" emphasized that if developers plan to activate these upgrades one after another in a short period of time, users still need to upgrade their software at the same time. atd said: "I think it's a little crazy to do a fork two months after another upgrade. If we're going to coordinate everyone to upgrade the client, we don't want to have everyone upgrade the client two months later. That would , not even one release cycle is enough."
atd added that in his opinion, PeerDAS is the most "interesting" code change in the EIP included and discussed in Pectra. Stokes said he hopes to include PeerDAS in Pectra even if it causes upgrade delays. Grandine client developer Saulius Grigaitis proposed removing EIP 7549 and EIP 7688 from Pectra in favor of PeerDAS. This prompted discussion of the implementation details of EIP 7688. The developers were unable to agree on the code changes and the proposal will be revisited at the next ACDC meeting.
On the topic of PeerDAS, developers continue to weigh the idea of splitting Pectra into two hard forks. Ethereum Foundation developer options engineer Parithosh Jayanthi warned that if developers split Pectra into two upgrades, they must be careful not to add more EIPs in future Pectra Part 2. Jayanthi said: “One thing I want to mention is that if we consider splitting into two forks, we have to be very careful not to add more new EIPs in the next fork. I don’t know if we will be able to do it To this point. If we can commit to something a year or a year and a half ago, because we are always coming up with new ideas and priorities are changing and so on."
Continue to discuss the two upgrades. Thoughts, Lighthouse developer "sean" said he did not foresee many interdependencies between PeerDAS and the current Pectra EIP list. Therefore, the two can be done separately and later easily merged when the developer becomes more confident in their implementation. Atd agreed, arguing that there would not be much risk in merging Pectra EIP, PeerDAS and EIP 7688 after developing and testing these separately.
Busa recommends continuing to test Pectra EIP and PeerDAS, but designing code changes so that PeerDAS is activated one epoch later than Pectra EIP on the development and test networks. He noted that this is already how testing of Pectra EIP and PeerDAS is done on Devnet 0. "There's really nothing that needs to be changed," Busa said, adding that if PeerDAS isn't ready when the other Pectra EIPs are, developers can remove that code change from the upgrade. This raises several questions about how different activation epochs of PeerDAS affect the work of client teams. In the end, the developers agreed to continue developing PeerDAS and Pectra EIP, but the premise was that PeerDAS would be activated in different epochs on the development network and the test network.
As mentioned above, the developers agreed to leave the discussion of whether EIP 7688 will be included in Pectra until the next ACDC call.
The above is the detailed content of Summary of the latest meeting of Ethereum core developers: Pectra upgrade may be divided into two hard forks. For more information, please follow other related articles on the PHP Chinese website!
![[Web front-end] Node.js quick start](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
