Making Ethereum Post Quantum

Transcript

Hello. Oh. Uh hi, my name's Colby Marozas Liebolt and I work at Offchain Labs and this is my little brother. Hi, I'm Cayden and I'm a contributor to Rim. And we're just going to go over the I guess the brief one-year journey of Lean Ethereum so far uh with the goal of making Ethereum post-quantum. Uh we're not cryptographers, so when we talk about crypto cryptography, don't take us like uh I guess at gunpoint, but we work on a client so here we go.

So, a over a year ago at Devcon Bangkok, Justin basically had a keynote where he want he proposed that with with quantum computers being a looming threat to Ethereum, uh what if we could take this opportunity to build an optimal chain assuming there was rough consensus. Of course, rough consensus changes over time, so we'll see how things end up. But yeah, so the main goal would be basically a quantum resistant chain uh hopefully incorporating uh the 10 years of research that Ethereum has done.

So, what is quantum resistance? Uh you can think of uh today's cryptography like a lock and the current computers struggle to pick, but quantum computers come with a master key what can basically decrypt all the locks we use on Ethereum today. So, quantum resistance means uh locks still hold security even if attackers get quantum computers. Uh quantum computers are especially dangerous for today's crypto like RSA and elliptic curves, and hash-based cryptography is safer here because quantum computers help much less against uh hash-based schemes.

So, the takeaway is post-quantum computers is about switching basically the locks Ethereum uses to secure the chain. Uh Rim's Inception had happened a few days after the keynote on November 13th of 2024. Uh we wanted to build a fast, scalable, and modular client, and we also uh loved Rust. Uh bringing like new and old faces onto our team, so people who have never even contributed to Ethereum before uh we now work with and onboarded. Um and also starting out so early uh after the talk, we also wanted to build up a lot of infrastructure, so when we did started like specking, we would be basically ready to go without delays.

So, a little less than a year ago uh Cands uh ECC happened last year in July, and basically we had an interop and the result of that was over something like uh lattice cryptography, we chose uh hash-based uh post-quantum signatures just because there's a lot of confidence in something you already know, uh where lattice-based solutions have never really been used in blockchains uh for the most part. Um we would need uh recursive proof aggregations using something like ZK VMs uh just because there isn't something as I guess succinct as something like BLS for

post-quantum. Um so the ideal would be taking something like SM XMSS uh a style of signatures that emerged and uh like a minimal ZK VM. Uh multiple teams were building real components, and then we wanted to start with just a very minimal devnet just so we can get something working that we could quickly inter iterate off of. So, like multiple teams uh doing a devnet basically uh putting researchers' theories into practice and seeing how they work in the real world.

So, we started off with devnet zero. Uh the first goal was to create a spec all the teams could work off of and collaborate. Uh the researchers at the EF weren't ready with like a PQ signatures library, so we would just build something. We'd basically build a network with everything but that starting off with. Uh the basic goals were 4-second slots instead of 12, uh using quick instead of TCP, and just using gossip sub 1.0 because new teams were going to be implementing libp2p from scratch uh with the eventual goal of building an optimized p2p layer.

So, for a consensus mechanism, we just took uh 3SF mini uh which there was a a paper about and Vitalik just made a mini prototype in Python. Uh we chose it because it was it was just brought up at the time, but also we just want to get the ball rolling. Uh we could always change that later in a month so. So, what is 3SF 3SF mini? Uh over a year ago, it was similar to the fast finality proposals that were happening at the time, uh but instead of doing uh all four votes in in one slot, uh it was split between three different slots. So, uh in the ideal case, uh

a slot would be a block would be finalized in three slots. Uh using a 2/3 majority of the validators. So, if 2/3 majority attested to a block, uh it would be finalized. And yeah, uh there was just some benefit in this is was a lot simpler than a single slot finality proposals. Um after that took place, um there was a Cambridge interop and some of the I guess takeaways there was things were getting a lot more coherent. Uh from Devcon, it was more about just getting people on board with the project, and now it was more starting to actually like expect

