Ethereum 能否实现量子安全？EF 首席研究员给出肯定答案｜Lean Ethereum

That's why we don't need to panic. We are right on track. I think we were very early in the process of researching all of these things. If you take Justin's talk at Devcon Bangkok, we started the post-quantum research and all of this just after that. So, it was basically the end of 2024. This was very, very early in the process.

At the time, far fewer people were talking about the quantum threat. But right now, this is becoming a real thing. We are investing a lot of resources and manpower into both research and implementation, so we are doing a lot of different things. I think the full migration is planned for 2029.

For me, this looks reasonable in terms of the timeline because we are investing a lot of effort there. We are also partnering with external entities. I think this is very important to say because we are not alone. All of that is very encouraging, and I think we are right on time. If we are ready for 2029, I think it will be totally fine with regard to quantum computers.

I'm DeFi Dad here with Nomadic. Today's show features Ethereum Foundation researcher Thomas Coratger. Thomas, thank you for joining us. How are you doing?

Hey, thanks for having me. I'm fine.

Okay, Thomas, I want to give people a bit of background on today's show because we're doing a Lean Ethereum series here. First up, we have part 1 with you on quantum. Then we'll be doing one on privacy and possibly a third on ZK. Today's focus is mostly on quantum.

To me, quantum really starts to feel like science fiction. It's this intersection of physics, hardware, computer science, and cryptography. Ethereum has to prepare for this future and these machines that don't really exist yet but could eventually break the cryptography securing the Ethereum network.

Today, we're both probably going to ask you a lot of beginner questions—101 stuff. How real is this? How far away is it? What does a quantum attack actually look like? And then, maybe most importantly, how is Ethereum specifically preparing for this?

1. Background and why focus on Ethereum

Let's just start with how you became drawn to working on Ethereum and joining the EF. Maybe you can share a little bit about that and what you do there today.

Sure. Thanks for the intro. I was doing something quite different before. I have an engineering background. I went to engineering school and then did a PhD in applied mathematics, but it wasn't related to cryptography at all. It was more related to physics.

After that, I decided to move to the crypto industry because I had read a bunch of papers, like the Bitcoin papers, the Ethereum papers, and a bunch of white papers like that. I decided to dig more into this crypto stuff. At the beginning, I was doing startup work—different kinds of things, like wallets and stuff like that, before account abstraction and everything.

Then I moved more into the ZK space, especially with Starknet and Cairo at the time. I was doing basically ZK-EVM engineering work and coding around cryptography, ZK-EVMs, SNARKs, STARKs, and this kind of stuff.

Just after that, I contacted Justin Drake after his talk at Devcon Bangkok about the Beam Chain project at the time. I said that it could be cool for me to participate in this effort. I started with a grant about a cryptography project, and from day 1, I participated in the post-quantum effort at the Ethereum Foundation.

Thomas, tell us more about why you ultimately chose to work on Ethereum. With your skill set, you clearly are in demand. You could probably work in one of many highly paid tech jobs today. Why Ethereum?

This is a good question because, for me, all of this stuff around crypto was very interesting—the blockchain industry at large. It's a perfect mix of computer science, cryptography, decentralized systems, and a lot of mathematics. As I mentioned before, I was doing a PhD in applied mathematics, so it was kind of the perfect fit for me.

I also really love the idea of decentralization—the fact that we can build the future of finance and many other things without having a centralized entity in the middle. It was very mind-blowing for me at the beginning, and it still is. The fact that we can work in a very productive way, asynchronously, around the world is also something really crazy.

As I said, for me, the blockchain industry is the perfect mix of mathematics, cryptography, computer science, and a lot of things like this. With Ethereum, of course, you can work on many blockchains. You can work on Bitcoin, Solana, or other projects like that. But Ethereum was, and still is, something super important, with a lot of novel ideas.

It is much more programmable than Bitcoin, for example, so you can do a lot of new things and really reinvent the world. It is also super decentralized compared to other alternatives that are much less decentralized. It's always a puzzle of things that you have to solve to keep performance, decentralization, and all of these kinds of things.

