I updated my 2023 roadmap diagram to overlay where the items that were there sit in the current Strawmap ( strawmap.org/ ). In general, a lot of overlap, but: * Some things got reshuffled in order (eg. quantum safety up-prioritized) * Some things deprioritized (eg. VDFs; many EVM improvements) * Some things replaced with superior constructions (eg. Verkle -> unified BT -> PBT; state expiry -> new state types) What's most striking, however, is that some completely new things are in the strawmap that are NOT in this diagram, because they were not in the 2023 roadmap at all. These reflect changing priorities. Notably: * First-class attention to strong privacy. This covers: keyed nonces and recent roots, aspects of FOCIL, lean privacy pool & wormholes * Aggressive scaling in the context of post-quantum. This covers: leanSPHINCS signatures and aggregation, zkzk frames (see ethereum-magicians.org/t/eip… ) * Lean-ification of the spec, to assist in formal verification (full FV of everything is only possible because of modern AI) * Blob and gas futures (this idea just didn't exist back in 2023) * Native rollups (SNARKs were nowhere near mature enough to even consider this back in 2023) * A more open design space for the "future of the EVM". zkzk frames already implies that the protocol will expose to users some ISA that's not the EVM - current leading candidates are leanISA and RISC-V. These ISAs are more simple, modern and efficient than the EVM. Once they're there, why not expose them to developers everywhere? (And then, why not turn the EVM into being an IR on top of that ISA, instead of an enshrined feature massively complicating the base protocol?) Though much of the deeper exploration here is too early even for the strawmap. * New state types are not just a replacement for expiry, they're a fundamentally different paradigm to how Ethereum does scaling A common theme in scaling, found in both state types and zkzk frames (both new ideas), is that instead of trying to maximally scale ALL ethereum activity, we try to create specialized mechanisms that have more restrictive properties that make them more scaling-friendly, while supporting the heaviest loads incurred by users and applications today (eg. token transfers, swaps) and tomorrow (eg. privacy protocols). The other common theme is treating STARKs and AI-accelerated FV as first-class objects, that we are okay betting the technical future of Ethereum on. There are recursive STARKs in many layers of the protocol, one particular primitive (the "aggregate to union verified dependencies" primitive) is expected to be used in *three* places in the protocol: EL, CL and DL. This can only be safe with formal verification, which is itself only feasible with modern AI tools. In general, many steps forward in maturity. And a huge amount of hard work by many dozens of Ethereum researchers and developers on all of these features. Ethereum will be quantum-safe. Ethereum will put users' privacy first. Ethereum will be secure. Ethereum will be censorship-resistant. Ethereum will be highly performant and scalable while satisfying the above. And Ethereum will be Lean.

What will the financial system of tomorrow look like? According to Nick Kerigan, our Head of Innovation, three transformative forces are converging: tokenisation, AI and quantum computing. While technology will reshape how finance operates, some fundamentals will remain unchanged. Trust, high-quality data and common standards will continue to underpin any future financial system. What comes next will combine new capabilities with trusted foundations to deliver better outcomes for customers. Read Nick's latest perspective: lnkd.in/eir-ZgQJ #Innovation #AI #Tokenisation #Payments

We’re proud to announce the launch of the Bitcoin Security Consortium, in partnership with BlackRock, Fidelity, Block, and more. Together we’ll support the long-term security of the Bitcoin network. Quantum computing is coming. Crypto needs to be ready.

⚛️ Most of the industry has not priced this in yet: Quantum-resistant signatures and threshold signing (what people loosely call MPC) do not play well together. And the places we lean on threshold signing hardest are exactly where post-quantum cryptography helps least. - Threshold signing lets a group share one key so any agreed subset produces a single, ordinary signature, with no one ever holding the whole key. It is load-bearing infrastructure for custody today. But most post-quantum families were never designed for it. As we migrate to PQC, a capability the ecosystem depends on does not migrate with it for free. - Hash-based signatures simply cannot be thresholdized. This should bother the Bitcoin and Ethereum crowd. Hash-based signatures are the most conservative, most trusted post-quantum option we have, exactly the profile a chain wants for a multi-decade guarantee. And they do not thresholdize. There is no structure to split a hash-based key and recombine it into one signature. It is a pity, because this is the family the most security-conservative chains would naturally reach for. - ML-DSA is the one that gives us a path Outside the blockchain world, ML-DSA (FIPS 204) will be the default signature standard. It is also the one post-quantum scheme that looks like it can support threshold signing at all. At first glance it looks easy, because its response is linear in the secret: z = mask + challenge × secret Same shape that makes threshold Schnorr and BLS clean. But here, it is not that clean. And that is where it gets interesting. - The real obstacle is rejection sampling, not linearity ML-DSA keeps signatures small with a tiny mask. Too small to fully hide the secret, so the naive z leaks a little of the key on every signature. The fix is to throw away the leaky attempts. It's called "rejection sampling". Alone, trivial. You check in private and bin the bad ones unseen. Split across a group, it breaks. The reject decision depends on the combined z, so everyone reveals their piece before anyone can judge the attempt, and the binned attempts are precisely the leaky ones. The decision needs the total, the total needs the reveal, and the reveal is a leak. A second check on the commitment w protects the other half of the key (s2) and has the same problem. - There is a solution, honest about its limits A recent paper solves this for up to six signers. The core idea: make every piece safe to reveal before it is revealed. Four moves: 1) Give each signer a short key piece it owns, so it can run rejection sampling privately. 2) Split rejection into a private per-signer stage plus a public stage on the total. 3) Add noise to w so the one unavoidable early reveal leaks nothing. 4) Use a ball-shaped safe zone plus parallel attempts to keep the success rate practical. The output is a standard ML-DSA signature, accepted by an unmodified verifier, no trusted setup, secure even if all but one signer is compromised. Honest caveats: it scales to about six signers before cost explodes, and the signatures are distinguishable from single-signer ones. We wanted a clean, secure setup, we end up with something as clunky as ECDSA threshold setups... - Two things are true at once. ML-DSA gives us a real path to post-quantum threshold signing for the classical world. The most conservative post-quantum choice, hash-based, gives us none. And none of this changes the thing I keep repeating: threshold signing distributes keys, not trust. If the endpoints can be compromised, splitting a key across them just distributes the attack surface. Post-quantum or not, key generation and signing still belong on certified secure hardware with a trusted display. WYSIWYS does not become optional because the primitive got quantum-resistant. For the deep version, with the actual geometry and worked examples, @conordeegan wrote the best explainer I have seen: conor.computer/blog/threshol…