At ACDE #239, Ethereum core developers joined to discuss new ideas for Hegota, finalise improvements intended for Devnet 6, and assess the progress of Glamsterdam Devnet. A large portion of the discussion centred on maintaining alignment between specs, tests, and client implementations in front of the impending Alpha 11 release, with Devnet 6 tentatively expected to launch next week.

Developers examined improvements to repricing ideas, thought about a trustless log indexing strategy for Hegota, and moved EIP-7645 closer to inclusion in addition to Glamsterdam talks. The current community vote to choose Glamsterdam's mascot and encrypted mempool efforts were also discussed at the conference.

• Glamsterdam Updates
• Hegota Updates

Glamsterdam Updates

Devnet 6: Targeted for Launch Next Week

Although certain Prysm and Nimbus nodes are still out while teams continue to work through synchronisation issues, Barnabas reported that Glamsterdam Devnet 5 is currently operating with about 95% participation. The majority of client teams have already turned their attention to Devnet 6, which is anticipated to launch in the middle of next week.

By the end of Monday, June 22, developers want to have Alpha 11 specifications ready, and execution-layer tests should also be accessible at that time. While consensus-layer work is still awaiting reliable container support for SSZ, Devnet 6 is anticipated to incorporate all Glamsterdam execution-layer EIPs.

EIP-8282: Discussed & Moved Toward Glamsterdam Inclusion

EIP-8282, which was discussed earlier this week during ACDT and is currently anticipated to be added to Glamsterdam, was also reviewed on the call. The plan deals with the situation where builders and validators join the same queue, which could lead to denial-of-service assaults. While execution-layer support is still awaiting a client implementation, two consensus-layer implementations are already in progress. According to Barnabas, testing needs to start as soon as an EL implementation is accessible.

Snap2: Proposed for Inclusion in a Future Meta EIP

Developers also talked about Snap2, an optional networking upgrade intended to facilitate state fix. It upgrades Ethereum's snapshot sync protocol, allowing nodes to retrieve and repair missing state data more efficiently. Teams from Geth, Besu, and Nethermind are already making headway on development projects, even though none of the clients has finished implementation work. Regardless of whether Snap2 eventually ships with a particular fork, Toni Wahrstös proposed that it be included in either the Glamsterdam or Hegota Meta EIP.

EIP-7928: Discussion Continued, Final Decision Deferred

After that, EIP-7928 and an open question about state access restructuring came into focus. Ignacio's recommendations sparked the conversation, which Dragan Rakita later developed. Rakita suggested postponing account loading until checks like call stack restrictions and balance validations were finished. Dragan claims that delaying these account loads could help clients avoid needless work and implement small speed improvements.

Client teams' opinions were divided. Several other teams admitted that they had not yet thoroughly examined the edge situation, and Besu engineers stated that putting the suggested improvements into practice would add more complexity. Developers decided to give Toni's current proposal a soft commitment instead of making a choice right away, giving teams another day to consider Dragan's other design. In order to keep Devnet 6 specs on track, a final decision is anticipated asynchronously before the end of the week.

Repricing EIPs: Updates Accepted for Devnet 6

Maria Silva gave multiple updates on the repricing initiatives. She attested to the fact that EIP-7904, which investigated compute repricing, has now been transformed into an informational EIP. All clients are already above the target threshold of 100 million gas per second, according to benchmarking results, negating the need for compute repricing as part of Glamsterdam. The proposal will still be part of the Meta EIP, but its major purpose will be to chronicle the process and its findings.

Maria also provided EIP-7937 with two updates. In order to ensure that gas flows back to the source from which it was extracted rather than being automatically deposited into the reservoir, the initial modification involves returning the refunded state gas. By charging state gas unconditionally and refunding it later if the account already exists, the second explains charging behaviour during CREATE operations. The modifications will be incorporated right away and added to Devnet 6 as no concerns were voiced during the call.

EIP-8038 and EIP-2780 updates were also provided. Both suggestions have already been shared for evaluation in revised versions, and it seems that the majority of the issues have been handled. For these more recent iterations, the STEEL team has begun putting specs and tests into place. Unless more issues arise, these will also be included in Devnet 6.