So, it was a perfect fit for me.

2. What is Lean Ethereum?

I like that analogy. It's kind of like a continuous puzzle that you have to keep solving. We'll definitely get to a big puzzle here with quantum. But before we jump down that rabbit hole, can you tell us a bit more about Lean Ethereum? What is it?

I believe it used to be called Beam Chain when Justin Drake unveiled it at Devcon Bangkok a few years ago. Correct me if I'm wrong, but maybe just give us the high-level overview of this Lean Ethereum movement within the space.

As I recall, that's what was initially presented as the Beam Chain project by Justin Drake at Devcon Bangkok 2024, I think. Just after that, I contacted Justin to be part of this effort. That's the moment when I started contributing deeply to the Ethereum Foundation's effort.

This was then rebranded as Lean Ethereum instead of Beam. Basically, it is a rewrite of the consensus part of the Ethereum system. Over the years, we have accumulated a lot of things—a lot of technical debt and a lot of other stuff—and we want to clear all of that out and make the consensus protocol very simple and very lean, containing only the most important pieces.

That way, we simplify a lot of the code, and we also make the switch to post-quantum cryptography. If you look at Justin Drake's slides at the time, post-quantum cryptography and the migration to post-quantum cryptography were one of the important buckets of work.

Among all the buckets of work that were presented, such as decreasing the slot time and making finality faster, cryptography was a very important bucket of work. That is where I started to contribute, inside this bucket of work on post-quantum cryptography.

There is a lot involved because you have post-quantum signatures, so you need to migrate from the signature schemes that we are using right now inside the consensus layer to some post-quantum scheme. I'm sure we'll talk about this later, but this also encompasses a lot of other things.

Later on, the Lean Ethereum movement started to grow with some different initiatives. We also have something that we call Lean Execution. That involves using much more ZK and many more SNARK proofs at the execution layer. For example, we can prove execution blocks in real time so that the nodes of the network don't have to redo all of the work; they can just verify a SNARK proof on-chain.

That is a way to scale, and in some sense, that is also part of the Lean Ethereum project. We even have some Lean Ethereum work on the data-availability layer, where we also need to switch from a pre-quantum world to a post-quantum world.

So, that is a big, nice thing to mention about the upcoming efforts of Ethereum to become simpler and post-quantum-resistant.

Is Lean Ethereum something that was, I guess, already planned without the threat of quantum, or are these things just complementary to one another?

I would say that this is more complementary because, of course, when Justin Drake presented this in 2024, the quantum threat was much less of a reality than it is right now, due to all of the advances in AI and stuff like this. That was not happening at the time. But if you look at the slides—the very first slides of the Beam Chain project—the post-quantum migration was already planned and already put down as an important bucket of work. We had many buckets of work in the Beam presentation, with red squares around the important ones, and if you look at these slides, post-quantum migration was already marked as a red flag.

3. Will users need to migrate to quantum-safe Ethereum?

Yeah, it feels like your team—specifically, I guess, the Ethereum Foundation, and maybe more broadly the Ethereum community—is on one end of the spectrum here in terms of getting ahead of the threat of quantum, basically thinking that far in advance and starting to do the necessary research so that the chain can ultimately be quantum-resistant. Whereas we have seen a lot of struggles, a tug-of-war between those who think that it is not a true threat within, let us say, the Bitcoin community and those within the Bitcoin community and elsewhere who are taking it seriously.

4. What is the quantum risk to blockchains like Ethereum?

But it has been great to see a consensus around this being an important problem to solve. It should be the top priority among researchers, so I have been very grateful for that. We probably should get right into more about what quantum is. Can you first tell us more about why exactly quantum computers are a threat to Ethereum? What are they at risk of breaking or hacking? I have always heard concerns about things like private keys, for example, if there were a quantum computer.

