# Besu Glamsterdam Position Paper

The Besu team views Glamsterdam as Ethereum's critical next step toward credible neutrality and execution scalability. While Fusaka and subsequent BPO forks will deliver L2 scaling increases, they do not address Ethereum's fundamental credible neutrality challenges. Glamsterdam provides our opportunity to correct course while setting the foundation for real-time ZK proving on L1.

## Our Three-Priority Framework for Glamsterdam:

**Scale L1, Scale L2, Improve UX**

L1 scaling through parallelization enables L2 scaling through faster proving, which ultimately delivers better UX through reduced costs and latency. Scalability powers growth; Censorship Resistance protects it.

## Glamsterdam Should Include:

### Censorship Resistance through Proposer-Builder Separation and FOCIL

Ethereum has been doing a great job of scaling (blob limits increased, PeerDAS, gas limits increased) which we will continue, while theming this hardfork on Censorship Resistance.

**ePBS** deserves inclusion in Glamsterdam. Since it is a consensus layer concern, the Besu team defers to our CL colleagues on implementation specifics- but we view ePBS as a thoroughly vetted design that has been under consideration long enough to warrant confidence.

ePBS provides superior delayed execution design (itself a major boon to scalability) without introducing a "free DA" problem that alternative approaches risk. Crucially, some form of delayed execution is foundational for encrypted mempool designs—the next frontier in MEV mitigation that we [flagged in our Fusaka planning](
https://hackmd.io/x_Nq1lLyRdyN3FhD0sPmFw).

**FOCIL**: We strongly encourage FOCIL's inclusion if bandwidth permits, and the time is now to fully enshrine as many forms of Censorship Resistance as possible. We look at FOCIL as not only a form of Censorship Resistance, but as a scalabilty improvement. FOCILs decoupling of block building and censorship resistance may help revitalize a public mempool currently starved for transaction volume.

### Performance and Parallelization through Block Access Lists

**EIP-7928 (Block Access Lists)** represents the highest-leverage execution optimization available to us. While different execution clients have adopted various parallelization strategies, none achieve perfect parallelism—Besu typically achieves 60-70% parallel execution on average.

EIP-7928 provides all execution clients with everything needed for perfectly parallel execution. This trades larger blocks for faster block execution, but the deeper value lies in its ZK proving implications: perfectly parallel execution enables parallelizable tracing, which dramatically accelerates proving performance.

**This is our foundation for real-time proving.** Having this infrastructure in place shortens the critical path to real-time ZK proving on L1, which ultimately benefits both L1 performance and L2 proving efficiency.

## What We're Deferring:

### Slot Restructuring
**Defer - until after ePBS and FOCIL have shipped.** This is an important protocol upgrade, but the timing is not quite right to pursue it now. Slot restructuring will have broad impact through both the CL protocol and each clients implementation. We also believe that it is dangerous to add additional duties to the slot (such as ePBS or FOCIL) after having shortened it. It is easier to compress an existing design than it is to insert new duties into an already shortened slot time.

### EOF
**Defer - existing DFI rationale unchanged.** The perceived issues that led to deferring EOF in previous planning cycles have not materially shifted, and it contributes to UX more than scaling. The merit of EOF has not changed, and Besu's implementation remains complete and ready to ship.

### 64-bit Mode
**Defer - optimization without bottleneck relief.** While likely beneficial for performance, this represents an optimization rather than addressing an existing bottleneck. Block Access Lists provide higher leverage optimization that directly addresses current parallelization limitations.

### Pureth
**Defer - or ship piecemeal.** Pureth's proving requirements burden trusted RPC providers unnecessarily, and we already have `getProof` for applications that need Merkle proofs. That being said, should Pureth be broken down into smaller pieces, and not require consensus breaking changes, there is no reason it could not be pursued on its own schedule.

## Denied for Inclusion

### Delayed Execution
**Not needed if ePBS is included.** ePBS provides the delayed execution properties we need without the additional complexity of standalone delayed execution designs. Should ePBS not be included in Glamsterdam, we will revisit this decision, and would want to see improvement to the design to disallow invalid transactions in valid blocks.

## Looking Forward

This upgrade should advance L1 capabilities, enable L2 innovation, and ultimately improve end-user experience.

Glamsterdam's focus on credible neutrality and parallelization creates the technical foundations for Ethereum's next phase of growth. Real-time proving becomes practical, ePBS's delayed execution unlocks threshold encryption schemes needed for encrypted mempools. Censorship Resistance becomes robust.

*Two hardforks a year.*

— The Besu Team