Post Quantum Transaction Signatures for Ethereum One Year Later

Transcript

It's all right. Hi. Hi everyone. Um yeah, I'm Antonio from the Ethereum Foundation. Um I'm going to give it like a quick view of what happens last year uh from the post-quantum transaction signatures for Ethereum. Um Quick notation I do in any of my talks this morning and you can sleep when you hear it start, you can wake up.

So, um I always like to see Ethereum and split in three big chunks, three big parts. Um so, we have the execution layer, the consensus, and the data availability sampling. And what do they have in common this this three parts? So, the the first part we of course we need valid signatures. And the algorithm there is ECDSA. For for for consensus since the the merge uh we have BLS BLS signatures or pairings.

And some years ago we introduced a KZG commitments. So, data availability sampling is heavily um pairings as well. Now, what do they have all these solutions in common since this is a recap of what I've done last year. I've solved this stuff already last year. I'll I'll go quick here. Is they have all they all use elliptic curve. So, and in particular for uh for ECDSA we use this the the same curve of Bitcoin secp256k1 and uh for consensus we use a pairing friendly curve that is like the best curve that is out there. This BLS12-381 and it's the same use curve used for uh for for KZG commitments. So,

curves plus pairings. We all know I I hope that I mean I hope since you are here you you know about this this uh threat of quantum computers. So, we have this famous Shor algorithm that in polynomial times breaks um discrete log uh problem in for elliptic curves and not only on finite fields and breaks factorization so RSA and um we've been working on on on try to to to migrate um Ethereum um to to to post-quantum for a while. But, we give um an acceleration in January. Uh you might have seen this um

um this tweet by by Justin and it kind of changed a bit my day-to-day working life because um yeah. We were working on it, but now we have been more serious about that. Uh you can find a lot of details on this website postquantumethereum.org. And as well we try to put some some um more information about uh our long-term plan that goes from now until 20 29 here. So, again three different layers uh that is consensus, data layer, and execution.

And many of these boxes uh involves involves quantum. Um so, this is like the high-level plan. So, for execution we have this uh post-quantum transaction signature calls. Uh for consensus we have this project called linear Ethereum and for data availability sampling we still working on it. So, we have some solution uh within still choose which one is going to be, but uh there are a lot of talks. For this specific uh talk of today we focus only about this box. So, post-quantum transaction signatures.

Next call is today at 3:00. Everyone is invited to come. It happens every couple of weeks um usually at it used to be at 4:00 now I changed the time. We have 3:00 CET. Today is going to be we have topics usually. Today's is going to be hardware wallets. Um we have a couple of invited uh presenters. One is here is Connor. And we have Ledger's. Here's Connor. And uh Ledger's going to is going to present something as well. So, what about post-quantum algorithm? We need something that resist to quantum computers. So, we need new maths so new engine.

This is the the winners uh of the NIST competition announced in July 2022 and um are based there are two categories of maths that has been chosen to that resist to quantum computer. There are lattice solution. They are like for signature are Dilithium and Falcon. For for encryption is Kyber. And for signature the other candidate um use hash functions. So, it's Sphinx plus. Again, for the moment we don't care about encryption. We we we focus about signature. That that's what we matters.

So, we don't at least we don't have this problem called harvest and decrypt later. So um the next slides are going to describe if you if you skip the the calls in the last months this is a recap of of the calls and uh is a shout-out for people that helped me during this uh little journey so far. Um on the first call we basically had we we've seen some lattice solutions. So, we had the the authors of these two uh EIP that uh they will um potentially offer some um some precompile for Dilithium and Falcon that are basically part of the NIST uh

algorithm chosen to be to replace uh ECDSA. And um we had so with the Simon and Renom um presenting this this two EIPs and they as well showed um a working demo and that um actually work with the non-native account abstraction. So, ERC-4337. And um they showed that actually we could have this this this this um algorithm replacing ECDSA with with actually some good price. So no from the gas perspective is is actually good a good good trade-off.

And the second things we we second talk and I think Stephen is here as well. We had Stefano and Fabrizio presenting um the proof of seed. This actually is an old idea of a post of Vitalik. I think it was already in 2020. Vitalik showed that um some thought about how to a hard fork in the case of quantum emergency. And um the idea they presented is is pretty actually simple to execute a bit less, but the idea process not too too hard. And it it starts from this observation. So, um the idea they address is actually nothing else that the the SHA-3 of of the public key. So, the the the public key is a point on elliptic curve.