Yeah. We can think about this problem in different ways. First, it is important to say that quantum computers are this new kind of machine. They are not strong at solving all of the problems in the world, but they are strong at solving specific problems in the world. Unfortunately, they are strong at solving cryptography, especially factoring numbers. That is the basis of many things in cryptography right now, in the pre-quantum era.

The main problem that we have right now with Ethereum at different layers is elliptic-curve cryptography because we are using that all over the place. For example, when you are a user and you want to sign a transaction with your MetaMask, under the hood, the signature uses an elliptic curve. If you are a validator and you propose a new block or validate some blocks, you also use elliptic-curve cryptography. Even at the data-availability layer—all of the blob-related things—we also have a commitment scheme called the KZG commitment scheme, which also uses elliptic curves.

5. How real is the quantum threat? How soon?

Basically, you can decompose Ethereum into these 3 layers: a consensus layer, an execution layer, and a data-availability layer. In all of these layers, we are using cryptographic objects that are not post-quantum-secure. What does that mean? It means that, for example, right now, with elliptic-curve cryptography, it is impossible for an attacker to get your public key and derive your private key. This should require an infinite amount of time for a classical computer, but the story is completely different with a quantum computer because, with a quantum computer, you can factor a number much more easily.

From a public key, you can basically derive the private key, and then you can sign on behalf of the user or something like that. That would be a real mess. That is the quantum threat that we should address right now. As I mentioned, the very important difficulty to have in mind is that this threat exists at different layers of Ethereum—basically, at all of the layers.

It is different at all of the layers because right now we are using one signature scheme for the execution layer, but we are using a completely different signature scheme at the consensus layer for validators. So, we have to solve a lot of problems like this. But basically, the problem is always the same with quantum computers: quantum computers are capable of breaking elliptic-curve cryptography, so we should get rid of that.

I want to get more into what these computers look like—some of the components that would need to come together to actually make one of these happen. I have seen a lot of theoretical discussions. There was a paper from Google, I believe, and Justin Drake was a co-author on it. I think this paper really shook people and woke people up to, “Oh my gosh, this looks more imminent.”

But, of course, like anything in today’s world, there are people who agreed with it and people who disagreed with it. What I want to get from you—and I know this is a highly subjective question—is, in your professional opinion, how imminent is the threat of quantum? Are we talking about 5 years away, 10 years away, or 20 years away, in your mind? I just kind of want to get your opinion on this.

Okay. Indeed, this is both a very good question and a very difficult one because nobody really knows. Why? Because we have a bunch of governments, startups, public institutes, and private institutes looking into this kind of quantum computer. At the Ethereum Foundation, we are not quantum-computer experts because what we want to do is take into account that quantum computers will break our cryptography, and so we need to migrate. But this is a completely different job from building full quantum computers. We have startups around the world doing that very well.

Right now, I can give a few numbers. The fact is that we have seen tons of progress recently, especially from the big labs like IBM and Google, the U.S. government labs, and Oratomic, which raised, if I am correct, millions a couple of weeks ago and is also a very big startup around quantum computers. What is also important to say is that the resources needed to break elliptic-curve cryptography have decreased a lot in the past couple of years.

It was something like 20 million physical qubits—that is the unit of a quantum computer—and with the recent paper that you mentioned with Justin, it was only 500,000 this year. That is huge progress. And this is just the beginning of AI. I am sure that we can do much more with more advanced AI. So, this decrease in the resources needed is very important to mention.

Concerning the timeline, we have different numbers in mind. Basically, at the beginning, the NIST organization, which sets standards in the United States, deprecated all of the pre-quantum cryptography for 2035, I think. But with all of the recent advancements, we have a non-negligible probability that a quantum computer could arrive around 2030 or 2032, something like this.

Justin has given a lot of talks about this, but there is also a small probability that it could come before 2030—2029, for example. That is theoretically possible. Of course, no one knows, but I would say that, at least at the Ethereum Foundation, we are preparing so that the transition should be done by 2030, something like that. That should be reasonable for the Ethereum Foundation. Even right now, if you look at the roadmap published on the strawmap.org website, the migration is planned for 2029.

