Post-Quantum Transition

Transcript

[music] Thank you, Nico. Um, it's really great to see uh the room be so packed today. Um so today uh we're going to have a joint talk with Kev and we would like to share our conviction that it is time to focus on defense and specifically that we must accelerate our transition towards postquantum and postAI cryptography. Over the last few months, we have seen a massive explosion in the number of vulnerabilities that we have discovered with AI. And thankfully, Ethereum is in a really fantastic position to navigate these difficult waters because we have

really outstanding client diversity, which has given us 100% uptime. Another piece of good news is that the EF security team has doubled its headcount in the last couple weeks and months and we have hired senior researchers who are AI native. And one amazing statistic is that since March we have given um clients 895 potential issues, 500 of which were confirmed to be vulnerabilities.

Now this talk is not about bugs. This talk is about something much more structural, much more fundamental. It is about the cryptographic assumptions that underly all of Ethereum L1. And for over a decade now, we have known that quantum will eventually break our cryptography. The only question was when. But now we have a new threat. a threat that we have very significantly underestimated which is just the idea that AI is coming up with new alien mathematics that may be able to break our cryptography without quantum computers.

So in this talk I will be focusing in part one on the threats and then I'll be handing the mic uh to Kev who will talk about solutions based on hashbased cryptography and formal verification. So Qday timelines are definitely accelerating behind closed doors. the CEO of a particular multi-billion dollar quantum company is saying that he has 99% conviction that Qday will happen in 2029.

Now I have a slightly different date. I have 2032 in date in mind and I also have much bigger error bars but I still ascribe a 10% chance of Q day by 2029 and that for me is enough motivation to be working very very hard to try and accelerate the timelines for the migration to postquantum cryptography. Now, one way to see the boom in quantum is to look at all of the new companies that have been formed in the last few years. And this is just a very small segment of the quantum space, specifically the neutral atom companies.

Neutral atoms are arguably the number one threat for our cryptography because they pose a short-term risk due to the fact that neutral atoms are so scalable uh in in the short term. And these companies here have received billions of dollars of investment over the last few months. And if you'd like to learn more about the intersection of Qday Shores algorithm and neutral atoms, there's a talk here just for you. Now, part of the reason why we're seeing such an acceleration in timelines is because every layer of the quantum stack is getting optimized. We're seeing breakthrough advances in the hardware, in the quantum error correction, but

also in the high level shaw algorithm that breaks our cryptography. Over the last few months, a group of roughly 100 amateurs through a website called ecdsa.fail have been able to reduce the number of cubits to run Shaw's algorithm by 30% relative to Google's paper in March. And not only that, they were able to reduce by 3x the runtime of Shaw's algorithm. And back in March, Google only expected AI to give a 5 to 10% improvement over their circuits. So this is new and unexpected development even for a

world-class team like Google. Now we should be expecting improvements to Shaw's algorithm to keep coming. Back in March, Google's paper had a 10-minute runtime for Shaw's algorithm on superconducting cubits that got reduced over the the next few months to three three and a half minutes. And this month, there's going to be a breakthrough paper that further reduces the runtime by an order of magnitude. We're going to go from minutes to seconds. And I think what this paper is going to do is two things. one, it's going to um kill the idea that a fast mempool is good mitigation against a slow quantum attacker. And secondly, I

think it might propel quantum back in the headlines just like Google did uh in in in March with its paper. Now one thing that I want to make very clear is that we have now entered an era of very significant government intervention. Quantum is a matter of national security and we should not be expecting a research from now on to become as free as it was in the past. Google's paper took a lot of dedication from from members of the team to see the the light of day and it had to come with very significant

concessions. One of the concessions was that the the circuit itself had to be censored. It had to be hidden behind a zero knowledge proof. Another interesting thing is that the whole process with of the government intervention added a lot of friction and the paper was only published a whole year after the initial ideas for the paper were discovered. And another interesting thing is that very significant very material commentary for example on Qday timelines was censored from the paper and never saw the the light of day.

Now the other threat that I alluded to is mathematical super intelligence. over one on one single day with a single drop open AI resolved 18% of the top 500 mathematical problems and it did so by only spending 3 hours of compute time per problem solved and this is in stark contrast with the fact that we have since July zero cryp analysis result.

The last three months have been the most prolific in the history of mathematics. You know, August, uh, September, October, and yet during these three months, we have had zero results, uh, from the major AI labs when it comes to cryptography and cryp analysis results. What is happening behind the scenes is that entities like the NSA are stockpiling cryptographic vulnerabilities and preventing the major AI labs from disclosing what they are finding.

Now another interesting thing about super intelligence is that it's leading to the creation of mathematics that no human or very very few human could have even imagined. Here on the slides we have six different mathematical problems that have stood for many many decades which hundreds if not thousands of the brightest mathematicians have tried to break and for which the consensus was that these conjectures are true. But what happened is that AI discovered new mathematics that that that show that actually these conjectures are not true. We have counter examples. We have disproofs.

And the cryptographic assumptions that Ethereum relies on is nothing more, nothing less than a mathematical conjecture that experts have been trying to attack for many decades and for which the consensus right now is that um the con the the conjecture is true. But there is a significant chance that our human intuition is simply wrong. And this is a threat that we are taking extremely seriously. And we now have a world-class team of people working on these assumptions. And we have, you know, material access to tools and information that is not currently

public. And so with all of this, we today are um announcing an up a material update to the straw map. We're pushing timelines forward very significantly to the to the jar fork. More specifically, we would like to have all three layers of L1, the E with postquantum transactions, the CL with postquantum attestations, and the DL with postquantum sampling. all wrapped up uh by JAR. And just a couple months ago, uh this was in LAR, you know, a year and a half after after this.