But, if you don't if you never done any transaction you actually you never expose the public key per se the the real public key. You expose the SHA of it and um even quantum computer are not able to to recover the public key. I mean, we have some algorithm that breaks uh hashing this called Grover, but it's actually not a thing. So, that's what the idea of just of of Vitalik to have a proof of seeds of of proof of seeds or a zero-knowledge proof of seed the fact that you actually knowing the the the seeds that of the of the of the public key. And we had again Stefano and Fabrizio here that they showed this this this this idea implemented. Uh I think

that Stefano will have a talk tomorrow or today that we'll see the the the the demo of this idea. And you can find the article on this QR code if you're interested. Um the second call we focus on the the missing algorithm and so the theme of the second call was uh hash-based solution. And I mean, for for for hash-based it's actually way easier to to to have way less way less assumptions. And again, we had you read Bitcoin is is actually real.

Um so, he showed us a hash-based signature scheme for Bitcoins because they have the same problem. I mean, they aren't special that they will be they will have issues if quantum computer will will actually be a thing in a few years. So, they need to think about replacing the ECDSA signatures as well. And their solution is based on the most conservative assumption that is hash-based. And um after the the the presentation we actually had Nico Contini that uh had a solid implementation of this this hash-based solutions in in Solidity. I mean, um it's actually what it was pretty quick uh to to to to execute the

the paper and uh we showed that Log us uh uh solution in Solidity with 100 bits of security. It showed different, but the some combination were pretty impressive performance. Now, this is this slides I want to spend a bit of more time because it's it's kind of tells a many things. So, the size is not the only parameter we are interested at. There are many access that we need to take in consideration. As as you can see actually Falcon is the one that gives us the best trade-off for signature size.

But, it has issues. I mean, you don't see the thing that I want to highlight here that nowhere we have algorithms. So, it's in the in the quantum solution, you never something like elliptic curve that gives it all, but it's really about picking your poison. And uh you have trade-offs. And uh so if you think for example Falcon that you see mostly in no red, but um there are the main issue in my opinion of Falcon is is this one. Is the the hardware implementation. I mean, verifi- verify to verify Falcon on online, so with with the precompiler with Solidity is not a big issue. The problem is signing. It use floating numbers and

hardware that they have they actually not a lot of RAM. So they actually struggle. At the moment it's impossible to for example signing using using Falcon. The Lithium from the other perspective does not does not have this this issue at all. But look at the the size. I mean, we're talking about 2 .5k of of signatures. And uh let alone hash-based. Now the the fourth goal, yes we skipped the the third.

Um was about account abstraction. Um we actually had um I did this this talk this this ETH research post last year that it was like the road for post-quantum Ethereum transaction is paved with account abstraction. We need despite which algorithm we're going to use, we always going to use account abstraction. This this is a fact. And um we have so far account abstraction, but it's not native. This is ERC-4337 that I I talked before, but we want to have native account abstraction. And so far the most likely candidate to to do it is going to be EIP-4337 that is called frame transaction. We had um a light client uh presenting it.

And uh we had as well the the presenter here in on the room. There is Matteo Matteo two Matteos and Alessandro that showed some solution based on account abstraction. Um that is an interesting idea. Um it it is like it use something called ephemeral keys. And uh they came with a demo as well. And uh the interesting idea behind that is pretty it's pretty simple, but pretty effective. And basically is um you will have a stable identity. And every time you you sign, you rotate your your key. In this case it is an ECDSA key.

Said that, you can maintain the same UX and doing the same solution that currently in the demo is done using ECDSA, you can do with hash-based solution one time. Like Winter needs. And the reason why will be Winter needs or a one-time a few times solutions because actually the key size of of this this guys is not too big. It's not It's not going to be many kilobytes. It's It's It's not It's not too bad. And um as you see like every time you sign, you are rotating the key. And so you the old keys are going to be replaced, but you never change your identity. This is going to be the same.

But that identity that you keep stable is going to be the hash of the public key. So you never expose your public key online. So simple solution, but pretty effective. And all this with account abstraction. And all this with account abstraction native and non-native. So both. But yeah, it's not over. Probably many of you seen this paper uh from from Justin yesterday. So it um it has some some good intuition of how the future is going to look like.

Uh equal author this probably the main authors actually were the the the Google quantum AI people and Don Boneh from Stanford. I mean, I'm not a specialist in the area. I just skimmed the paper cuz it was yesterday and yeah, it's been busy days. These are some numbers. And the things that I'm is more most important for me is this one. So it shows that despite all this this kind of of improvements in both in the qubits and the physical qubit size, will take still some minutes at the moment to to break elliptic curve DLP.