Thomas, you mentioned qubits in there, and this is one little piece of research that I actually did, so I get to show off that I actually know what a qubit is. Hopefully, I do not get this wrong, but a qubit is essentially a quantum computer’s version of a bit. Where a bit is a 0 or a 1, a qubit can behave sort of like both a 0 and a 1.

6. What resources does a quantum attack actually require?

But the real question I wanted to ask you here is that I am still having trouble mentally picturing what a quantum computer looks like and what it would take to amass the resources to bring an attack together. In my mind, there is this theoretical problem that people are proving can be done, but there is still this physical, real-world hardware constraint: you have to amass all this stuff that most likely no sovereign citizen could amass. It is more likely a nation-state actor or some major corporation, I would assume, but correct me if I am wrong. Can you provide any color or clarity on some of those elements?

Yeah, sure. Again, my disclaimer: I am not a quantum-computer expert. But as you mentioned, classical computers work with bits, which are basically 0s and 1s, and quantum computers work with qubits. That is a kind of superposition linked to quantum physics and all of these very nice and very cool physical phenomena. There are a bunch of physical studies that you can have around all of this.

In a quantum computer, there is a hardware part and a software part. The hardware part concerns how you build a quantum computer.

So, all of the machinery—all of the hardware, the components, everything like that—is part of it. For this, you have a bunch of teams around the world. As you mentioned, these are mostly very big companies because you need a lot of resources, and also governments, because this is very critical for them.

For example, this is not at all related to the blockchain space, but with a quantum computer, you can decrypt military conversations or medical data that are encrypted using pre-quantum schemes. You can harvest a lot of data as a government and decrypt it later, once the quantum computer is there. That is very strategic stuff for big governments right now, especially given the current state of the world.

Now, you have different techniques to build a quantum computer. One very modern and very cool one is called neutral atoms. I will not go into the details, but when Justin Drake was a co-author of the paper with the Google folks, there was concurrently another paper by the startup called Oratomic. Oratomic is doing neutral atoms.

The neutral-atom technique scales much better than the other technique used by Google before. With Google's method, you had these very big quantum computers—very big machines that you can see with a very big cooling system, because you need to cool all of these down. If you search for a quantum computer on Google, you will see this kind of huge machine. On the other side, the neutral-atom technique is much more scalable for the long term, so a lot of research entities are migrating to neutral-atom techniques.

It is also important to mention the software side of things, because the algorithm capable of breaking pre-quantum cryptography—elliptic-curve cryptography—is called Shor's algorithm. It was invented in the 1990s, so it was already there long before the quantum computer even existed or was being researched. But this requires a bunch of circuits, algorithmic improvements, and so on. There are a bunch of theoretical questions around the software: how you program your algorithm and so on.

What is also very important is the difference between the physical qubit and the logical qubit. What is very difficult for a quantum computer is to stabilize it—to make it stable. Between the physical qubit and the logical qubit, you have what we call error-correcting codes. That is another field of theoretical questions, with a lot of software engineering and new algorithms that can be applied to stabilize the whole system and benefit as much as possible from all of the physical qubits produced. This is one of the main difficulties right now in the quantum-computer world: stabilizing the system.

Thomas, for those of us who are ETH holders or DeFi users on Ethereum, will there eventually be a moment where we have to do something? Is it just a fork that will get us eventually to a quantum-safe Ethereum, or is there anything else involved for us as users and ETH holders?

So, first, it is important to mention that when we talk about ETH holders and classical users, we are talking about the execution-layer side of things. We are not talking about the consensus layer or the data-availability layer because the consensus layer is only for the validators of the system. So, as a regular user, you are not impacted.

But on the execution layer, indeed, we have to migrate from the signature schemes that we have right now because the signature scheme is called ECDSA, and this is based on pre-quantum elliptic-curve cryptography. So, we have to migrate out of this.

