Highlights from the All Core Developers Execution (ACDE) Call #230

Ethereum core developers came together for ACDE #230 with a clear sense of where attention needs to be focused next. Two parallel tracks framed the discussion.

The first was Glamsterdam Devnet progress and overall execution layer readiness. Client teams walked through optimization efforts, networking safeguards, and scope discipline as they prepare the next round of testing.

The second was the ongoing debate around Hegotá headliners, where competing proposals are now narrowing toward a decision point. In particular, encrypted mempool designs are drawing serious consideration, raising deeper questions about MEV mitigation and censorship resistance.

• Glamsterdam Updates
• Hegota Updates

Glamsterdam Updates

Glamsterdam discussions covered a wide range of execution layer topics, but they all pointed in the same direction. The focus right now is stability and performance, not expansion.

BAL Devnet 2 recently went live. As expected with early testing networks, the rollout was not perfectly smooth. Some clients initially faced issues tied to specific EIPs. However, those issues appear to be stabilizing. Consensus across participating nodes is functioning well, and teams are now pushing harder on stress testing.

To simulate realistic network conditions, developers are aggressively spamming transactions. EVM fuzzing is being used to catch edge cases in opcode behavior. Uniswap style transactions are being injected to generate meaningful state changes. This is less about checking boxes and more about observing how clients behave under sustained load.

Client teams emphasized that parallel execution, parallel state root computation, and batched state reads are top priorities. Some clients are experimenting with multiple configurations. One configuration runs without optimizations. Another enables parallel execution but skips state prefetching. A third enables both.

The goal is empirical measurement. Ethereum is not simply assuming improvements will help. It is benchmarking them across implementations. And importantly, several developers signaled that this optimization work should take precedence over adding new EIPs.

While EIP-8037, which adjusts state creation gas costs, and EIP-7954, which increases maximum contract size, were mentioned as potential candidates, there was clear resistance to expanding scope too quickly.

Behind the scenes, the EF testing team is refactoring gas repricing infrastructure. The aim is to make gas tests parameterized so repricing proposals can be evaluated more efficiently. That work is heavy and time consuming. Expanding DevNet scope during this refactor risks slowing overall progress.

In other words, Devnet 3 is likely to remain lean. Another key Glamsterdam topic was EIP-8024. A proposed change to push postfix encoding raised concerns, especially around code size impact and downstream tooling implications. The room leaned toward rejecting that change. A separate proposal to simplify decoding through branchless normalization received more favorable reactions, since it reduces complexity without introducing broader ripple effects.

One of the most important conversations involved eth/70, which introduces partial block receipt lists. This networking upgrade addresses a subtle but potentially important issue. Under certain conditions, blocks with extremely large receipt data can stress snap sync and DevP2P bandwidth limits. While such cases are rare, they become more relevant as gas limits gradually increase.

Technically, eth/70 does not require a hard fork to roll out. It is a networking layer change. However, including it within Glamsterdam provides coordination certainty. Everyone upgrades together, and adoption becomes easier to reason about.

The gas limit conversation tied everything together. If Ethereum wants to push gas limits higher in the future, networking propagation must remain healthy. Some developers argued that the edge case risk is overstated. Others warned against knowingly expanding limits before networking upgrades are broadly adopted.

Hegota Updates

The proposal window for execution layer headliners has closed. Four candidates are now under consideration.

1. Frame Transactions
2. SSZ execution blocks
3. Universal Enshrined Encrypted Mempool
4. LUCID Encrypted Mempool

LUCID proposes an encrypted mempool architecture built around what proponents describe as a censorship resistance trinity.

• Proposer builder separation ensures block building competition.
• Forced inclusion lists ensure certain transactions cannot be censored.
• And encrypted mempool behavior prevents front running and sandwiching by hiding transaction details until inclusion.

The system encrypts transactions before they enter the mempool. Builders commit to transaction hashes. Once a beacon block is attested, symmetric keys are released, allowing transactions to be decrypted and ordered at the top of the next block based on fee bids.

Unlike some earlier proposals, LUCID keeps decryption largely outside the core protocol. The encryption envelope is standardized, but key management is flexible. A sender could decrypt their own transaction. A threshold committee could handle decryption. A specialized service could act as decryptor.

Frame Transactions were also discussed briefly. The proposal continues to evolve. Adjustments have been made to the approve mechanism to ensure compatibility with proxy based smart accounts. Opcode refinements are being explored to simplify transaction parameter access. Implementation has begun in execution specs, and test fixtures are under development.

Frame Transactions feel more incremental compared to encrypted mempool proposals. They extend transaction structure rather than attempting to fundamentally alter ordering visibility.

Client teams have now been asked to submit ranked preferences across the headliner options, including the possibility of no headliner. Those rankings will guide the next phase of decision making.

If you find any issues in this blog or notice any missing information, please feel free to reach out at yash@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.

Related Articles

1. Highlights of Ethereum's All Core Devs Meeting (ACDC) #153
2. Highlights of Ethereum's All Core Devs Meeting (ACDE) #207
3. Highlights of Ethereum's All Core Devs Meeting (ACDC) #152
4. Highlights of Ethereum's All Core Devs Meeting (ACDE) #206
5. Highlights of Ethereum's All Core Devs Meeting (ACDE) #205

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