lean Ethereum

Justin Drake joins Bankless. Q-Day is no longer a sci-fi thought experiment. We get into: - When quantum becomes a real crypto threat - Bitcoin’s hardest post-quantum tradeoffs - Ethereum’s roadmap to survive it - Why Justin thinks quantum is also an opportunity - What AI changes about the cryptography race 📅 Monday, March 23 w/ @drakefjustin

x.com/i/article/2034…

x.com/i/article/2034…

@tkstanczak @0xValentinesXBT @DeanEigenmann We do not intend to move slowly.🫡

What does a zkVM designed specifically for Ethereum consensus look like? In this episode (4/6 of the @LeanEthereum miniseries), researchers from the Ethereum Foundation, Thomas Coratger (@tcoratger) and Emile, discuss with @nico_mnbl the design and implementation of leanVM, the minimal VM used for post-quantum signature aggregation. They cover: – Why leanVM uses a VM instead of fixed circuits to support flexible XMSS aggregation and recursive proof composition – The leanVM architecture: a minimal instruction set (4 opcodes) designed for simplicity and formal verification – The proving stack behind LeanVM: multilinear arithmetization, sum-check, and the Weir commitment scheme – Implementation details: CPU-optimized proving with Plonky3, SIMD techniques, and Poseidon2 hashing – Benchmarks and constraints around recursion and XMSS aggregation throughput They also discuss specification design, benchmarking methodology, and open questions around implementing post-quantum cryptography in Ethereum. Listen to the full episode. —-------------------- TIMECODES 03:36 Why LeanVM Was Chosen 07:50 LeanVM Minimalist Design 08:34 Simplicity Over Speed 19:34 Security and Field Selection 20:41 Performance and Aggregation Benchmarks 28:14 Ethereum Python Specification

Hash-based SNARKs are becoming central to Ethereum’s post-quantum roadmap, but how secure are they, really? In this episode (part 3 of the @leanEthereum miniseries), @nico_mnbl chats with @GiacomoFenzi and @asanso to examine the theory and security of post-quantum SNARKs. They cover: – The SNARK stack behind LeanVM (multilinear arithmetization + sum-check) – The $1M Proximity Gap Prize and the wave of new research it triggered – How recent results affect security margins for hash-based proof systems – Why Ethereum is moving toward provable security regimes for long-term protocol safety They also explore open problems in coding theory, list decoding, and hash-based proof systems. Listen to the full episode —----- TIMECODES 02:24 – Why Ethereum needs post-quantum SNARKs 03:30 – The LeanVM SNARK stack (multilinear + sum-check) 04:53 – The $1M Proximity Gap Prize 12:04 – The wave of new research papers 12:52 – Johnson bound vs capacity bound 21:24 – New attack analysis on deployed STARKs 27:07 – Why the 128-bit security threshold matters 30:26 – Open research questions in post-quantum SNARKs

@nic_carter straight-up complimenting @drakefjustin's new strawmap & Ethereum’s solid post-quantum roadmap in the pod—great contrast vs Bitcoin’s current path. Coherent PQ strategy FTW. 🔥