I think that the migration path for this specific layer will be a bit more progressive than it is for the consensus. For the consensus, basically, it will just be a hard fork where we migrate everything. But for the execution layer, I am seeing something a bit more progressive. Why? Because we will first migrate the accounts that you have right now into smart accounts, using smart contracts. That will be a first phase of the migration, because if we migrate to native account abstraction, then you benefit from the power of smart contracts as your wallet. Instead of having a classical EOA, you have a smart wallet. We are capable of encapsulating any kind of logic inside the smart contract. This is what we call cryptographic agility, because inside the smart contract, we are capable of simply migrating the signature scheme that is used under the hood without the user noticing it.

Once this phase is done, then we can maybe start with a simple and maybe less demanding post-quantum signature scheme, and then, a couple of hard forks later, migrate to something much more long-term. So, yeah, you will have to do a migration at some point in order to migrate your coins probably from the current EOA to a smart account or something like that. All of that is still under discussion. Nothing is fixed on how we will do this, when we will do this, and all of this.

About the execution layer specifically, we have biweekly breakout call sessions that are open to everyone, organized by Antonio, who is also a researcher at the Ethereum Foundation, every Wednesday, where a lot of different people participate. These can be researchers, investors, individual people, companies, institutions, and a lot of people like this.

Thomas, something I just want to clarify there. Again, understanding that it sounds like a lot of this is still in flux and being decided, there are no real concrete answers. But you said that at some point we may have to migrate our tokens to a new wallet standard of some kind. Did I hear that right? Does that mean every Ethereum user is going to have to do some sort of wallet upgrade or migrate these tokens somewhere?

Yeah, I do see it that way. This is still an open discussion. When you speak about these things in the Bitcoin world, you have a much bigger problem. Why? Because you have what we call dormant coins—basically, Satoshi's coins plus a bunch of others, but mostly the Satoshi coins. Since Satoshi just disappeared, the coins that he owns are kind of stuck somewhere, and nobody can just move them around.

There are all of these questions about what we should do with Satoshi's coins. Should we just burn them? Should we keep them alive as a big bounty for anyone who comes up with a quantum computer or some other solution? This is, in general, the big problem that we have with migration on a blockchain.

7. Will Glamsterdam or Hegota help post-quantum Ethereum?

The good news is that for Ethereum, we have much less of this problem because we estimate that only 0.1% of all ETH is lost or something like that. So, it is much less of a problem overall for the migration. I suppose this will look something like that.

In terms of the upcoming network upgrades, Glimmerstone Dam and Hagota, if I'm saying that correctly, do those feed into any of what we're talking about? What are the timelines for these network upgrades? And, if you can summarize this, is there anything within those network upgrades that contributes to the overall roadmap to get Ethereum to be quantum-safe?

Yeah, this is a good question. I think that in the next hard fork, Glamsterdam, it is a bit too early to talk about all of this post-quantum migration stuff. We have this strongmap.org website that is a live roadmap that we update over time, where you have a plan for all of the hard forks, with what is included in each hard fork, following the 3 layers of Ethereum.

Even if Glamsterdam is still a bit early, we are still discussing and researching some things. But I think that the real migration points should start maybe 1 or 2 hard forks after Glamsterdam, with progressive migration paths. I can mention, for example, the migration to native account abstraction. I can also mention the public-key registry program on the consensus layer.

I can mention, for example, the inclusion of LinVM, which is basically a minimal ZK-VM that will probably also be included in J* or something like that. I would say that between A* and L*, this is the time frame that we have for this kind of migration.

8. Tradeoffs in upgrading to quantum resistance

Are there any trade-offs that we're introducing with this? Are there any different hardware requirements that are going to be needed? It's clear to me, at least, that we have to go through this upgrade. But what are the trade-offs, if any, or does it make things better in some way?

Sure.

We have a lot of trade-offs—a lot of stuff. This is mainly our job on a day-to-day basis. First, the big trade-off we have is the signature size. Why? The pre-quantum signature schemes are very convenient because they are super small.

