lean Ethereum Part 5: Devnets & Upgrade Coordination with Will and Raúl
Wednesday, 18 March 2026 · 2 min read · Listen to the episode ↗
In the fifth episode of Lean Ethereum, Will Cochran and Raúl Kripalani discuss crucial advancements in Ethereum, including the implementation of post-quantum signatures and snark aggregation. They emphasize the necessity of upgrade coordination and collaboration within the Ethereum development community, highlighting the transition from DevNet Zero to DevNet Four. Additionally, the conversations cover bandwidth optimization, the importance of signature size reduction, and the introduction of ETHP2P for enhanced network performance, all pivotal for the future of blockchain technology.
In the fifth episode of the Lean Ethereum mini-series, Will Cochran and Raúl Kripalani from the Ethereum Foundation discuss the integration of post-quantum signatures, snark aggregation, and the Lean VM stack into Ethereum clients. They emphasize the importance of human and networking layers for Lean Ethereum and share their backgrounds in networking, protocols, and architecture.
The conversation highlights the collaboration required among different layers of Ethereum development, particularly in coordinating client efforts and the social aspects of development. They explore Ethereum's scaling journey, the need for post-quantum security, and the iterative process of integrating new technologies. The lean Ethereum bootstrapping process, initiated through community discussions, is introduced, focusing on creating actionable specifications.
The structured approach to developing Ethereum specifications is discussed, with Tomah leading efforts for a lean, executable specification. They outline the progression from DevNet Zero to DevNet Four, emphasizing signature aggregation and the goal of a cohesive Ethereum network addressing consensus and execution. Key concepts such as fork choice and finality are examined, along with the challenges of changing fundamental elements like signature size.
The Lean ethos prioritizes simplicity and optimality, fostering collaboration with various organizations. The conversation addresses the complexities of achieving faster finality and ongoing research into alternative methods while maintaining moderate bandwidth requirements for decentralization and accessibility. They note that Ethereum currently experiences underutilization of bandwidth, with usage spikes during block and adaptation propagation.
The size of signatures is discussed, with efforts to reduce XMSS signatures from 3 kilobytes to 1 kilobyte, aiming for an ideal Maximum Transmission Unit (MTU) size under 1.2 kilobytes. Smaller signature sizes are crucial for reducing fragmentation and potential packet loss, minimizing round trip latency. Pipelining is emphasized to ensure a fast, fully utilized network, with proposed network topologies for aggregating leaf signatures from validators.
The introduction of latency along the critical path and the role of pipelining in managing larger signatures are explored. Structured grid topologies for deterministic routing are discussed, along with the importance of redundancy in network nodes to prevent single points of failure. Co-design between cryptography, signature aggregation teams, and the DevNet team is highlighted, with structured weekly calls facilitating communication.
Lean metrics aim to establish client-agnostic performance measurements, focusing on observability and performance in signature aggregation. Resource optimization is critical, with discussions on metrics such as signatures aggregated per second and network capacity. Finality in signature propagation and block agreement is addressed, with aspirations for faster finality and ongoing research by the protocol consensus team.
The upcoming Cambridge meetup for researchers aims to enhance collaboration, with Raúl presenting ETHP2P, a new networking stack designed specifically for Ethereum. ETHP2P will replace the current Lippi2p stack, optimizing for Ethereum's network workloads and introducing new topologies and features. Improvements in the transport layer with QUIC as the primary transport are also discussed, enhancing data flow between the execution and consensus layers.
This summary was generated from the episode transcript and can contain mistakes.