Introducing strawmap, a strawman roadmap by EF Protocol. Believe in something. Believe in an Ethereum strawmap. Who is this for? The document, available at strawmap[.]org, is intended for advanced readers. It is a dense and technical resource primarily for researchers, developers, and participants in Ethereum governance. Visit ethereum[.]org/roadmap for more introductory material. Accessible explainers unpacking the strawmap will follow soon™. What is the strawmap? The strawmap is an invitation to view L1 protocol upgrades through a holistic lens. By placing proposals on a single visual it provides a unified perspective on Ethereum L1 ambitions. The time horizon spans years, extending beyond the immediate focus of All Core Devs (ACD) and forkcast[.]org which typically cover only the next couple of forks. What are some of the highlights? The strawmap features five simple north stars, presented as black boxes on the right: → fast L1: fast UX, via short slots and finality in seconds → gigagas L1: 1 gigagas/sec (10K TPS), via zkEVMs and real-time proving → teragas L2: 1 gigabyte/sec (10M TPS), via data availability sampling → post quantum L1: durable cryptography, via hash-based schemes → private L1: first-class privacy, via shielded ETH transfers What is the origin story? The strawman roadmap originated as a discussion starter at an EF workshop in Jan 2026, partly motivated by a desire to integrate lean Ethereum with shorter-term initiatives. Upgrade dependencies and fork constraints became particularly effective at surfacing valuable discussion topics. The strawman is now shared publicly in a spirit of proactive transparency and accelerationism. Why the "strawmap" name? "Strawmap" is a portmanteau of "strawman" and "roadmap". The strawman qualifier is deliberate for two reasons: 1. It acknowledges the limits of drafting a roadmap in a highly decentralized ecosystem. An "official" roadmap reflecting all Ethereum stakeholders is effectively impossible. Rough consensus is fundamentally an emergent, continuous, and inherent uncertain process. 2. It underscores the document's status as a work-in-progress. Although it originated within the EF Protocol cluster, there are competing views held among its 100 members, not to mention a rich diversity of non-EFer views. The strawmap is not a prediction. It is an accelerationist coordination tool, sketching one reasonably coherent path among millions of possible outcomes. What is the strawmap time frame? The strawmap focuses on forks extending through the end of the decade. It outlines seven forks by 2029 based on a rough cadence of one fork every six months. While grounded in current expectations, these timelines should be treated with healthy skepticism. The current draft assumes human-first development. AI-driven development and formal verification could significantly compress schedules. What do the letters on top represent? The strawmap is organized as a timeline, with forks progressing from left to right. Consensus layer forks follow a star-based naming scheme with incrementing first letters: Altair, Bellatrix, Capella, Deneb, Electra, Fulu, etc. Upcoming forks such as Glamsterdam and Hegotá have finalized names. Other forks, like I* and J*, have placeholder names (with I* pronounced "I star"). What do the colors and arrows represent? Upgrades are grouped into three color-coded horizontal layers: consensus (CL), data (DL), execution (EL). Dark boxes denote headliners (see below), grey boxes indicate offchain upgrades, and black boxes represent north stars. An explanatory legend appears at the bottom. Within each layer, upgrades are further organized by theme and sub-theme. Arrows signal hard technical dependencies or natural upgrade progressions. Underlined text in boxes links to relevant EIPs and write-ups. What are headliners? Headliners are particularly prominent and ambitious upgrades. To maintain a fast fork cadence, the modern ACD process limits itself to one consensus and one execution headliner per fork. For example, in Glamsterdam, these headliners are ePBS and BALs, respectively. (L* is an exceptional fork, displaying two headliners tied to the bigger lean consensus fork. Lean consensus landing in L* would be a fateful coincidence.) Will the strawmap evolve? Yes, the strawmap is a living and malleable document. It will evolve alongside community feedback, R&D advancements, and governance. Expect at least quarterly updates, with the latest revision date noted on the document. Can I share feedback? Yes, feedback is actively encouraged. The EF Protocol strawmap is maintained by the EF Architecture team: @adietrichs, @barnabemonnot, @fradamt, @drakefjustin. Each has open DMs and can be reached at first.name@ethereum[.]org. General inquiries can be sent to strawmap@ethereum[.]org.

Quantum computers (if and when they do in fact get powerful enough) would break Ethereum’s BLS signatures, so what can be done now to mitigate? For the second instalment of the @leanEthereum miniseries. Nico sat down with Benedikt Wagner and Dmitry Khovratovich (@Khovr) from the @ethereumfndn We unpack leanSig, a hash-based multi-signature scheme designed to replace BLS in a post-quantum world. Listen to the full episode here on X. —--------- TIMECODES 3:22 Post-quantum signatures 3:35 Why replace BLS 4:45 Hash-based signatures (LeanSig design) 9:12 Size vs performance trade-off 11:31 SNARK-based aggregation 12:37 Circuit constraints & encoding 17:33 Aborting Random Oracle 19:47 Signature size & tight security 22:26 Random Oracle vs Standard Model 25:23 Poseidon hash function 28:24 Poseidon Initiative 31:06 Billion-Dollar Merkle Tree

Ethereum is starting from the endgame. Episode 4 of TheCoordinate is a deep dive into Lean Ethereum: a clean-slate rethink of consensus, execution, and data availability. I sat down with @drakefjustin from @ethereumfndn to unpack: > need for the rewrite, > rewrite items: post-quantum security + fast finality, > endgame finality (3-slot -> 2-slot -> maybe 1-slot), > slot anatomy, networking constraints, and the "SOL slots" meme, > real-time ZK proving changing the execution roadmap, > censorship resistance with FOSSIL, > role of L2s in the world of Lean Ethereum, > incentives across proposer, builder, prover, includer, attester. If you’re building on @ethereum or trying to understand where the base layer is headed, this one is for you. This is Episode 4 of TheCoordinate. Hope you enjoy it! ------------------------------- Timestamps: 0:00 Intro: digital intelligence needs digital institutions 0:30 The big questions: Lean Ethereum, consensus/execution, post-quantum 1:25 Why Ethereum needs an endgame mindset (and a clean-slate approach) 3:30 The two “rewrite-class” items: post-quantum security + fast finality 5:52 Beamchain → Lean Consensus → Lean Ethereum (expands beyond consensus) 6:34 ZK EVM + real-time proving within a slot → “10,000 TPS” target 10:10 “SOL slots”: pushing slot duration toward speed-of-light constraints 11:09 3-slot finality (3SF) → endgame finality (2-slot / 1-slot paths) 18:19 eFP2P: erasure-coded gossip, bandwidth efficiency, scaling blobs 26:21 FOSSIL today: inclusion lists + opening includers beyond validators 39:09 Lean VM: minimal ZKVM 51:04 XMSS explained: Merkle signatures, 2^32 leaves, statefulness tradeoff 1:00:36 Rollups: 99.9% throughput on L2s + “native rollups” 1:06:53 Economics: roles (builder/prover/includer/attester), proving costs, stake capping

How Ethereum is preparing for a post-quantum future with @coinage_media Thanks for the amazing discussion! youtube.com/watch?v=LFlWO3…