On the consensus side of things, we have a signature scheme called BLS, also based on elliptic curves, and one signature is only 96 bytes. The nice fact is that you can very easily aggregate as many signatures as you want and still produce an aggregate signature that is also 96 bytes. This is very important because the signature size is still the same with elliptic-curve cryptography.

This is what happens already today in practice: you can take all of the validator signatures and concatenate them together. You obtain an aggregate signature, and you post this very small object on-chain, 1 time per block. But with a post-quantum alternative, you cannot do that at all. You have to migrate to something else in terms of cryptography.

What we lean toward today is what we call hash-based cryptography. That is a kind of cryptography based on hash functions, which is a very old assumption, so it is very conservative and very secure because it has been studied for decades before us. The fact is that, first, signatures are much bigger. We were talking about 96 bytes, and now we are talking about 1–3 kilobytes for each signature, so that is much bigger. Second, we do not have a nice aggregation technique, so we lose the property of being able to aggregate signatures together easily.

You end up with 2 problems: first, bigger signatures, and second, much harder aggregation. We have to think harder, and that is where we introduce SNARKs, because we need to aggregate signatures together. You cannot have thousands of validators each signing with a 2-kilobyte signature and posting all of that in your block. This is totally impossible; you cannot send that through the network or load it.

What we do is use a SNARK. This SNARK aggregates all of our signatures and is there to say, “I, as a prover, attest to you that all of these 1,000 signatures are valid.” You now post 1 proof on-chain, 1 proof per block, and by verifying this proof, you are able to say, “Okay, all of these signatures are valid.” But the machinery that we have to put in place for this aggregation is much more complicated than it was before with BLS. That is, for example, a trade-off.

Then we have to pick 1 hash function, for example. We have a lot of questions about this. Should we pick a hash function that is friendly to proving but less studied over time? Should we pick a standard hash function such as BLAKE or SHA, which are very classic hash functions that have been studied for decades and standardized through the NIST process, but are obviously much harder to prove?

We have a bunch of trade-offs, mostly cryptographic trade-offs but also size trade-offs. That is why we are also thinking about how to adapt the peer-to-peer layer to take into account these much larger objects that we have to pass through the network. On the execution side of things, it is the same problem. If you take all of the transactions that are inside a block, you have a lot of transactions, and you also cannot handle very large signatures like this. So, you also have to think about how to aggregate the execution-layer signatures.

Thomas, real quick, is there—you might have answered this; apologies—but are there any surprise improvements in this, other than the benefit of quantum resistance? “Hey, because we’re doing this, we get this sort of upgrade.” Or is it pure trade-offs all the way down?

No, I think we have some surprises, but we also have some very nice new features coming. For example, due to this migration, we have thought about account abstraction natively on Ethereum. That is very nice and very cool because then you can have any sort of logic on top of account abstraction.

We can also think about this as a scaling solution, because we are improving things with zero-knowledge proofs. ZK can help a lot with execution scaling, because then you can have a proof of a block on Ethereum and scale because your validators do not need to run all of the transactions again; they just need to verify a proof.

I also mentioned signature aggregation, but if you imagine a world where we have a lot of transactions per block, then you can aggregate all of those transactions into an aggregate proof. That is also a scaling vector in some sort of way. Even if the proof is still a bit large—typically 128 KB or something—if you have 1,000 signatures per block, this is still a scaling vector.

From a security perspective, of course, we are improving things because we get rid of the quantum threat. That is also a nice thing to have in mind. We are also progressing in the SNARK and cryptography space, so that is potentially a way, in the future, to include true ZK—privacy, private transactions, and things like this—on-chain natively on Ethereum through all of the machinery that we have.

9. The quantum research team at EF

This is also a way of unifying all of Ethereum, because basically we want to use the same hash function everywhere, on the network. All of those are very cool things.

