# Ethereum Accounts - Post Quantum Today | Nicolas Consigny (Berlin Ethereum Day, June 2026)

- Speakers: Nicolas Consigny
- Channel: [Berlin Ethereum Meetup](https://streameth.org/berlin-ethereum-meetup)
- Date: 2026-09-25
- Watch: https://streameth.org/watch/yt-r873wc7ugOk
- YouTube: https://www.youtube.com/watch?v=r873wc7ugOk

## Transcript

Hello everyone. I'm Niko. I lead the Kohaku initiative at the Ethereum Foundation. Uh and I do a little bit of postquantum cryptography these days. Um I'm going to give you a short introduction about uh hashbased signatures. Actually, it was not the best title. Uh so I just changed it for Ethereum Ethereum accounts postquantum today. So as you know we can upgrade the Ethereum protocol with EIPs. It is great that we can do that but it also comes at a cost uh because we need to organize around the fork. We need to wait uh we need to agree which is very hard to get consensus around a lot of cordives. And on top of that, we have a history of having a lot of troubles with um cryptographic primitives which are uh pre-ompiles. Um so what we what I tried to do in the last few months is to find a way to have a postquantum signature on Ethereum without having to wait for a hard fork. And so talking with uh the organizers of this event, um I realized it was maybe not the best time to go deep into what is a hashbased signature and how it looks like, but rather give a high level explainer because well it's a lightning talk and not everyone wants to see um the inside of hashbang signatures. So first let's start at the very beginning. What is an account? You have two types of accounts on Ethereum. You have uh externally owned accounts, EOAs, which are controlled uh by a private key. Uh what is super cool with these accounts is that you don't really need to deploy them. They just exist uh out of the possible set of of Revit. And then you have uh contract accounts which are different. they're deployed and they're controlled by code. And so the cool thing with uh smart account is that you can do uh a lot of arbitrary logic to control the account. And unlike uh externally owned account, they don't have private key that is automatically associated let's say uh with the address. So you have what we call uh verifiers and you have what we call verifiers. So basically you can verify a specific signature directly inside the account code. So if you look at what's inside the account you have an ounce. You probably all know what it is. It's this little number that increase. Uh when you do um transaction you have a balance which is the amount of way or ease that you have on your account. You have a storage hash where you have the state and you have a code hash. The code hash is the important part uh here. In an externally owned account, it's empty. And in a contract account, it's not. Uh and this is where you can put your uh EVM code. So, okay, this is cool, but how do we make it postquent? Well, basically inside the code hash um in inside the code of the the account, we are going to be able to write arbitrary logic. And one of the arbitrary logic that you can write is a signature verification. Um and with a signature uh verification you uh you can ask the contract uh to call arbitrary methods to validate any type of signature. This is great and this is one of the uh advantage of Ethereum being a programmable chain is that you can actually do this very cool stuff at the contract level. This is why we're a smart contract chain and this is why we can do a lot of very cool stuff on Ethereum. Okay, so we need a signature and we need one that is uh postquentum and you have two types well you have actually more than that but you have two uh big types of postquentum signature one is latisbased and the other is hashbased and in the world of hashbased signatures uh there is one called sphinx And Sphinx is a weird construction of hashes where you have trees and chains of hashes that are allowing you to sign a message from this primitive. So you all know I hope you all know uh the hash which is just you give an input into a function and it gives you a fixed size output. Basically if you do a trick with um a chain of hash and a tree you can end up signing message. Uh so having a digital signature uh scheme and the problem with um so the cool side first the cool side is that the hash functions are very wellknown uh somewhat easy to understand and they're relying on assumptions uh that have been battle tested over and over again. This is why I went for the hashes uh rather than lettuce which is based on different assumption and which is u which are much harder to understand. But the problem is that they're very big and somewhat um intensive. So when you try to do this uh signature you need to do a lot of hash millions of hash. And so this is uh compute intensive and it is yeah it is hard to to to deal with. So the hash signatures uh that were standardized were a little bit uh too big for Ethereum and they were also using hash functions that are not native to Ethereum. Uh so with the cryptography team and with a bunch of friends, we started uh to work on a slight modification of this sphinx signature and sphinx actually standardized uh a signature that was called sphinx plus. Uh so as a joke because our signature is lighter and smaller we called it uh sphinx minus. So this is what it looks like. Uh so you have a bunch of Merkel trees and each Merkel tree is authenticating uh the layer that is under it and you end up being able to do um a lot of signatures with a single key pair. Uh so with sphinx minus you have different uh varants and different budget of signatures. Uh but basically you have enough uh space to sign a few millions of transaction before lowering the security uh of the scheme. And if you think about it a few millions of transaction it's quite a lot like uh if you sign every day for a few decades you're still not even close. Um so it's pretty cool. Uh and we found a way to optimize the gas for it. So, it's not too expensive to do on the EVM. And uh actually, some of the variants that are the most optimized are as cheap as a few cents uh on Ethereum today because the gas price is pretty low these days. You can go and check uh all of this and the repo swings minus. And this is very cool because this allows smart contract to um to verify um postquantum signatures. But most people use EOA and some people are very attached to their EOA address. Um we even have some people who like have tattoos of of the EOA address. Uh so it would be sad if we had to sunset the EOA because all these people would look quite dumb with the tattoos. But we have a way for them uh to upgrade. Uh so we are working on two different tips to be able to upgrade your EOA uh to our smart contracts. So you may remember 7702 which allows you to delegate an EOA uh to a contract basically to point from your EOA to a contract so that it can execute um arbitrary logic from the EOA. But the problem with this in a postquantum model is that you still have the old ECDA key uh from the EOA that can uh sign transaction and operate um the account. So in a world where uh you have a postquantum computer, this means that you did delegate to a new smart contract wallet which has this fancy signature verification that is postquantum, but you still have this old EOA that can do things with the um not postquantum signature. So to solve that, we need to do two things. we need to um deactivate the ECDSA the old key from the EOA. This is not too complicated to do. You we can do it with a flag uh on the account. And the problem is that we have something on the EVM which is called uh EC recover which is a native operation in the EVM which allows you to recover an address from an ECDSA signature. Uh and you can with this uh you can sign permit transaction, you can sign offline uh transaction. Um, so we could just try to uh deactivate it or to change its behavior. And one problem doing this is that some people are actually using EC recover but not to recover uh addresses but to do um different mathematical operation. Um I think the biggest one uh is the chain link oracle which is using it for some fancy mass. So we need to be a little bit careful and we are still working on on the second one. Um DCIP might change but the idea the main idea is here already. Uh it's to enable this uh transition and it will be optin. So it's not like we are going to roll this out and and deactivate uh EOAs and you will be stuck. It's going to be optin. So if you think that uh quantum computers are never happening and you don't care about this, then you can just never opt in and voila, you stay with your AOX. But if you feel like it's a good idea to move, uh you will be able to opt in and to change um and to change your account toward a Postquentum account. Uh so we are working on on this uh EIP with Colen and Light client who's championing this these this EIP for us. Okay. So here we have almost uh all the building blocks to create these uh postm accounts on Ethereum. And um it is still somewhat uh fancy and exotic uh to have a verifier of a new postquantum scheme. And we have seen in the past that smart contract uh bugs can be terrible especi especially when it comes to wallet. Uh so how can we be sure that the verifier contract is good and is behaving correctly without a bug? Um well for this we have a new solution uh which is verity. It allows you to formally verify uh smart contracts and it's um based on the lean programming language. LEIN is um a framework that was developed by Microsoft. Uh they put hundreds of engineers for almost a decade into it. Uh and so they built this very nice uh verification framework that uh that now is not part of Microsoft anymore. And we have a team uh that worked on a specific uh compiler for verifying lin code um and for verifying existing solidity code. So the way it works uh you can either write your contract directly in lean and it will compile down to uh you will um and then to EVM by code or you can take an existing solidity contract and translate it line by line [clears throat] compile it down to the bite code and then prove that your lean bite code is equivalent to the solidity by code. And with this uh equivalence you have proved that the theorem that you're verifying in your LIN are also applying to the solidity code that that you have. And so just like this we can uh have a very um nice formal proof of a contract. And this is what we did for some of the variants of Sync Minus. And we are going to um do it for all the variants of Sync Minus. And if you're writing smart contracts, I really invite you to look into Varity and to try it. Uh because it's a super nice tool. It's it's very uh powerful and it scales super well. So it can allow you to um to do for example a verified unis swap. So someone already did this. It's called swap. So yeah, you can do a lot of very cool project with varity. And yeah, if you're writing smart contracts, I really invite you to to have a deep look into it. And uh voila, thanks to this lightning talk, we are going to win some time and get back on on schedule. So, thank you for your attention. If you have some questions, >> why are these spotless signatures so data for hashbased? Um so for hashbased uh the construction size that was parame uh that was decided by NIS is absolutely huge. It gives you enough room to sign 2 point uh 2 to the 64 signatures with the same key pair and 2 to the 64 is a huge number. So the three that I showed you earlier, this one uh if you take the le version of this uh the three would be 300 pages of a book just to uh represent it on your screen. Uh so it is a huge construction and when I say huge it's like yeah it's really size of the Bible. So this creates a big um signature size because you have this huge construction that is creating it and so it creates a 7 to 12 kilobyte signature size and we took it down to 2 3 kilobyte which is still huge by the way. >> Thank you. I have a question regarding the last slide regarding lean. >> Yeah. H how how is this uh like proof timer being used in just you mentioned some applications that are user test or validate in proof just if you could double click on on this topic would be quite interesting. Thank you. >> Um so you have two ways to use it. Uh one is to just write a new contract from scratch. uh and so you will write a contract in the LIN uh language that is slightly adapted for the EVM. So it's a ED uh EDSL a specific uh domain specific language. So you can either write entirely new contract from scratch in lean uh and so it gives you this nice um proofs so you can have invariant and proofs in your uh in your contract. So you can prove for example um that the balance uh cannot be exploited in a in a liquidity pool in the swap uh and you can prove invariance uh that are give you insurance that the contract is is correctly written and the other one is to translate an existing contract. So this is basically an auditing tool. Um yeah so you can audit existing contracts with this and uh yeah for example if you're trying to prove an invariance uh let's say on the on the liquidity pool and you figure out that you're not managing to prove this uh invariant like let's say uh classic example is a re-entrrency uh if you're not being if you're not able to prove the re-entrrency invariance in your lin version it probably means that somewhere in your contract there is a a re-entrrency attack that is possible Uh so this is how you you you use this tool to basically write more secure contracts. >> Let's have one last question. >> Uh thank you for the talk first. Um the question is uh I think we was using some variant of XMss which was also a hash signature. So what are some of the considerations around space versus using anything inside? >> Very good question. So XMss is um stateful. So you need to keep a a state uh and if you mismanage this state uh let's say you have announced that you're going to reuse it's like if you were rebuilding your private key. Uh so XNSS is the same uh type of construction but you have to be super careful about uh the management of the state else you would basically give your private key away. And so on the consensus side it is way way easier for a validator for a node uh to manage state because it's automated and it's uh a program. Uh for wallet uh management operation, it's it's a bit more um messy. Um and uh you can have a bunch of bugs uh a bunch of attacks like fault injection and state roll back that could uh that could make this uh quite complicated. So we decided to go for stateless uh signature which is uh sphinx. And funnily xms is actually part of sphinx. So the trees that you see are actually XMSS trees inside Sphinx. >> All right, that will wrap up the session. The final question. Thank you Nico end and a round of applause for Nico please.