leanSPHINCS: Signing for the long run

Transcript

[music] [music] >> So, I'm Nico. I work at the Ethereum Foundation uh >> [snorts] >> on the strategy team, and I also work on the post-quantum transition for the execution layer. And you may also know me for the Kohaku initiative that I co-lead with Vitalik. Today, I'm going to talk to you about uh post-quantum signatures for the future of Ethereum. So, these signatures are the ones you are going to use for regular transactions.

So, it will represent most of the Ethereum transactions, but you can always decide to use custom uh verifiers. So, let's go into it. So, first, what's an account? An account on Ethereum, you have two main type of account. You have the EOAs, which are the externally owned accounts, and they have a nonce and a balance, and basically, that's it. And you have a second type of account, which are the so-called smart account, and they have this extra storage hash, and uh code hash.

And basically, they are cooler than the EOAs because they can have custom logic, and they can do arbitrary um cryptography verification. So, actually today, you can already have uh post-quantum signatures that protects this account, and you can have it in a safe or in a 4337 or in a 772 7702 setup. Okay, cool, but how do we make it post-quantum for everyone so that the chain upgrades and survives the quantum computers that everyone is saying they are coming soon. So, how do we make it post-quantum?

Well, we need to have a signature that is verified by a contract. Okay, but which signatures? So, there are two main families of post-quantum signatures that have been standardized by NIST. NIST is the organization that decides internal international standards. They decide a lot of standards. They do standards from for everything. You can find standards from the type of wood that you would put that you should put in your building so it doesn't burn too fast in case of fire. And they also do the standards for cryptography.

And in Ethereum, we decided to go with one of the two families, which is the hash-based family. And the name of the signature scheme is SPHINCS. This is why we are talking about Lean SPHINCS today. Okay, now this is the cross where this talk can be become extremely technical and boring because it's a 61-page document that describes the standards of all the algorithm. But today, we are at Devcon and this is a community conference, so and it's a lightning talk, so we're not going to go through this.

So, I'm going to skip to what we did from the standard to get to something that we can use in the >> [clears throat] >> in the EVM in the Ethereum context. So, NIST, they designed this standard to be stateless, so it means that you don't have to care about how many times you sign with the signature pair. But they did it with an incredibly big number, which is 2 to the 64. 2 to the 64 is insanely large. If you were to start signing today, >> [snorts] >> you would you would die. You would not even be remotely close to to that number even if you were signing every second.

So, it doesn't really make sense to take such a big signature uh to take the cost of this huge size in the context of Ethereum. So, we decided to take the exact same model, but just to reduce the size of this big Merkle tree structure that you see on the screen right now. So, that it fits to our use case, which is we're discussing the lifetime these days and this is like in the hundreds of millions of signatures. On Ethereum, you can check all the accounts and you can check that nobody is signing 100 million times with the same account. That would be actually very bad security practice because you need to rotate keys from time to time.

Okay, so this is the signatures that we are considering for the future Lean chain of Ethereum. Uh but right now all of you guys have EOAs, so we need to upgrade them toward this. And some people are deeply attached to their EOAs. Especially this guy. Um I don't recommend you to tattoo your EOAs, but it's okay guys if you did it, I got you. We worked on two EIPs that are allowing the EOA to become post-quantum.

And the next one will be Lean Sphinx. Which is basically the signature that plugs into those two EIPs. I'm running out of time, but how can we be sure that these verifiers and that these new contracts are secure? Well, the only way is to use formal verification. So, right now in the EVM, we have this beautiful tool called Verity, which is a domain-specific language that has been designed to prove formally prove EVM equivalence and it's based based on Lean. And we will be using Lean to verify all the cryptography work that

we do in the context of the Lean Sphinx initiative. Thank you for your attention. It was a pleasure to be with you. >> Awesome. Nico, this is super cool. Like Lean Sphinx gets me excited, honestly. So, my question is uh will {slash} can Lean Sphinx be aggregated by the Lean VM? >> Absolutely, it can. And I'm doing this every day, and we improve the performance every day. Right now, I can already say that on my computer, just on the CPU, uh I prove about 2 million uh Lean Sphinx uh 2 million key check per seconds, which represent a a huge number

of Lean Sphinx. >> And another question is how big is enough for the lifetime of Lean Sphinx? Like, how many times can you actually sign with Lean Sphinx? >> Uh to me, I would say 2 to the 26. This is one of the last point that we need to fix. Some people say 2 to the 30. I'm a 2 to the 26 guy. >> Oh, and last question cuz we're running out of time, but would you recommend Lean Sphinx over ML-DSA Lithium for end-to-end message authentication? Uh I think we know the answer what you would say, but >> Yeah, uh so ML-DSA can be used for encryp- uh for different stuff. You have ML-KEM that is very useful for

encryption. Uh for us, it will be Lean Sphinx and hash-based for Ethereum. We are hash bros. >> Makes sense. Well, thank you so much, Nico. Uh this was really awesome. >> [music]