things out and bring things into reality. Uh the workshop made clear that networking is a core bottleneck because quantum signatures is a a lot bigger. Uh I believe we're targeting around 3 kilobits, and um that's why like aggregation would be like quite a problem cuz there's not like an elegant way to um co-coalesce the aggregations uh attestations, so. Uh we'd probably need uh specialized p2p network uh subnets, so we could like split the work of aggregating these signatures amongst multiple nodes. So, if you had 100 nodes, uh you'd have four groups, and then these groups would then attest

you could say into four groups into one signature, and then you would have another layer for your final sig uh attestation you'd include in a block. So, the goal was to to operate leanly. Uh each devnet would just ideally include one change, so we wouldn't be caught up so much in testing and the like. So, what were the results of devnet zero? Uh we had a working spec that the teams could work off of. Uh all the teams finalized like 3SF mini a consensus mechanism that we could like run our devnets with, and then we achieved interoperability between Rim, Zeem, and Keeling.

Uh Rim is in Rust, uh Zeem is in Zig, and Keeling was in C++. And there's a link to the specs there. So, going off the tails of uh devnet zero, uh we had new goals, so uh Tomas at the EF now on the post-quantum team, and I believe uh Benedict implemented uh XMSS with basically a in a package they called LeanSig, uh which for the first time we'd be able to use post-quantum signatures on a devnet, which is really cool.

Uh in this devnet, uh we would we were just going to basically just simply aggregate the signatures through uh concatenation. Of course, just appending signatures to a list would bloat the blocks, but at this point the goal was just getting something working. And also the goal was saying a baseline for I guess PQ signatures on a devnet and seeing what what's the baseline we're working from. Uh LeanSig and XMSS. So, XMSS or extended Merkle signature scheme is a post-quantum signature scheme built entirely from hash functions, so its security does not rely on elliptic curves or other algebra that quantum computers can break easily. Uh at the leaf level, XMSS uses Winternitz

uh one-time signatures. Uh each leaf is a is can only be used one time for signing something securely uh because if you signed uh multiple messages uh with that signature uh a quantum computer could use that in like the information to forge a new signature, uh which would break the security. Um XMSS places basically like many uh Winternitz one-time signatures uh in each leaf, so this you could think of it as like a Merkle tree where each leaf is a key that we can use once to sign a block or uh slot, and then at the end you could say their identity is the root of the

Merkle tree, uh which they broadcast to the network. Um and yeah, this scheme is uh stateful because uh the the validator needs to know like which keys they have used in the past. And uh LeanSig basically just adopted this uh paper and made some changes to the parameters to optimize it for our use case. So, the schedule of signing opportunities could would be mapped directly to slots. And the results of devnet one was for the first time we had a DevNet of multiple nodes uh actually like signing blocks and validating blocks with post quantum signatures which was really cool

and at this time we onboarded another client lantern which was built in C. So client teams and researchers we work on a client and collaborate with researchers so specialized teams at the EF work on like the post quantum libraries and papers such as like the EF's post quantum team but we also work with the EF's P2P team because to because libp2p isn't really optimal for sending like as big of messages as we want so the goal would be to design a peer-to-peer stack around our data types.

And theory will only take us so far of course. Uh so going into DevNet two our goals were to integrate the lean multi-sig or lean VM aggregation and kind of set baseline metric for this. So lean VM or lean multi-sig is a minimal hash base ZKVM designed to prove verification of many hash base signatures for post quantum Ethereum instead of being fully general fully general ZK computer it is a specialized hash heavy workload like signature for checking and proof recursion.

In lean multi-sig the idea is to verify many signatures inside and replace them with one succinct proof this gives a form of aggregation even for hash base signatures which do not natively aggregate like something like BLS. The proving stack is built for a cursing recursive composition so proofs can themselves be folded into larger proofs over time. The design goal is to make post quantum multi-signature practical by shifting from many on chain signature checks to one proof of verification.

