Summary of the latest meeting of Ethereum core developers: Blob Gas added, Pectra code changes

Original title: "Ethereum All Core Developers Consensus Call #130 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 130th ACDC conference call. At the meeting, developers conducted in-depth discussions and decisions on Dencun upgrade action items, Pectra upgrade code changes, and light client development.

Developers discussed some problems that occurred in the Ethereum network and put forward targeted solutions and improvement suggestions. In addition, the developers looked ahead to future development plans and important matters. 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:

March 21, 2024, Ethereum Development People gathered on Zoom for the All Core Developers Consensus (ACDC) call #130 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 discussed unfinished business related to the Dencun upgrade, proposals for the Pectra upgrade, and improvements to the Ethereum network layer. The developers agreed to include EIP 7251 "Increase MAX_EFFECTIVE_Balance" in Pectra and continue to evaluate EIP 7547 "Inclusion lists" for potential inclusion in upgrades.

Dencun Action Project

Shared by Trenton Van Epps, community coordinator employed by the Ethereum Foundation A compilation of emotions from Ethereum protocol developers about the years of development leading up to the Dencun upgrade has been published on Mirror. Titled "Dencun Diaries," the compilation features the voices of more than 45 Ethereum developers and their thoughts on the successes and challenges of preparing for Dencun.

Van Epps said of the project: "I think this is a very useful resource. If you have been paying attention, you will know that I have previously contributed to the Merge upgrade and Beacon Chain The startup did something similar. So, this just adds to the historical record. Hopefully we start to build institutional memory of how the Ethereum core developers and the community around it operate. So, thank you to everyone who submitted . I think this is a good snapshot of emotion, and I hope we can move forward with continuous learning."

He also said that he was very concerned about the progress made in upgrading Dencun. Contributing Ethereum developers still have the opportunity to add their comments to Dencun's diary and contact him directly.

Then, Tim Beiko, Director of Protocol Support at the Ethereum Foundation, issued a call to all Dencun EIP authors to update their proposals on GitHub, updating the status to "Final" to indicate that their code changes have now been implemented on the Ethereum mainnet. The full list of EIPs requiring this status update can be found here.

Regarding the impact of the upgrade on Ethereum, Prysm developer Terence Tsao mentioned that he noticed an increase in the number of reorganized blocks, which means that on the network A block proposed but not included in the canonical chain of Ethereum blocks. Tsao said he is further investigating the cause of this behavior, and he speculates that the cause is related to the MEV builder specification.

Parithosh Jayanthi, developer operations engineer at the Ethereum Foundation, said that based on his team’s analysis of Dencun, they noticed that a small number of data blocks were delayed in arriving at the network, which was delayed. Four seconds enter a time slot. A timeslot is the 12-second interval during which validators on Ethereum are selected to propose blocks. Although the number of slowly arriving blocks is not high, Jayanthi said it is important to keep a close eye on this behavior. Prysm developer "Potuz" mentioned that one of the changes to the attestation inclusion timeline in the upgrade may exacerbate the metrics that nodes track resource usage. Teku developer Enrico Del Fante said his team is aware of the issue regarding higher-than-normal CPU and bandwidth usage and will include a solution to fix the issue in the next version of the Teku client.

Finally, Lodestar developer Gajinder Singh proposed a minor name change, changing the opcode "BLOBBASEFEE" to "BLOBBASEFEEPERGAS". "Basically making sure the units are more consistent with what they convey," said Singh. Ryan encouraged developers on the call, particularly the authors of EIP 4844, the author of the proposal to introduce data blocks, to review Singh's changes.

Censorship-resistant code changes

Ethereum Foundation security researcher Fredrik Svantes has shared a proposal to Implement the "get_Payload" request through the client to increase the value of the local building block by 10%. The developers added calculation of block value to the engine API in late 2022 via the “get_Payload” request. This is done so that validators can easily compare the value of local building blocks to the value of blocks built by third-party block builders. According to Svantes, 64% of builders are actively reviewing transactions in blocks. To encourage validators to propose locally built blocks, Svantes proposed increasing the value of local blocks by 10%. He added that he is working with the Ethereum Foundation’s testing team to ensure that these changes do not trigger any false alarms or disrupt existing testing infrastructure when testing client software.

Potuz pushed back against Svantes' suggestion, stating that block values should be configured by the client. "We should stop specifying these things. We should stop doing it in a coordinated way," Potuz said, adding: "I think clients should be free to set these things. They can be configured by the user, and we shouldn't have to do that on the actual We are afraid to act in order to achieve what we believe in." Other developers on the call, including Lodestar developer Phil Ngo and Lighthouse developer "Sean," agreed with Potuz.

"One reason for not setting it to 10% might be that it would be an unexpected situation, sort of taking advantage of the fact that the user might not be aware of this feature "A better approach, perhaps in Lighthouse, would be to require the user to set the value when using the builder. This would increase awareness of the flag rather than giving advice on what value it should be set to," Sean said.

The developers then discussed what kind of margin would encourage validators to choose local blocks over blocks built by builders. Since time on the conference call is limited, Ryan recommends moving on to other meeting agenda items.

Pectra Code Changes

Ryan started talking about the major code changes included in Electra The discussion focused on the two most dominant proposals, EIP 7251 and EIP 7547, which are leading the race. "We've talked about it back and forth. We had thought one or the other was buried, they've resurfaced at different times, but we've definitely gotten to the point where if we don't make a decision, we really need to make a decision soon. The intention is to have a functional prototype and development network for Electra at some point in May, we're shutting down at the end of March. So, I just want everyone to understand that these are medium sized projects, if not large projects that we can continue discussion, but we can't keep dragging this out for much longer. Otherwise, I think the default is 'no.' I think indecision is a decision in itself," Ryan said.

