smstack.eth

engineer @sunnyside_io | @DecipherGlobal | ko @organ_mo

[smstack.eth @StackDigest]

https://t.co/6tXjp6Q512

[Justin Thaler @SuccinctJT]

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 (https://t.co/FM68hmkqRx), 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.

[Derek Chiang | Ethlabs @decentrek]

I made a visualization of EIP-8288 aka "recursive mempool aggregation," my new favorite EIP of all time because it perfectly encapsulates the thesis of the "cryptographic world computer" -- a system whose scalability *increases*, not decreases, with the level of decentralization.

In a previous tweet I explained how EIP-8288 achieved this seemingly impossible feat, but one gif is worth a thousand words.

Essentially, EIP-8288 leverages Ethereum's decentralized mempool as a parallel ZK proving cluster. Clients send signatures and proofs to the mempool, which over multiple rounds progressively aggregate them into fewer and fewer proofs, until the block builder finally aggregates them into one SINGLE proof.

This design accomplishes five things at once:

- The more nodes we add to the decentralized mempool, the more signatures/proofs Ethereum can process as a whole. This is obvious if you look at the animation and imagine more nodes in the mempool ring, which would "fan out" to more signatures/proofs.

- By aggregating over multiple rounds (aka "recursive aggregation"), the bandwidth consumed by proofs remains constant for each node even as the network processes more proofs. As a result, the network stays decentralized even as capacity increases.

- By aggregating proofs before one final aggregation by the builder, as opposed to requiring the builder to aggregate everything, the network can process more proofs without increasing hardware requirements for the builder.

- By aggregating everything to a single block-level proof, validators can verify thousands of signatures/proofs by checking just one aggregated proof. Hardware requirements for validators can therefore stay low, keeping the network decentralized.

- By aggregating not just native signatures but also STARKs, Ethereum can support any signature scheme by wrapping them in STARKs.

So once again, this is how Ethereum will:

- scale to process tens of thousands of PQ and private transactions per second

- charge a tiny amount of gas to validate each txn, even though the original signature/proof may be huge (up to hundreds of KBs in size)

- all while decentralizing even MORE.

You are not bullish enough.

[smstack.eth @StackDigest]

100%, these days such claims sound to me like a bet that Ethereum won’t be able to prepare for PQ era - which won’t happen

[Mislav | Ethlabs @ox_shaman]

PQ resistance is *not* a moat. Essentially everyone will have it and claims of PQ superiority over Ethereum from certain chains are intellectually dishonest arguments.

[smstack.eth @StackDigest]

@EliBenSasson How about the signature algorithms? Do you also think we should go for hash-based ones like SPHINCS+, not ML-DSA or Falcon?

[smstack.eth @StackDigest]

@gballet Hmm yeah that would be ideal but also sounds like we have lots of things to improve then

[smstack.eth @StackDigest]

@URozmej @dapplion Agreed, still there are new mechanisms coming out, and I guess there are bunch of rooms for improvement there

[smstack.eth @StackDigest]

@URozmej @dapplion Would this mean that we need sth more than EIP-7907 where rules are more strict in ZK-fied world?

[smstack.eth @StackDigest]

Have to agree with this!

[Justin Thaler @SuccinctJT]

11/ Private transfers need public-key encryption, which provably can’t be built from hashes alone. So avoiding lattices in signatures and proofs doesn’t remove the dependence on lattices. It just trades their benefits for a false sense of security.

[smstack.eth @StackDigest]

@meanjanroy @VitalikButerin Oh right nice :) Would be great to see this in prod!!

[smstack.eth @StackDigest]

As @VitalikButerin pointed out yesterday, zkVM proving speed is becoming less of a bottleneck. With binary fields and advances in PCS like WHIR and Ligerito, the progress is impressive.

But beyond security, I think we should focus more on usability.

A few questions worth digging into:

- How easily can existing application or client logic be compiled and proved in a zkVM?
- How can we reduce the onchain verification cost of hash-based SNARKs on the EVM?
- How practical is client-side proving in browsers and on mobile devices, and how far can we optimize it?

I’m particularly interested in the second question. If you’re working on this or have interesting ideas, please DM me!

[Srinath Setty @srinathtv]

Introducing Magnetar from Microsoft Research, the first zkVM that is: (1) general-purpose (RV64), (2) post-quantum from standard hashes alone (no curves, no lattices, no Poseidon), and (3) built for recursion.

Despite its conservative security, it is the fastest zkVM: 7.2–8.7 MHz on a laptop, 10–39× faster than existing zkVMs across 15 workloads! An optimized version reaches 9.5–12.8 MHz.

Links in the thread below.

[smstack.eth @StackDigest]

@TauLepton_ 🚀🚀

[smstack.eth @StackDigest]

@meanjanroy @VitalikButerin Just took a brief look on this, so nice! So in a post-quantum world, the bottleneck would be ‘how to prove PQ-safe signature of a physical card with hash-based SNARK’, right?

Btw what would be the most meaningful usecase of this zkEMV?

[smstack.eth @StackDigest]

@meanjanroy @VitalikButerin Oh that’s really interesting - is there any open repo or doc for it?

[smstack.eth @StackDigest]

@milotruck What do u mean by onchain fuzzing?

[smstack.eth @StackDigest]

@pcaversaccio You can also paste your mainnet tx hash to see how much gas it take after Glamsterdam!

https://t.co/QUE7SA5MH0

[smstack.eth @StackDigest]

Is it over 100 bits security? 🤔

[ZKsync @zksync]

https://t.co/ejI9SUZmna

[smstack.eth @StackDigest]

You can bring your Safe & Fireblocks MPC wallet to Privacy Boost with no extra key setup or module installation!

[Privacy Boost @PrivacyBoost]

[How Privacy Boost Works #5]: Keep Your Safe, Make Payments Private

Why give up your multisig to go private?

With Privacy Boost V2, a regular Safe transaction approves each private spend.

Onchain shows the approval, not who got paid or how much.

Full detail below ↓

[smstack.eth @StackDigest]

@decentrek Fully agree with this, Ethereum is for everyone

[smstack.eth @StackDigest]

This is so important on apps that leverage ZK proofs on L2s, since L2s cannot adopt EIP-8288 style native proof verification.

[Danno Ferrin @shemnon]

RISC-V is the answer.

One very late puzzle piece that contributed to me walking away from EOF at great personal cost was the full-throated endorsement by V for ossifying the EVM as a RISC-V compiled program, and RISC-V guest programs becoming a valid target for smart contracts.

I also think that the idea of banning precompiles and expecting people to EVMify things like PQ crypto schemes is bonkers and regressive. The EVM ISA is wrong for this. RISC-V is a real ISA for the kind of bit twiddling encryption requires, especially if they bring in the vector extensions. But I'm not holding my breath for anything other than the current schemes.

This leaves open a more functional rule for "precompiles" in the zk era, in that precompiles are only considered when they have more efficient ZK circuit constructions than a simple RISC-V implementation, like the proposed FAEST encryption scheme. Otherwise you get charged based on RISC-V cycle count.

This is the way.