And behind all of these pieces of infrastructure, we have a very powerful tool, a very powerful engine called lean VM. and LININVM over the last few days and hours has reached a very significant milestone of end to end formal verification. Now the other thing that we would like to do is set a timeline with mission 2028. We are hoping that in January 2027 we will be launching uh Glamsterdam uh on mainet and our hope is that by December 2028 we'll be able to wrap up the full

postquantum and post AAI uh transition which gives us 24 months to ship the three forks after Glamsterdam. And so next I would like to invite Kev to tell us more about the solutions when it comes to hashbased cryptography and formal verification. Kev, the floor is yours. [music] Cool. Thanks Justin for setting PDoom to 100%.

uh by the end of my talk, I'm hoping that we set it to let's see [laughter] [gasps] um so as Justin was saying, I'd say one way to view mission 2028 is that we want to have all of the pieces stable by the end of 2027 at the latest irrespective of the hardfork schedule. This then allows us to pipeline the changes into the upcoming hard forks until December 2028 at the latest.

The TLDDR is that we have two solutions uh that we are using to ship PQ safely. Hashes and formal verification against the quantum/AI adversary. We believe that hashes are the most conservative option. And we already rely on hashes in the protocol to be secure in places like the state tree, the transactions, uh, and the block hash. While FV will be an important ingredients for shipping DQ safely since it allows us to shrink the amount of code that a human needs to audit.

So which hash? It's the million-doll question. So we started off with Poseidon 2 for performance reasons. However, as proving systems got faster, we're able to move to more traditional hashes. Shafree is our current default. And if you don't know what about Shafrey/Ketak, it has enjoyed about 10 plus years of crypto analysis and has a huge security margin. So that's a good thing. Why is this important? If all of the security boils down to the choice of the hash function, we do need to ensure that we choose it very carefully.

So where are the hashes being used? On the EL we swap ECDSA for lean sphinx. On the CL we swap BLS for lean XMSS. On the DL we swap KZG for lean DA. And we're about to introduce uh this new thing called lean PCS. It's basically a PQ polinomial commitment schemes which will allow developers who rely on pre-quantum pre-ompiles or snarks like graph 16 or plon to switch to PQ Starks as an alternative.

So what's the problem with all of these hash functions or hashbased schemes? The proofs or signatures are very large and the solution to this is lean VM. You can think of it as a component that acts as a compression function. So we compress many lean spin signatures, many lean XMSSS signatures or lean da proofs into a small proof. What happens if there is a bug in lean VM or any of the components that I've just listed? Okay, pdoom is going back up. Uh we're introducing a lot of changes into the protocol and with AI making it easier than ever to find bugs.

Literally, you can just prompt find bug, make no mistakes, and it will probably find something. We do need to find ways to increase our confidence in the code that we're shipping. And this is why we're looking at formal verification. Now the idea with form of verification is that instead of auditing multiple lines of code, we audit a spec that we validate is faithful to the protocol or algorithm that we want to state and then prove equivalence uh to the spec between the spec and the code we want to execute.

If the equivalence proof is airtight and I'm sort of brushing a lot of stuff under the carpet there then the code being executed is a implementation detail and this has opened up interesting optimization experiments uh known as auto research where the AI continuously optimizes the implementation and the system accepts this as long as the AI is able to prove that uh the implementation is still equivalent to the specs and we've seen some interesting results from this. So, snark.fast 4x improvements improver times. Better.code we've seen some new mass findings related to the proximity gap. SIG.golf, we saw a 2x decrease in the number of risk five

cycles. Now, in some sense, AI finding a 2x improvement is not actually new. Like, this is something that I'm pretty sure all of you have seen already. The nice thing that I want to stress is that the AI is able to provide a proof that the optimization is sound. And we're now also launching EVM.f which uses an experimental spec at the moment and is aiming to optimize a stateless ELU guest program. I'm going to put my engineering hat on now. Right now, I would not advise you to blindly auto research your implementations and full send it uh into production uh since formal verification

as it pertains to shipping code is still nent and in some cases the trusted compute base is not yet well understood. So, some of you in the audience may be wondering how does this all affect me? uh is there anything I should be on the lookout for in the short to medium term? So for validators if you have a 0x0 withdrawal credentials we are setting out a plan to deprecate this. So please upgrade. Also strongly advise you to engage with the first steps of the PQ plan on the CL side which is the PQ validator registry.

For developers to keep it simple be on the lookout for places in which you do assume ECDSA. And for users the way you interact with the chain will change with something called frame transactions. This is an enabler for PQ on the E in the happy path. Please look into it. wallets, please start looking into how you will support frames. Now, zooming out uh just a bit. In terms of protocol risk, we note that 72% of the total e supply is linked to accounts that have signed a transaction before, thus revealing their public key. If you are a part of this percentage and you are a bit paranoid, one way to mitigate

this is by sending your ETH to a new account. And since accounts that have not signed transactions in the past o only reveal their hash, a cryp cryptographically relevant quantum computer will need to find the pre-image of the hash before being able to crack the public key. Another option given we have frames is to eagerly deploy a lean shrinks verifier contract on chain using our our lean shrinks candidate. Use that to approve transactions on behalf of your account. It will be more expensive given it's not in the protocol and we don't have lean VM yet, but you will be PQ safe.

Speaking of our leanx candidate, we are looking for feedback on the considered parameter set uh please check out uh spinx.art by a meal. And if you want to try out lean spinx on test nets andor just interested in how aggregation works, uh please check out the daugi test net by Antonio Sensor. Thank you for listening. If you want to know more about PQ, we have this QR code which will take you to a playlist with roughly 40 hours of PQ related content from the Cambridge workshop. This is the last slide and uh in case folks did zone out, the TLDDR [music]