A few reflections on the lattice vs. hash-only debate that our recent Aerie post sparked: 1. Cryptographic ossification for blockchains was never safe. Until the day we know with certainty that P ≠ NP, that finding short vectors in lattices is intractable, that Keccak effectively behaves like a random oracle in deployed SNARKs, and that every single bug has been eliminated from our codebases, blockchains cannot ossify. That is simply not how safe systems are built. Issues will arise, and the system will have to respond. It’s a double standard to reject lattices because blockchains are hard to upgrade if lattices break, while counting on upgrades if AI breaks your hash function or finds a critical zkVM bug. The best counterargument is that hash-only designs are more agile: if your hash function breaks, just swap out the hash. But we must aspire to a higher level of agility than this. Indeed, as I cover next, if SNARK recursion itself turns out to degrade security, the proposed hash-only blockchain designs would need to be rethought from the ground up. 2. The real security debate is not lattices vs. hashes — it is lattices vs. building everything on SNARK recursion. That’s because “hash-only” is not really hash-only: it rests on hashes plus the soundness of deep SNARK recursion. Ethereum’s roadmap relies on exactly that: hash-based aggregation needs recursion to keep up with a slot’s worth of signatures, and EIP-8288 would send other signature schemes and users’ own proofs through the same recursive pipeline. In contrast, Aerie proves a slot’s worth of signatures on one laptop without any recursion. All deployed post-quantum SNARKs rely on the Random Oracle Methodology (via Fiat–Shamir) to establish their security. This is an idealization we know fails in the real world: we have explicit counterexamples where “SNARKs” coming out of this methodology are totally insecure when instantiated with any concrete hash function. We generally ignore these counterexamples in part because they only arise when proving contrived, self-referential statements about the very hash function used by the SNARK verifier. But proving statements about the verifier’s own hash function is the exact thing you do in SNARK recursion. That’s why the security of recursive SNARKs can’t be established even in the random oracle model. On top of that, the standard security proofs for recursion (in other models) suffer an “extractor runtime” blowup that is exponential in the recursion depth, suggesting that security may degrade as more recursion is applied. Yet Ethereum’s own EIP-8288 enables unlimited-depth recursion, even as it lists soundness of recursive SNARKs as a trust assumption. Proofs in more idealized models avoid the blowup, but they mainly tell us that an attack on SNARK recursion would have to exploit the concrete hash function, which is exactly what the Fiat–Shamir attacks above do. To be clear, we don’t know of any outright attacks on SNARK recursion, and I very much hope it is secure. But some of us who have studied the question have a lingering sense that an attack may be possible in some settings. And if AI is going to supercharge cryptanalysis, there is no reason to expect it to spare Fiat–Shamir for SNARKs, let alone SNARK recursion, both of which have had far less scrutiny than lattices. So, I do not concede that a “recursion everywhere” hash-only approach is clearly more conservative than one built on standard lattice assumptions. 3. “Just wrap everything in a hash-based SNARK” (like EIP-8288) faces challenges. Aggregating signatures and proofs off-chain into a single block-level proof is a powerful design independent of the hash-only vs. lattice debate, and I am not telling people to avoid it. But claiming, as Vitalik Buterin did this week, that users can run whatever cryptography they want locally and wrap it in a client-side leanVM proof glosses over major hurdles. For example, leanVM today is a minimal VM designed almost entirely to prove hash-based signatures and recursion, not general-purpose computation. And binary-field SNARKs like leanVM remain slow at proving the integer multiplications that lattice cryptography does en masse. I am optimistic that many of these zkVM challenges can be met (including via my own work, binary-field Twist and Shout, which are now implemented in Magnetar). But regardless, if lattices can make aggregation simpler and faster, then they should be leveraged. We need to be agile no matter what. 4. For chains whose reason for existence is privacy, I truly struggle to understand the pushback. Public-key encryption (and fast single-server PIR) cannot be built from hashes alone, at least not in any black-box way. If lattices break, it is going to be very, very hard for these chains to provide acceptable levels of privacy and functionality. For a project whose entire reason for existence is privacy, a loss of confidentiality is an existential failure. Next to that, a second signature upgrade (after the first one, from elliptic curves alone to, hopefully, a hybrid lattice scheme) is easy. Summary: We don’t know for sure what is secure and what isn’t. We are all weighing unquantifiable risks against each other, and we do not need to agree on a total order on them. But hash-only solutions face many open engineering challenges, and they are not more “conservative” in the way some have argued. Some of those challenges are entirely prosaic and have nothing to do with bugs or cryptography, like hardware support for custom schemes whose hash function is still undecided. I hope we can overcome those challenges within the appropriate timelines, but they must be acknowledged and portrayed realistically. Overall, cryptographic agility and defense in depth (e.g., hybrid signatures) are the answer, which is why we are building both lattice-Jolt and hash-Jolt. In practice, the positions are less polarized than social media discourse suggests: for example, StarkWare is working to make Falcon verification cheap (falcon.provably.fast/), which is great to see. Here is the (apparently) controversial take I am sticking to: Conditioned on agility, whenever lattices make systems simpler or more functional, we should embrace them rather than default to “hash-only” designs. Lattices are what the rest of the world will depend on, with decades of study and hardening behind them, and at the system level, less functional often means less secure. Where hash-only designs are just as simple and functional, by all means use them.