So it's not going to be not going to be milliseconds. Still takes take a while. Of course, things will always get better right? Now um again this this this the table. And I want to highlight something here that I didn't tell you before. Now it's true that the key size is pretty important. So we see the key size the smallest key size there is 666 bytes. And uh at the moment ECDSA is 32 bytes. So it's actually 20 times bigger, right? Something like this. But what matters actually for us for the future of Ethereum and for the future of other chains as well, is not the key size per se, but is the

aggregation. Is is the aggregation matters in two parts mainly. It at P2P level and at mempool. And even if the key size is big, but we are able to to aggregate the signature in a way that doesn't impact too much the peer-to-peer layer and the mempool layer, we won. So this is a kind of my take for the plan of the next next years. So we are now 2026 where we're going to try to implement this ephemeral keys solutions with your help, I hope.

And that solution that the main part we need to focus is UX. So we need to talk to wallet. Both physical wallet and and software wallets. And hopefully this doesn't depend on me, but it's ACD. So it's consensus people that that that they they the core dev. We need to give us native account abstractions so we can use account abstraction and this solution that are based on ephemeral keys. And the long-term plan that this should happen around 2029, hopefully, is Linea giving us this aggregated signatures and stranded in the protocol.

And with Lin Swings that is solution that is this super safe because it has only assumptions that are hash-based. But even if the key size the signature size is big per se, the fact that we can aggregate will not impact too much. The the mempool will not impact too much um the peer-to-peer. So that's my current take at the moment. Might change tomorrow. I don't know. But this is the best view I mean, this this calls so far showed me that this is the right things to do.

Um let's see how it goes. And I reserve few more time for questions, but if you want to see some of this um things that we spoke, shout out to Julio. Uh he implemented a testnet. Uh we we got this domain daisugi. And uh he has all the things we mentioned here. So both the Falcon uh in various forms and uh the ephemeral key solution that at the moment is using ECDSA. We're planning to put as well um ephemeral keys and uh hash-based with the help of River River guys as well that are working on on wallets and other

uh solutions. So this is the testnet and the wallet, but we probably will will have more to come that will will integrate these things better. And that's basically it. If you have any question, I'm happy to answer. >> [applause] >> Yeah, question is basically what is the security model for ephemeral keys? Because either you have a cryptor either or not and it's like, okay. Just saying it's kind of just quantum annoying. If you want to use one-time signatures, there are Winter needs one-time signatures which are designed for this.

Good question, Renat. As we spoke already about that, but basically like um I was mentioning before, let me find the right slide, that yes, you're right. If we stay on the ECDLP elliptic curve, so ECDSA, you're correct. But the UX is really the same for for hash-based one-time signature. So probably the next things we're going to work is implementing this UX with Winter needs or few times signatures. So for us, so that the idea per se, so what we need is UX and the rest is crypto- cryptographically is not too bad. I mean, what we need is UX at the moment. We have people that will use it without thinking too much and clicking button and will have where

they're safe. And that stays. Good question. All right, so I'm >> [clears throat] >> Can you maybe expand on the benefits of native account abstraction compared to 4337? So what can we do? Why it's better once we have native account abstraction? I mean, sure. Um when when you have something native, it's always better. So at the moment it's non-native means Thanks for the question, but it's really good because it's really important for again for the UX. At the moment non-native account abstraction means that you have

smart contracts. So the standard is not in the protocol, but you have like smart contracts doing that. Having this in the protocol will you you don't have actually to rely on on any external contract and is is really the protocol knows about account abstraction. The moment is something exogenous from the protocol so is always better to have this kind of important things inside the protocol. So nothing changes conceptually but in terms of implementation a lot.

Is there any way to to understand to to mercy pardon. Is there any way to understand why is the 437 is used? For example, 437 maybe used as social recovery, maybe used as multi-sig or maybe used to I mean implemented deployed to use some post-quantum algorithm. Is there any way to standardize the usage of the 437? For example, if I want to check that this 437 uses m l d s a why not? Okay. Is there any way to to to to see to to show that this 437 is used to implement the this to to is it deployed to use this post-quantum algorithm? Right. So the the beauty or of account abstraction is

pretty flexible. So you can do many things. You said like post-quantum you can do account recovery, you can do sponsor transactions. At the moment this is done like with the with the with the contract. In the future whatever you can do now with 437 we could do with frame transaction on any native solution but is really generic. It's it's a framework. So not even uh account abstraction or account abstraction just a framework to to allow you to do to don't be really tied to the EOA that it just that does that. It's really like a framework for generalize a lot of use cases like the one you mentioned.

Okay, thank you so much and a great applause to Antonio. >> [applause] [music]