Lodestar

Lodestar's Glamsterdam headliner vision

Lodestar's vision for Glamsterdam's headliner is an opportunity to optimize Ethereum's slot structuring, separate consensus and execution concerns, and ensure we set ourselves up for future success in shortening slot times with data on overhead concerns.

Lodestar's Glamsterdam headliner vision

Lodestar's vision for Glamsterdam's headliner is an opportunity to optimize Ethereum's slot structuring, separate consensus and execution concerns, and ensure we set ourselves up for future success in shortening slot times with data on overhead concerns. We believe that shortening slot times is a great win for user experience (UX), but how we get there is also important.

In our proposal, we outline why using the slot time we have more efficiently is the first step to achieving the goal of shortening the length of slot times. Then, we outline the wins with EIP-7732 and why it matters. In addition, we can then parallelize development on both layers with an execution layer headliner.

Why we support EIP-7732

EIP-7732, also known as Execution Payload Block Separation (EPBS), achieves multiple goals, which we believe are worth the effort over competing headliners. These goals are:

  • Maximally efficient pipelining of slot operations.
  • Separate layer concerns between consensus beacon blocks/blobs and execution payloads.
  • Larger positive impact on the liveness/stability of Ethereum via extended validation timeframes and improved bandwidth utilization.
  • Allowing for the collection of real-world data to support the shortening of slot times.

Why is separating beacon blocks and execution payloads important?

Every second counts. Minimizing the dependencies of operations will help us better optimize, structure and utilize every millisecond of a slot operation effectively. We do this by decoupling execution validation from consensus validation, both logically and temporally. Currently, we have to acquire multiple pieces of data, which vary in size, thus affecting transmission times:

  • Consensus block
  • Execution payload
  • Blobs

Then, we run the state transition function (processing the execution payload transactions to determine validity) so we can attest to the head block. As payloads get larger, the overhead on transmission and validation grows in time duration. Separating the dependencies unlocks massive efficiencies in how we utilize every millisecond of a slot.

With EPBS, attestations can be submitted if the consensus block is valid without the dependencies of all the pieces of data listed above, nor having to acquire and check validity of the execution payload itself (we remove the ExecutionPayload field from the BeaconBlockBody and replace it with a signed commitment as SignedExecutionPayloadHeader).

Consensus blocks are much smaller and faster to propagate and validate. Therefore, attestations can then be done earlier in the slot. Attestations will no longer need to be thrown out with invalid execution payloads, which minimize liveness failures if non-valid execution payloads are no longer being produced. For a network that majorily depends on out-of-protocol block production rather than local block building, there is a larger surface of possible malfunctions that can occur, risking Ethereum's liveness capabilities. This could be from builders submitting invalid blocks and/or trusted relays having various issues ranging from failure to demote invalid block builders to infrastructure failures:

EPBS ensures trustless builder accountability and helps to remove another vector for liveness failure.

In Delayed Execution (EIP-7886), the consensus block, execution payload and blobs still have the same propagation deadline, while EPBS, has different propagation deadlines and start times, which lead to better utilization of the slot.

If we also want to keep Ethereum as decentralized as possible, we need to consider supporting lower resourced nodes both in terms of compute and bandwidth. Supporting EPBS means we can restructure operators to efficiently use slots, reducing peak bandwidth requirements. Execution payloads can be transmitted over extended timeframes and executed with more time. Bandwidth is harder to scale due to physical network infrastructure requirements, so we must optimize its usage for scaling the network.

Invasiveness of shortening slot times

EIP-7782 for six second slot times are much more invasive on the client as it touches more aspects of the codebase than EPBS. There is also no compelling data at this point to show that client implementations can successfully upkeep a network like Ethereum mainnet that is now two times faster. Some clients may need to rework their architecture (such as their caches) to optimize for this future. Postponing EIP-7782 gives clients more time to ensure their clients are ready for this future.

We believe that data from the network and clients collected from restructuring the slot can inform us about changes we can make to the slot time in the H* hard fork.

Bonus integration of FOCIL?

Although we believe the priority on EPBS is higher than Fork-choice Enforced Inclusion Lists (FOCIL), research developments have allowed FOCIL to find a clean integration into EPBS. FOCIL can make a great non-headliner addition to Glamsterdam and is complimentary to the integration of EPBS. This would make for a great secondary goal to the headliner if achievable.

For those who are concerned about the degradating of UX due to increased average transaction inclusion time, there is a mitigation in the works for a dual-deadline PTC vote in EPBS where the Payload Timeliness Committee (PTC) observes for the availability of the payload first at four seconds and then for blob data availability at ten seconds.

Execution Layer Headliner: EIP-7919 Pureth

With EPBS, we can separate consensus and execution headliners for parallel workflows

If EPBS becomes the headliner for Glamsterdam, the work is scoped to be 100% for consensus layer clients. An added side benefit of this is testing for the most complex and impactful feature is constrained to consensus, minimizing coordination and testing surface overhead. This will then allow execution client teams to focus on their own main headliner which focuses mostly on execution.

We believe an execution headliner like EIP-7919 Pureth, will unlock massive UX benefits for infrastructure with minimal disruptions to EPBS implementation on the consensus layer. Pureth removes current issues with consuming chain data and includes a few minor tasks for consensus clients. These tasks include updating SSZ definitions for execution payload and helps future-proof changes to the beacon state container.

Other resources

There are multiple other benefits that we agree with which make EIP-7732 very appealing as a headliner for Glamsterdam. The resources are below for additional context:

Read next