.@apolynya is back with updated thoughts on ZK. One line stood out: “The potential impact of ZKPs supercedes that of all blockchains.” Early signs say he’s right. Our upcoming 2026 ZK Industry Report with @zeroknowledgefm surveys adoption across categories beyond blockchains.

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.

Most chains scale by asking you to trust more. zkSYS is built to do the opposite. The new testnet update covers Airbender proving, compact Syscoin DA, a lighter Gateway, full local verification, and post-quantum smart accounts. More scale. Less trust. Try now: • Portal: portal.tanenbaum.io/bridge • Explorer: explorer-zk.tanenbaum.io/ • ChainList: chainlist.org/chain/57057 Full update: syscoin.org/news/zksys-updat…

New post on EthResear.ch! Validator Redirected Revenue By: - clesaege 🔗 ethresear.ch/t/25248 Highlights: - Ethereum faces a persistent coordination failure: many ecosystem improvements are public goods, so voluntary funding tends to underprovide them, creating deadweight loss and harming long-term competitiveness. - Validators are structurally aligned with ecosystem growth (more usage → more demand for blockspace → more ETH burn/value), but they still get stuck in a prisoner’s-dilemma equilibrium where they hesitate to contribute unless others also commit. - The proposal adds a protocol-level mechanism where validators signal a redirect rate: if a majority (e.g., 51%) supports a non-zero rate, that rate becomes mandatory for all validators, solving intra-validator free-riding; the rate is capped (suggested max 10%, min 0%). - Validators also signal preferred funding recipients and allocations; execution clients aggregate these into a “splitter” contract using a king-of-the-hill / Condorcet-winner style process with simple protocol choices (KEEP vs CHANGE), aiming to minimize governance overhead (“set and forget”). - Key open risks include validator cartelization (majority could redirect funds to themselves), principal–agent problems (staking operators controlling votes vs delegators’ preferences), and the possibility that willingness to redirect rewards is interpreted as evidence issuance could be reduced. ELI5: Ethereum needs shared things (like security tools and maintenance) that help everyone, but it’s hard to get people to voluntarily pay because each person hopes others will cover the cost (the “free-rider” problem). This article suggests a built-in way for Ethereum validators (the people who earn staking rewards) to collectively agree to donate a small, capped slice of their rewards to fund important ecosystem work. Validators would also collectively choose where the money goes using a simple voting/competition process, so funding can happen without lots of meetings or bureaucracy—while still acknowledging risks like validators teaming up (cartels) or staking companies voting in their own interest instead of users’.