Eddy Lazzarin ☀️ retweeted
The only way out is through.
They're calling it the Bugpocalypse. LLMs are being used to find long-hidden cracks in the software infrastructure, and it's happening at a furious rate. 3% of all compromises in computing history happened in the last week, claims one source? I believe it.
There are people saying public access to the frontier models ought to be locked out, or heavily guardrailed, over this. The problem with that idea can be summed up in one sentence: when lockpicks are outlawed, only outlaws will have lockpicks.
The lockpicks will be Chinese open-weight models, if nothing else. There's no way to stop those from becoming ubiquitous.
There are two futures in front of us. One in which only the bad guys have lockpicks, and security holes go undiscovered until they're exploited. Another in which everybody has lockpicks and is aggressively red-teaming their own software so it gets fixed before the holes are exploited.
The corpus of human code is huge but finite. The number of defects in it has to be finite too. We can fix those defects now; we have a million friendly robots to do it with.
The only way out is through.
They're calling it the Bugpocalypse. LLMs are being used to find long-hidden cracks in the software infrastructure, and it's happening at a furious rate. 3% of all compromises in computing history happened in the last week, claims one source? I believe it.
There are people saying public access to the frontier models ought to be locked out, or heavily guardrailed, over this. The problem with that idea can be summed up in one sentence: when lockpicks are outlawed, only outlaws will have lockpicks.
The lockpicks will be Chinese open-weight models, if nothing else. There's no way to stop those from becoming ubiquitous.
There are two futures in front of us. One in which only the bad guys have lockpicks, and security holes go undiscovered until they're exploited. Another in which everybody has lockpicks and is aggressively red-teaming their own software so it gets fixed before the holes are exploited.
The corpus of human code is huge but finite. The number of defects in it has to be finite too. We can fix those defects now; we have a million friendly robots to do it with.
The only way out is through.
172
618
4,634
425,843
Eddy Lazzarin ☀️ retweeted
@apruden08t done — yet. In the future, I believe any vulnerability in code will be exploited almost instantly by bots. But any program has a finite number of bugs, and the defender gets to search it first and for as long as they want before release. AI helps make that search exhaustive, and with formal methods we can probably prove code bug-free. This favors the defender.
Obviously, we need to change how we ship software, and the transition will be challenging. But the end result is good.
Obviously, we need to change how we ship software, and the transition will be challenging. But the end result is good.
2
1
22
1,044
This reminds me to set up Mercury CLI so my agents can managing my accounts directly (without computer use).
github.com/MercuryTechnol…
github.com/MercuryTechnol…
This is insane. We cannot allow AI agents to go into your bank account and act independently without your authorization. But that is what’s happening right now.
Left unchecked, AI could endanger the entire global financial system — including your bank account.
Pause AI NOW!
13
0
36
2,970
Eddy Lazzarin ☀️ retweeted
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.
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.
28
60
258
30,934
The best new private stablecoin wallet right now is @alcove_wallet. Nothing else is close.
- insanely fast (seconds, even for a cross-chain transfer)
- comically cheap (I'm seeing $0.38 on a $10k deposit)
- easy mobile UI, anybody can use
I think it's the next gen leader.
- insanely fast (seconds, even for a cross-chain transfer)
- comically cheap (I'm seeing $0.38 on a $10k deposit)
- easy mobile UI, anybody can use
I think it's the next gen leader.
26
14
153
27,177
Compliance-mandated clarification: by "the best" I mean "according to my personal preferences" — which I think is obvious!
0
1
18
964
I float a balance in Alcove and I can send/receive payments to/from basically any blockchain at nearly no cost. Which I previously had to assemble a stack of kinda janky tools to do.
Can't wait for a CLI tool + more services.
Can't wait for a CLI tool + more services.
0
1
24
1,615
None of these are really about maxxing friction though, this is really texxturemaxxing or THICKlife
I'm fascinated by the rise of frictionmaxxing as a response to a frictionless life. We engineer away inconvenience, only to discover that some of the friction we removed was part of what made life feel alive in the first place
4
1
26
2,865
Eddy Lazzarin ☀️ retweeted
YOU CAN SEE EVERYTHING, PRIMETIME, and DIGGER make 2026 the best year for film since 2015 (SICARIO, EX MACHINA, and MAD MAX: FURY ROAD). At long last, movies are back.
325
202
6,907
668,665
Eddy Lazzarin ☀️ retweeted
When I was writing Unreal Engine 1, my time was divided as follows:
- Around 30% went to seriously deep coding on hard problems: assembly language texture mappers, C++ BSP trees, data persistence, object oriented systems design, and networking.
- Around 70% was just typing and refactoring large bodies of code needed for a complete engine feature set. This was not hard, and while I was doing it my mind was mostly on the deeper coding topics, thinking and planning for what's next. It didn't feel much different from vibe coding today, except that it was just me typing code on an IBM Model M keyboard rather than prompting it and reviewing the results.
So, it has always seemed perfectly logical that we would rely on AI for that 70%, once the AI could do it with a similar quality standard as we could, which has never been perfection. It came as no surprise that, after a few years of AI model evolution, it was able to take the reigns on that 70% and free up programmers' time for more valuable tasks.
What's more of a surprise is the emergence of AI as a sort of insta-Carmack able to solve hard technical problems quite cleverly and often cleanly, and that it's able to reason about and work in complex 3D scenes both by operating the tools and by directly understanding the raw data files.
I abandoned assembly language in 1998 when out-of-order CPUs made much simpler C/C++ code faster, and never I missed it. If prompting through architectural documents, concept art, and design plans can transcend typing code and tweaking vertices, that will enable developers to spend their time on higher-level, higher value technical and creative tasks.
What matters is the end product, whether it's a game or an engine. Anything developers can do to try out more ideas and make better software and games faster is a win for everyone.
- Around 30% went to seriously deep coding on hard problems: assembly language texture mappers, C++ BSP trees, data persistence, object oriented systems design, and networking.
- Around 70% was just typing and refactoring large bodies of code needed for a complete engine feature set. This was not hard, and while I was doing it my mind was mostly on the deeper coding topics, thinking and planning for what's next. It didn't feel much different from vibe coding today, except that it was just me typing code on an IBM Model M keyboard rather than prompting it and reviewing the results.
So, it has always seemed perfectly logical that we would rely on AI for that 70%, once the AI could do it with a similar quality standard as we could, which has never been perfection. It came as no surprise that, after a few years of AI model evolution, it was able to take the reigns on that 70% and free up programmers' time for more valuable tasks.
What's more of a surprise is the emergence of AI as a sort of insta-Carmack able to solve hard technical problems quite cleverly and often cleanly, and that it's able to reason about and work in complex 3D scenes both by operating the tools and by directly understanding the raw data files.
I abandoned assembly language in 1998 when out-of-order CPUs made much simpler C/C++ code faster, and never I missed it. If prompting through architectural documents, concept art, and design plans can transcend typing code and tweaking vertices, that will enable developers to spend their time on higher-level, higher value technical and creative tasks.
What matters is the end product, whether it's a game or an engine. Anything developers can do to try out more ideas and make better software and games faster is a win for everyone.
981
1,637
18,805
1,615,333
Eddy Lazzarin ☀️ retweeted
Ethereum using non-standard cryptography a second time around (for post-quantum) would be a big mistake
We could have had every iPhone act as a hardware wallet with Apple Wallet support if Ethereum had used standardized cryptography. Let’s fix this now instead of repeating it
We could have had every iPhone act as a hardware wallet with Apple Wallet support if Ethereum had used standardized cryptography. Let’s fix this now instead of repeating it
The case for lattices 👇
18
21
178
16,449
Eddy Lazzarin ☀️ retweeted
Post-quantum signatures are 10 to 100x bigger than today's. Aerie shrinks them back down.
25
18
206
32,848
Eddy Lazzarin ☀️ retweeted
1/ Today we’re releasing Aerie: fast post-quantum signature aggregation, using lattice-based SNARKs for lattice-based Falcon signatures. On a laptop (CPU only), it aggregates roughly a full Ethereum slot’s worth of signatures (32,768) in 0.65 seconds.
46
82
525
50,104
Eddy Lazzarin ☀️ retweeted
Hugely important point
a16z crypto's Eddy Lazzarin and Stanford's Dan Boneh on how AI's math leap could turn a decade of trust-building in cryptography into one month:
Eddy: "We specifically rely in some sense on time... We put these schemes out and we wait. And we wait because what we believe is ts, like cryptographers and mathematicians, are testing and trying to break these things."
"Because of the pace of progress on AI's mathematical abilities, there is a conspicuous absence of time... A whole new well of cognitive ability to scrutinize has appeared."
Dan: "In the past, when someone would make an assumption and build a system based on it, we'd have to wait like 10 years before that system could be deployed."
"Now we can just let a model run for a month, try to break it, and if the model can't break it, boy, do we have a lot of confidence that the assumption is valid."
Eddy: "The labs can say, 'We took our tip-top, totally unrestricted, most cyber-capable model, and we told it to go absolutely insane, and we spent $20 million, $50 million trying to break this scheme.'"
"We actually have the prospect to have more confidence in our security than ever before."
@eddylazzarin @danboneh
0
3
17
2,027