WEBVTT Automatically timed original source text; AI narration; timing not manually listen-through verified. 00:00:00.000 --> 00:00:03.060 The Ethereum Perspective on Post-Quantum Cryptography. 00:00:03.280 --> 00:00:12.600 Notes from a talk by Antonio Sanso at the Post-Quantum Bitcoin Workshop at Stanford, 28 August 2026, written by Localhost Research. 00:00:12.980 --> 00:00:14.560 This is an AI recording. 00:00:14.900 --> 00:00:19.860 Find the original text and more information on btctranscripts.com. 00:00:20.040 --> 00:00:23.600 Ethereum's Three Layers — All Depend on Elliptic Curves 00:00:23.600 --> 00:00:25.220 Layer: Current cryptography. 00:00:26.400 --> 00:00:29.660 Execution: secp256k1. 00:00:29.980 --> 00:00:32.700 Consensus: BLS12-381. 00:00:33.120 --> 00:00:36.460 Data availability sampling: BLS12-381. 00:00:36.760 --> 00:00:45.140 (The DA layer is more explicit in Ethereum than in Bitcoin. Each layer has many client implementations, all sharing the underlying EC assumptions.) 00:00:46.280 --> 00:00:48.680 The Roadmap (with a governance caveat) 00:00:49.020 --> 00:00:59.140 Caveat: this "strawman" reflects the Ethereum Foundation's vision, not a guarantee — Ethereum governance is complicated, and this is an attempt to guide the community. 00:00:59.620 --> 00:01:02.980 Currently shipping Glamsterdam; introducing frame transactions. 00:01:03.600 --> 00:01:10.960 LeanVM: where STARK-based aggregation of signatures for all three layers will live. Plan is to ship leanSPHINCS. 00:01:11.380 --> 00:01:19.000 Direction: account abstraction + no precompiles + aligned architecture across consensus/DA. 00:01:19.660 --> 00:01:29.120 Going all-in on hash-based signatures. No lattices. Rationale (from Q&A below): minimal assumptions, alignment across all three layers. 00:01:30.660 --> 00:01:33.380 Hash Function Choice: Dropping Poseidon 00:01:34.060 --> 00:01:38.520 For years Ethereum pushed Poseidon (Sanso personally was not a fan). 00:01:38.840 --> 00:01:47.480 A recent paper, Flock, means Poseidon is no longer needed: hundreds of thousands of signatures can be proven in zk quickly with standard hashes. 00:01:47.880 --> 00:01:51.640 Poseidon isn't considered broken — it's just no longer worth the risk. 00:01:52.780 --> 00:01:56.280 Stateful for Consensus, Stateless for Transactions 00:01:56.900 --> 00:02:06.860 Consensus layer: stateful signatures. Interesting fit, because signing many blocks already gets you slashed — the protocol punishes state reuse anyway. 00:02:07.560 --> 00:02:11.040 Transaction layer: stateless — a SPHINCS+ variant. 00:02:11.460 --> 00:02:18.780 SPHINCS+ has many tunable parameters trading off signature size, hash counts for signing/verification, and key lifetime. 00:02:19.200 --> 00:02:33.020 SPHINCS+ isn't truly stateless — the signature budget is just so large (2⁶⁴) that it behaves statelessly. That budget was recognized as bigger than needed: most ETH addresses have sent fewer than 3,000 transactions. 00:02:33.340 --> 00:02:39.420 But shrinking budgets can push signing cost too high (e.g., 1.45B hashes in one example). 00:02:40.390 --> 00:02:43.570 SPHINCS-G and Hardware Wallet Signing 00:02:43.570 --> 00:02:51.130 Baseline SPHINCS on a Ledger Nano S Plus: 47.5s to sign — not ideal but better than before. 00:02:51.530 --> 00:02:57.690 SPHINCS-G (recent): 2²⁴ signature budget, 32-byte public keys. 00:02:58.210 --> 00:03:07.670 Key insight: parts of SPHINCS are public and can be computed outside the hardware wallet's secure element — only the Winternitz chains touching secrets must stay inside. 00:03:08.190 --> 00:03:15.770 Requires lots of host↔device interaction; precomputation happens offline ahead of signing, plus grinding at signing time. 00:03:15.970 --> 00:03:26.450 This changes the SPHINCS security proof, which will need to be adapted (they're precomputing different parts of the XMSS/hypertree — conceptually similar to hypertree pruning). 00:03:27.000 --> 00:03:27.940 Path forward: 00:03:28.180 --> 00:03:31.700 Formalize and analyze the SPHINCS-G construction properly 00:03:32.020 --> 00:03:38.640 Experiment with non-standard, more aggressive SPHINCS variants (non-conventional WOTS+C / FORS+C) 00:03:38.900 --> 00:03:41.580 Formally verify the signature contracts 00:03:42.700 --> 00:03:43.320 Q&A 00:03:43.320 --> 00:03:49.600 Q: Would this be an online/offline signature — always requiring preprocessing, or one-time? 00:03:49.800 --> 00:03:52.420 There are many different scenarios under consideration. 00:03:52.940 --> 00:03:57.200 Q: If the host selects the randomizer, can't it bias the result? 00:03:57.540 --> 00:04:01.300 Yes — they're aware of this and adapting the design to account for it. 00:04:02.020 --> 00:04:05.040 Q: Why hash-based given the tradeoff space? 00:04:05.280 --> 00:04:17.420 The required assumptions are minimal, plus alignment across all three layers. And there's growing research on thresholdization/MPC for hash-based schemes, so the picture there isn't as dark as feared. 00:04:17.880 --> 00:04:20.620 Q: Where are signatures verified? 00:04:20.980 --> 00:04:44.040 At the account abstraction level, with an aggregator at the mempool level calling the STARK precompile. Without a precompile it's not too expensive since cost is amortized via aggregation. (For comparison: ML-DSA without a precompile would cost 8–10M gas — though people have implemented MPC on Dilithium, and that may be acceptable if you really care about a given transaction.) 00:04:44.560 --> 00:04:50.430 Q: Exact parameter choices? SPHINCS+C optimizations? 00:04:50.950 --> 00:05:02.090 Parameters not yet picked — and they matter less as long as aggregation and outsourced signing exist. Amortization plays the biggest role. Announcement coming soon. 00:05:02.430 --> 00:05:12.230 Other notes: a new actor will be responsible for aggregation, aggregating every few milliseconds; there was discussion of enshrining the aggregation scheme.