In addition, Barnabas called attention to a temporary pull request that introduced two new system contracts for EIP-8282 and urged developers working at the execution layer to use them for diagnostic testing until the final version is ready.

As the Glamsterdam conversation came to an end, developers examined a bug fix that affected exiting builders. Exited builders may receive top-up deposits right away under the current behaviour, and they may also take up space in the validator withdrawal queue. When a fresh top-up deposit is made to an existing builder, the suggested patch resets the withdrawability delay to 8,192 epochs, or around 36 days.

Teams anticipate releasing Alpha 11 on Monday, allowing Devnet 6 to launch as early as Wednesday of next week, assuming that all outstanding pull requests are merged by Friday.

Hegota Updates

The next step for developers was to submit ideas for inclusion in Hegota.

EIP-8304: Presented for Consideration

EIP-8304, a Trustless Log Transaction Index designed to offer verifiable proofs for transaction and event queries, was presented by Zsolt Felfölli. The plan is intended to replace EIP-7745, which was previously thought to be too complicated and challenging to implement. EIP-8304 builds sorted index tables for individual blocks and keeps their roots in a system contract rather than constructing a massive protocol-level index. Then, using zero-knowledge proofs, larger aggregated indexes can be produced outside and combined.

Felfiči claims that the method could facilitate trustless APIs, effective inclusion and exclusion proofs, and possibly enhance cross-chain communication by simplifying the process of proving recent events from a different chain. The presentation's benchmarking results seemed encouraging.

While average proof creation times are still about 17 milliseconds, searches covering roughly 25 million blocks are said to finish in less than a second. Exclusion proofs were calculated to be between 25 and 30 kilobytes for on-chain apps and roughly 70 kilobytes for API usage. Block-level table generation can be parallelised, which lessens the workload for protocol participants, and was estimated at less than 2% of block processing time. During the conversation, no issues were brought up.

EIP-7645: Advanced to Consideration for Inclusion

EIP-7645, which suggests aliasing ORIGIN to SENDER in an attempt to reduce long-standing technical debt surrounding tx.origin, was also discussed during the session. Account abstraction, according to Cyrus, distinguishes between the account initiating execution and the entity sponsoring transaction fees, making assumptions about tx.origin increasingly untrustworthy. He also mentioned current conversations in Ethereum's Future AA channels and pointed out that origin-based behaviour is already being leveraged in applications today. Developers decided to place EIP-7645 into consideration-for-inclusion status for Hegota after hearing no concerns.

EIP-2488: Discussion Postponed

The proposal of EIP-2488, which calls for the deprecation of the CALLCODE opcode, was unable to present the notion, discussion of the proposal was delayed.

Encrypted Mempools & Mascot Voting

Before ending the session, developers emphasised continued work on encrypted mempools and urged a more thorough examination of EIP-8105 and EIP-8184. Contributors working on the proposals have attached rewards for reviewers and are actively looking for input.

The gathering concluded with a lighthearted conversation about Glamsterdam's mascot. The Polar Bear is currently in second place, and the Flamingo is topping the community vote. Although the general opinion went toward keeping the process open to community engagement, several engineers made lighthearted suggestions that client teams should have the final word.

That's all from ACD meeting today. You can follow notes from earlier meetings here.

If you find any issues in this article or notice missing information, please feel free to reach out at team@etherworld.co for clarifications or updates.

To promote your Web3 articles, events, and projects, you may reach out anytime via EtherWorld PR for submissions and collaboration.

To follow blockchain news, track Ethereum protocol progress, and read our latest stories, subscribe to our weekly today.

Related Articles

1. Hsiao-Wei Wang Steps Down From Ethereum Foundation Leadership
2. An Overview of WYRIWE (What You Read Is What You Execute)
3. Ethereum Coalition Pushes for Encrypted Mempool in Upcoming Hardfork
4. EF President Aya Miyaguchi Outlines New EF Direction
5. Ethereum Foundation Advances Cross-Chain Intents with LI.FI Launch