Inclusion list

Ryan then turned over to Ethereum Foundation researcher Mike Neuder, who is Led the preparation of EIP 7547, the inclusion lists (ILs), for Pectra's work. Neuder shared an update from a recent breakout session on ILs. A summary of the session can be found here. Singh, Sean and others on the call expressed support for including both ILs and EIP 7251, also known as MaxEB, in Pectra. One of the salient issues mentioned by Potuz regarding the IL specification is its impact on the inscribed account abstraction (AA). In the future, Ethereum developers plan to introduce enhanced flexibility for user-controlled Ethereum accounts, also known as externally owned accounts (EOAs), a process that may be complicated by the current design of ILs. The developers discussed ways to update the IL specification to make it more compatible with future AA code changes. The developers also discussed their initial efforts to implement ILs in their own clients for the first time, and the trade-offs of using the engine API in some cases. Neuder and Terence recommended discussing issues related to IL specifications at the next IL breakout session rather than discussing the technical details of ILs on a conference call.

MaxEB

The developers also discussed the readiness of MaxEB to be implemented in Pectra. Ngo shared an update from the latest MaxEB breakout session, which took place on Wednesday, March 20. A summary of the meeting can be found here. Lighthouse developer "ethDreamer" said that his team prefers to prioritize MaxEB, but is also willing to include both in Pectra. Based on his colleagues' assessment of MaxEB, Potuz said the Prysm team is confident that MaxEB can be implemented before the end of the year, which is the timeframe in which developers are trying to complete the Pectra upgrade.

Ryan reminded the developers on the conference call that in conjunction with the Pectra upgrade, they have committed to work on peerDAS, an initiative aimed at introducing Data availability sampling and code changes to safely increase Ethereum's data availability capacity by increasing the number of data blocks in each block. Ryan said: "I intuitively think that one of MaxEB or IL entering Electra may not have a big impact on the parallelism that can be used for peerDAS research and development, but if both exist at the same time, we are now starting to weigh that it may not really be possible to handle both at the same time. Three things."

However, developers on the conference call, such as Sean, Singh, Ngo, Lighthouse developer Age Manning and others, expressed support for including both MaxEB and ILs in Pectra. If developers still plan to launch Pectra on mainnet before the end of the year, Potuz strongly advises against including both. On the topic of ILs, Ryan asked if its implementation also places a heavy workload on the EL client team. Geth developer "Lightclient" said that from his perspective, the workload of implementing ILs is split 80/20 between the CL/EL client team. After more discussion among the developers on these two code changes, Beiko recommended continuing the inclusion of MaxEB in Pectra, while continuing further scoping of the ILs following further discussions between the EL and CL client teams to May contain ILs after upgrade. This means developers prioritize MaxEB over ILs. Ultimately, the developers agreed to adopt Beiko's strategy of including MaxEB in Pectra and revisiting the ILs within one to four weeks.

"My personal opinion is that these two things combined bring us into more complex territory than the upgrades we have discussed over the past few months. So to Be aware. I would also say at this moment that we are always very confident and excited about the complexity and there is still a lot of work to do," Ryan said in a final warning about the scope of Pectra. As in ACDC #129, after this week's meeting, Ryan will take three months off. Ethereum Foundation researcher Alex Stokes will host the ACDC call on his behalf.

Blob gas increase

After discussing maxEB and ILs, the developers discussed A proposal drafted by Ethereum Foundation researcher Ansgar Dietrichs to gradually increase the number of blobs in each block to a maximum of 16 within four months of the Pectra upgrade, taking it from 6 16. This increase will further reduce the cost of data availability and the cost of Layer 2 rollups built on Ethereum. Ryan expressed support for the proposal, provided three key conditions are met:

· Reliable data on blob performance.

· Activating EIP 7623 in Pectra, which limits the maximum block size.

· Further discussion on the exact mechanism by which time increases the number of blobs.

Ryan encouraged developers to share their thoughts on the proposal in the coming weeks.

Light client development

Nimbus developer Etan Kissling shared two articles with Impact CL Draft proposal related to standardized light client development. Sync committee penalties and light client data backfilling are two components of the light client roadmap that developers are working on in parallel with the Pectra upgrade. Kissling asked the CL client team for input on these components, specifically what impact the maxEB penalty condition would have on large validators participating in the synchronization committee. For background on the Sync Committee, read this article from the Ethereum Foundation.

Web Update

In terms of ongoing research projects, Manning shared a new An approach to annotation subnets (attnets), a network layer that enables validators to send and receive annotations. Although implementation is not urgent at this time, this backwards-compatibility proposal appears to provide optimizations for the network once peerDAS comes into effect.

Manning also proposed the implementation of new control messages to network peers that would "significantly reduce" node bandwidth. Manning said his team has begun testing "IDONTWANT" control messages and can be released independently, but it will require coordination across the network to start seeing the benefits of this change. He asked developers on the call to review the proposal and see if they would consider releasing the change together.

Finally, Manning raised the issue of deprecating complex in the libp2p library. Mplex is a stream multiplexer used to send multiple data streams over a communication link. Due to the deprecation of mplex, Manning said his team and other client teams are upgrading to a different stream multiplexer called yamux. Manning asked the client team about the status of the migration and whether complex was still being used. Representatives from the Teku and Lodestar teams said they are working hard on their yamux implementations but are not ready to switch from mplex yet.

「Original link‖