Thomas, something we probably should have asked sooner in the podcast: what does the team and makeup of the post-quantum team look like? How many people are working on it at the Ethereum Foundation? Maybe just give us some insight into that and any breakthroughs you have had recently of any kind.

Within the Ethereum Foundation, we are moving more and more toward very small teams to be more effective, reduce bureaucracy, and be very productive with AI and agents. Inside the post-quantum team, there are 2 of us within the Ethereum Foundation: Emil and me. We both have basically the same role, researching and coding some post-quantum cryptography.

Our main focus right now is the consensus layer of Ethereum, because this is probably the most challenging part of Ethereum’s transition to post-quantum cryptography. We think that we can then reuse a lot of the machinery we put in place on the consensus layer on the other layers of Ethereum to help with the transition.

We have this new signature scheme called XMSS, which is a post-quantum, hash-based signature scheme. A paper was published by the cryptography team last year within the Ethereum Foundation. What we are building on a day-to-day basis is all of the machinery to aggregate the signatures together. That is what we call LeanVM.

LeanVM is a small and purpose-built ZK-VM that is there for only 1 job: to aggregate signatures together. It is very minimal compared with other ZK-VMs on the market, but very performant in this way.

Over the last year, we have built this ZK-VM based on a classical prime field, so it is a ZK-VM very close to other ZK-VMs on the market, based on classical techniques such as polynomial commitment schemes that were also published by some university and MPJ students.

Then we have a prime field called Qualabelle, which is a very classical prime field, and in the middle of everything we have a hash function called the Poseidon hash function. This is a hash function that is very friendly to prove but not very classical and not standardized by the NIST Institute.

What is very cool to mention is that a couple of weeks ago, we had this very nice breakthrough involving new binary-field techniques. What binary-field techniques are is that, inside your proving system, instead of using a classical prime field like KoalaBear, you just use a binary field. That is a field composed of 0 and 1, and then you do some extension stuff and very deep math.

The fact is that with this binary field, you can now use a very classical hash function like BLAKE or SHA. These hash functions are very cool because they are standardized through the NIST process, and we can rely on them because they have had decades of study and cryptanalysis before us.

Right now, Emil and I are working full-time on this breakthrough and making it efficient to aggregate signatures together. That is a very recent breakthrough that we have been working on for the past few months or so.

Yeah, congratulations on the breakthrough. I’m sure DeFi Dad is fully up to speed on that breakthrough and understands KoalaBear in depth by now, I would imagine.

Just a brief disclaimer: this breakthrough—we are always conducting research with universities and other people, so Emil and I are not publishing any papers or stuff like this. We often rely on papers published by other researchers. For this one, it was a paper published by William Wong, Benedict Burns, and Ron Rossbloom, who are university and research people.

10. Can AI accelerate this research and the EF strawmap?

One other thing you said in there that perked my ears up relates to AI. I know the initial roadmap, which has the 2029 end date, was created without assuming any use of AI coding or agents. To my knowledge, that is true. But you said in your little 2-man lean team that you are using AI quite heavily.

I guess do you think AI will speed up the completion of the roadmap? Is it usable enough for you guys that you’re seeing major benefits, and is it accelerating development? I guess both on the roadmap side and maybe in your world in quantum?

Yeah, a lot. On both sides, definitely a lot. Let me explain why. We saw this breakthrough in AI, I think at the end of last year, with Opus 4.5 or 4.6, something like that. Before, it was much more about human interaction with the agent and a lot of back-and-forth to mitigate all of the agent’s problems, as well as the fact that the agent was not autonomous or performant at all for very complex cryptographic tasks.

But now, with the very recent models of Opus and Fable and all of these models, we’ve seen that change dramatically. We’ve seen an increasing number of things that we can do with this AI.

Within the Ethereum Foundation, we are using AI heavily, and even more so on my team. We use AI super heavily for different things: coding, explaining papers, and digging further into a paper that previously required reading it by hand. That was a very complex and time-demanding task. But right now, with AI, you can do all of that in a much more approachable way. It turns out that for mathematical problems like cryptography, if you give the agent enough context, it is very, very performant at carrying out these tasks.