Now the results of this DevNet where we had successfully integrated lean multi-sig and lean VM aggregation in integrated into all clients and achieved interrupt up to somewhere of 20,000 slots were finalized. And we added another team two more teams into this DevNet both Grandine and EthLambda. And now this was essentially one of our biggest DevNets up to this point DevNet three where we added an aggregator and up our interval from I believe three to five intervals and established a protocol for propagating aggregated signatures.

The results is all teams had successfully integrated aggregation committee aggregation five intervals and we successfully And basically the goal this was originally we had basically four second slots and eight and four ticks so each tick we would do a like a piece of work and we made basically a specialized tick in the four second window for aggregation where before this was handled in the block production basically tick so we basically split the roles into two jobs so there would be a validator that creates a block in a separate one that that like creates the aggregation from the attestations.

And then current DevNet four this is still being specked out and we've multiple teams have already implemented quite a bit to the bit of this but this is still in progress and after ECC within one to two weeks we should be running a long DevNet and hopefully testing this. But this DevNet includes integrating recursive post quantum signature aggregation using the lean VM and having multiple aggregates for the same map. So you can kind of think of this as like the ZKVM then aggregating attestations made by the ZKVM so we could have like basically like multiple intervals of aggregating just because we can only

we can only aggregate so many attestations a second so being able to like make a tree like structure where at the end we have a final one and delegate the work across the network. Now testing and metrics something like DevNet three there was multiple clients being onboarded so often times we might run into small bugs or edge cases between different clients because majority of them are written in different languages so we used Grafana dashboards to test our DevNets and we have this tool called lean quick start where we run the long long node DevNets.

And as you can see this image we've I think this was DevNet three we finalized upwards to 30,000 slots. Now lean lean's future currently a few days ago we had a event called fort mode and we had a round table where we established that within the relatively near future future we want a 10,000 node DevNet. And essentially a lot of clients are trying to onboard themselves maybe even within like one to three days they'll use like AI so they have horrible testing and they're just trying to join and join these DevNets so that causes problems right?

So we're actually trying to proof that so that doesn't happen. And then within like a week all the client teams are planning to have like a six month road map prepared and then hop on a call and uh really figure out the next six months going forward essentially. And I want to give a big thank you to everyone of you coming out a lot more than I expected. But yeah on and a big thanks to all the contributors who've contributed to Rem and the researchers they do a great job on Rem we have roughly almost 50 contributors who have contributed and 130 I think six GitHub stars currently.

And if you want to check out our telegram where we post all our updates and our team meetings and the lean road map where you can get caught up to pretty much everything there is to do with lean Ethereum and get links to all our calls that we've had between all the client teams the links right here leanroadmap.org and uh Rem Rem's X uh remlabs.com or yeah. And also our GitHub. So I'm not sure if we have time for questions. We almost run out of time but we can make one or two questions.

>> Okay. Thank you. How is Bitcoin doing on post quantum stuff? So my understanding of Bitcoin is most the research is and the core developers on Bitcoin core are basically funded by a company called Blockstream. And uh on fort mode we basically brought it up potentially there could be a collaboration there but I believe that their their goals so far from what I heard is to basically just like mine announce and try to figure out some mining way to make a post quantum like security for Bitcoin but I guess that's to be expected but

I believe they're making good progress cuz they hire a lot of great researchers even researchers who have done like papers with like the Ethereum Foundation's like consensus team for their PhDs and stuff so yeah. One last question. Thank you great talk I was just wondering in XMSS you mentioned every leaf is used once for signing. Since every leaf is the number of the leaves are limited I was wondering what happens every one of them is used and how would the switch work if you're going to use another tree? For sure so we would need to add some on chain like transfer mechanism so you could think of it right

now is people on like this MacBook could check could generate around like 8.5 years worth of keys in eight hours. So the idea would be like someone on their laptop or even a GPU would generate like 10 years worth of keys and then in 10 years it would be a your future your future problem. And that would be the goal so yeah and then there would just be like I propose using this other tree tree and then you would just like upgrade the key you use for your validator.

So guys thank you for your presentation and thanks for coming.