We have also recently seen the rise of formal verification. We have a formal-verification team within the Ethereum Foundation. Formal verification is basically when you write some theorems and proofs in a language called Lean 4. You can prove that your code is written correctly when compared to formally verified code. That is very powerful, because now you can go very, very deep into optimization with the agent while still proving that your code executes as expected through this formal-verification language.

We also have things we’re doing inside the Ethereum Foundation with AI and formal verification. We’ve seen a lot of interaction between our work in AI and formal verification. For example, we have a very nice project—I’m not leading this at all—called EVM ISN. That is basically a version of the EVM, the engine of Ethereum, coded by an agent automatically into assembly code. In the meantime, you do the exact same thing with Lean 4, so you prove that your code executes as expected through formal verification. This is very advanced, and we’re doing a lot of this.

11. Is Ethereum on track to be quantum-safe?

Thomas, before we wrap up, I want to end on this: when do you think Ethereum will be quantum-safe? And do you believe Ethereum is on track to be fully quantum-safe before quantum computers become a real threat? I’m trying to get at what keeps you up at night between now and then.

I think we were very early in the process of researching all of these things. You should take, for example, Justin Drake’s talk at Devcon Bangkok. We started the post-quantum research and all of this just after that, so it was basically the end of 2024. This was very early in the process.

At the time, far fewer people were talking about the quantum threat. But right now, this is becoming a real thing, obviously, and I still think we’re right on track because we’ve prepared a lot of research. We’re investing a lot of research and manpower into both research and implementation. We have code being produced right now on a day-to-day basis in Rust. We have a specification in Python for this new post-quantum consensus layer for some clients to experiment with and things like that.

We’re doing a lot of different things, and I think the full migration is planned for 2029. For me, this looks reasonable in terms of timeline because we’re investing a lot of effort there, and we’re also partnering with external entities.

I think this is very important to say, because we’re not alone. We’re partnering with universities, PhD students, and postdocs. We’re even partnering with some Bitcoin folks because we have an open communication channel with the Blockstream people. We have also co-authored some papers with them, and we’re in constant discussion with these folks.

All of that is very encouraging, and I think we’re right on time. If we’re ready by 2029, I think it will be totally fine with regard to quantum computers.

Something really important to mention is that the first quantum computers will be very expensive, very easy. They will probably be able to run Shor’s algorithm, which is capable of recovering the key, but not in a very small amount of time. That will probably require hours, maybe even days, and so, if this is the case, it will concern only huge holders, not the average holder. That’s why we don’t need to panic. We’re right on track, we’re researching all of this stuff, and I think that’s it.

12. Closing

Thomas, I think this is a great place for us to start wrapping up. First, I want to remind our listeners they can learn more about the work you and your team are doing on Lean Ethereum by going to strawmap.org. That is a great website to track all the progress. They should follow your personal handle: tcoratger. That is his Twitter handle. The GitHub is the same handle. We will put that into the show notes so you can easily find it. Thomas, thank you so much for your time, and thank you for all of the important work you and your team do. I really appreciate you coming on to dumb down some of the research you are doing and how it all relates back to our experience as ETH holders, DeFi users, or ETH stakers. I want to give you the final word before we go, and we would love to have you back in the future. Again, if you enjoyed this episode, we are doing a second part on Lean Ethereum, so stay tuned for that. Thomas, anything else here before we go?

No, thanks for having me. As you just mentioned, please feel free to visit the strawmap.org website. This is a live roadmap that you can consult on a day-to-day basis. This evolves very frequently. We also have a Lean Ethereum GitHub organization that you can check, where we have all of our code repositories and you can participate in an open-source manner. Thanks for the great discussion. Thanks for having me.

Thanks everyone for tuning in. To stay up-to-date with future episodes plus get expert tips, strategies, and exclusive content, subscribe to our free newsletter at the-hyphen-edge.xyz.