PQ Ethereum Workshop - Day 1 Kickoff

Transcript

Wow. Wow. What a fantastic group of attendees. Thank you so much to everyone who uh who flew uh to come here. Uh we have an excellent uh venue here in in Cambridge. Gorgeous Jesus College. And this is the inaugural postmarium workshop. I'm hoping that it's going to be extremely productive, extremely fun, and uh we've actually planned for success because we've pre-booked for 2026. So, we have 44 rooms for next year in October. So, hopefully most of you can stay uh on on on the premises and I'm told the rooms are excellent.

>> Okay. So, um postquantum security for Ethereum has been a long time coming. So this E research post from May 2028 introduced uh B signatures as a candidate for Ethereum. And the very first sentence of this post kind of highlights that BLS would need to be replaced and that stock based aggregation is is a possibility. And uh back then when Vitalic was asked what is your vision for Ethereum 3.0 So his answer was Starks, Starks and lots of Starks because they're very flexible and powerful. They solve a lot of other problems including postquantum security.

So in this talk I'd like to do three things. First of all I'd like to share some of the high level thesis that have um d kind of shaped the path that we've gone down from a research and development perspective for uh postm signatures. And then I'd like to share a snapshot of where we're at right now. What is the cryptographic stack that we have for postquantum signatures and then I'll share a few words about the the workshop. Okay. So four thesis that I'd like to share today. So the first one is uh aggregation. In my opinion, aggregation is an absolute must uh for the the whole blockchain industry, not just for Ethereum consensus layer. And uh you

know I also think that snarks are going to be required uh for aggregation and uh feces three and four are related to snarks. Uh we want them to be end to end and formally verified. That's thesis number four and more likely than not uh you know hashbased signatures are the the best construction that that we could hope for. Okay. Aggregation. So there's been a lot of progress recently with NIST standardizing postquantum signatures. But I would argue um that this is not solving the problem that we have. Uh we need to be able to aggregate signatures and there's two key reasons. The first reason is that we're pushing through a lot of signatures through our

blockchain. So today on the third one we're pushing through 2.7,000 signatures per second. Uh, and I'm hoping that with the the upcoming upgrades to Ethereum, uh, that I'm hoping we can get to 16 at least 16,000 signatures per second. So imagine if you were to verify these signatures individually. Each one of them, let's say, takes a millisecond. You wouldn't be able to keep up with this sheer volume of of signatures. So signature aggregation is required at the consensus layer. But I would also argue that they're required at the application layer. So, one of the features of postquantum signatures is that they're at least 10 times larger than the curve based signatures.

And um it's kind of inconceivable or unacceptable for all of the blockchains that we know and love to just suffer a 10x degradation of performance. Imagine if Bitcoin went from three transactions per second to 0.3 transactions per second. It would be uh completely unacceptable. Um and actually here we have Mihal uh from blockstream uh and I'm hoping that a lot of the the technology that we're building here will be adopted very broadly across the whole blockchain ecosystem. Now the second thesis uh that I'm presenting here is that we most likely need snarks specifically recursive snarks to do our aggregation and the three key reasons are collaborative

aggregation pipeline aggregation and flexible aggregation. We're very picky on the aggregation. So uh one of the things that we want is the ability for mutually untrusted aggregators to work together and collaborate towards a final aggregate and one of the things that this unlocks is parallelism. So we can imagine for example parallel subnets where aggregation partial aggregation happens and then you know the final aggregation happens at later stages. Um and it's also very important uh to have censorship resistance. So you can imagine a malicious aggregator censoring some of the of the signatures and we want it to be we want it to be

permissionless for anyone to enrich the censored aggregates with the censored transactions in order to form uncensored aggregates and this is especially important in the context of proof of stake where we want everyone to have the option to vote and not be um censored from from voting. Another um property that we'd like is called pipeline aggregation. So it's this idea that if you're downloading signatures on the wire, you want to start the aggregation process as quickly as possible uh so that you can do continuous aggregation and you don't have to wait until you've downloaded the the last bite of the last transaction.

and the flexible aggregation. Um, you know, one one of the things that we want is to be able to aggregate across multiple messages, not just across multiple signers. So, in the context of proof of stake, you know, there's multiple forks that different testers might be uh voting for. And in the context of the application layer, every user is signing a different transaction and therefore a different message. And then a final nice to have is that it would be very nice for our aggregation to have the possibility for to turn on zero knowledge. Uh and to maybe have a little bit of ancillary logic that goes around the signature aggregation. Maybe

the best example that I have in mind here is this proposal called privacy wormholes which is basically giving Ethereum L1 uh privacy uh in the same style of of Zcash and you can think of the ancillary logic as being you know verifying some sort of nullifier similar to what Zcash does. Okay. So if you accept that we need aggregation for blockchains and you accept that we need snarks, what kind of snarks um do do should we pick? And um the thesis that we that we have basically is to go for hashbased signatures for three fundamental reasons. The first one is security,

second one simplicity, third one elegance. Let me stop with with elegance because it's very easy to state which is that um imagine if we were to build the entirety of Ethereum uh layer one with just one building block. Isn't that like a cool idea? Very very elegant. Security is is similar. Imagine if we were to build all of Ethereum on the on on just the security of one single hash function. That is a very lean cryptographic assumption. It's a very minimal assumption and you don't need additional hardness assumptions like latises.

And then uh simplicity. It turns out that hashbased constructions nowadays um you know are well understood. They're very modular. We have a very clean way to think about them in the pure random oracle model or quantum random oracle model. And also the the hashbased signatures, you know, they're just very simple um you know, hash chains and Merkel trees and and hashbased NS is basically just fancy Merkel trees. And there's there's also some uh considerations related to um like like practical considerations. So the the number one contender uh for for for postquantum signatures other than than hashbased um is

is is latises. And here we we haven't seen the kind of maturity and adoption that we've seen with with hashbased signatures. And one of the points as well that I wanted to stress is related to performance. So one of the biggest selling points of latisbased signatures is the fact that they're a little bit smaller than the hashbased uh counterparts. But in the context of aggregation, um it doesn't really matter as much what the size of the unaggregated signatures are because the only thing that goes on chain is the is the aggregate and these off-chain messages that are just gossip about peers. It's okay if they're, you know, 2x 5x uh bigger than the the

hashbased counterparts. Okay. And then the final thesis is that, you know, Ethereum is today securing a trillion dollars. In the future, it's plausibly going to be securing trillions of dollars. We want to have relatively high confidence that there's no bugs in what we're enshrining. And end to end formal verification seems to be the the best strategy to go forward. And what we want is to formally verify everything. The mathematics including the proximity gap theorems, the cryptography including the soundness of the PCS, the POP, the circuits as well as the correctness of the code, the formal imple the the reference implementation in Rust of of

the the signature verifiers. And I'm actually relatively bullish that we can pull this off. This has never been done before. Uh but I think we can pull it off for several reasons. One is that we have a very modular stack as we'll see and we're kind of incre we can incrementally bootstrap with bite-sized chunks and eventually hopefully build up to the whole system. Um and we're also putting a lot of resources towards formal verification. So Alex Hicks is leading a $20 million program um to be this money is to be spent over three years uh to accelerate the tooling of formal verification. And we also have AI which is promising to help us do a lot

of the grunt work hopefully over the next few years. So those were the postquantum uh feces basically shaping uh the direction and next I'd like to uh share a little bit more detail about the stack but any any questions so far happy to take them otherwise uh we can take them at the end. Okay, let's continue then. So post quantum stack. So the our stack is basically made out of um two parts. We have the the the leaf signature which is hash based um and uh that's the signature that the attesters would be uh

generating and then we have this aggregation machinery with the snarks. Of course we're starting with a hash function. It's a snark friendly hash function. So it's relative to a field. With the hash function, we're building what's called a one-time signature scheme in OTS. And then once we have a one-time signature scheme, we can easily build a many time signature scheme uh by concatenating multiple of these onetime signatures under a multle tree. And the specifics that we have here is paid onto as you know the industry standard snark friendly hash function very much trusted very much uh scrutinized and koal as arguably the most performant

field that you could pair with with the son 2 because of the fact that it has an sbox uh with only a power three um for the the one time signature And for the the signature, we're going with Winteret and XMss, specifically ZK optimized versions of of of Winteret and XMss. And that that is work that has been done by the film foundation to optimize these schemes. And then for the snarks, uh what we're suggesting is to use were because it has the smallest uh uh proofs that that we know of for the PCS as well as super spartan for the POP because

simple, elegant and and and powerful uh proof system. We've built our own custom ISA, very very simple, very minimalistic with just eight instructions. Uh somewhat uh largely inspired by uh by Cairo. Uh and we also have uh a custom aggregation program that is capable of verifying uh and multiple XMSSS signatures but also recursively verifying the the the proofs so we can have recursive aggregation and that's a whole multi- signature scheme and what we like to do I like to do is to add the lean prefix in front of these things. So for example uh the lean ISA

the lean SIG lean multisig and and that's basically because it falls under the the umbrella of lean Ethereum and lean consensus which is one of the big future upgrades that is being proposed for Ethereum. Now one of the amazing things is that this whole stack we're hoping to be able to spec it in about a thousand lines of Python code. And here we're talking about the cryptographically relevant part which is the the the the verifier that's subsumes the essence of the of of of this of the signature. And part of the reason we have con conviction that this is possible is because we have a draft specification for the first six

layers all the way to superpartum. And that's about 500 lines of code. And so one of the things that we've tried to strive for is just absolute simplicity and minimality uh and and overall reducing complexity. Now if you were to zoom out and look at the the the broader stack there two more layers that you could add. One is the peer-to-peer layer that the clients are working on and then there's the clients themselves which is the software that's going to wrap all of this uh for the the postquantum deets and test nets and eventually maintenance.

One of the things uh that we've been working on uh well Emil has been working on I guess for the last six weeks is uh to improve the performance of a aggregation. This is one of the last things that we need to do to derisk this direction and um you know we've basically roughly had a 6x improvement over the last five weeks. Uh and we need another 6x improvement to get to where we want from a performance standpoint. And we believe that we can can get there given uh given known optimizations.

Okay, final word uh final words on the postpoint workshop before I open it up for for questions. So one of the things that I want to stress is that even though we have you know this very exciting northstar that you know is going to play out over multiple years we want uh to be kind of nurturing public goods as we go along and there's a lot of public goods uh out there and we're basically hoping to lift all boats and a lot of the attendees uh in this room are you know creators and nurturers of these public goods. So for example, we have Angus who discovered qualar we have uh who co-authored Pon we have Elon and and Jako co-authors of

war were uh we have um sleuth author of logo we have all of the authors of lean sik Mitri Mikuel and Benedict uh we have Emil who designed and implemented the lean ISA we have the maintainers uh you know Angus and Tomar of Clunky 3 and we also have the creator and maintainer of Arclave uh Quang one of the the the formal verification libraries that we'll be leaning into.

So what uh we've done is that we've split up the attendees into four different groups. uh postquantum definite. These are mostly uh client developers. Uh they're not cryptographic cryptographer experts, cryptography experts. And then we have more on the cryptography side, the theory, the implementation, and the and the formal application. And for each of these groups, we're going to have a um a coordinator uh as well uh as a as a as a technical technical lead. So on the left is the the technical lead and and the the coordinate. So those these people are your your your first point of contact and they'll be helping

facilitate uh over the next over the next few days. So one of my last slides I want to try and highlight some of the open problems that we'd like some of you guys to start uh thinking about. So for the postquantum uh DevNet group, one of the uh goals is to try and have some sort of a demo of the very first death uh where you know multiple clients are talking to each other, they're signing messages. Um and I'm also hoping that we can make progress on the peer-to-peer uh topology for the aggregations with the various subnets. There's all sorts of of of a design space. Camille will be talking

about that. for the postquantum theory. One of the biggest open problems in the space is the uh proximity gaps conjectures. Can we make progress there? You know, the foundation is putting forward a million dollars, but we don't have the rules of the prize yet. So hopefully we can um make progress on setting the rules. Um and there's also some potentially lowhanging fruit in trying to further optimize the win signatures, specifically the encoding uh part which is now uh you know no longer the bottleneck versus versus hashing uh for the implementers you know two big open problems are one are we on the

right path with recursion with the lean virtual machine the industry hasn't yet settled and converged on on on one design there's all sorts of different ideas floating about can we pick the best ideas and another um valuable thing to work on is can we stream our implementation of where up to plunky 3 so that the whole ecosystem can start making use of punk3 I know that punky 3 is like the hot new thing that everyone's starting to implement I know that you know SP1 risk zero openm and others are embracing punk3 sorry aware it is the the new hot thing uh and can we help accelerate this public good and for uh for more verification

you know we have a long road in front of us in multiple years. And so can we have a a credible plan to doing all of the formal verification that we need and also can we try and accelerate the development of UPLIB and hopefully nerd snipe a few of you in this room or you know watching the recording online to help with the the the formal education. So uh this is the agenda over the next uh three days for this morning. We're going to have about 10 different speakers give very short talks uh providing a little bit of context on the lay of the stack that they're working on and highlighting some of the open problems. Uh we're going to be meeting

uh every day uh at 9:00. Doors will open at 8:30 and we'll be closing every day uh with a quick debrief at at at 5:00. Uh and there will also be a group photo which we might move uh slightly earlier so that everyone everyone can make it including those who are leaving slightly earlier. Final slide tonight uh we have an opening dinner. Uh we're doing something a little unusual which is we're punting to the restaurant. Uh very Cambridge thing to do I guess. Uh and uh the closing dinner on day three is a very very unique uh thing. So, I've been in Cambridge for 18 years and I've never

done this. Uh, so we're basically having dinner in the Cambridge Union Debating Chamber. Um, I don't know how how will pull this off, but yeah, it's it's it's very unique. And we're also going to have an exciting uh speaker uh giving a closing speech. So, that is going to be a local Cambridge entrepreneur. He created u over 10 years ago a quantum error correction company and his company now has 150 employees and they're like one of the well they're the world leader in quantum error correction and so um Steve will be giving us the the a snapshot of the the progress on postquantum computing sorry on quantum computing

which I understand is is very exciting and that's it thank Okay. So, we have few microphones for anyone who has any questions about the workshop. I know we shouldn't trust any deadline you give, but what's the timeline?

So, uh, when I first introduced, uh, what was what was called the the beam chain about a year ago at at Defconnect, the the timeline slide that I presented was the most my most hated slide ever because the timelines were so stretched into the future. uh it basically uh had um a four-year development plan and we would launch uh like late 2028 or early 2029. Now the good news is that um a lot of a lot of incremental updates are happening on Ethereum between now and then. And the other piece of good news is that the timelines haven't changed.

Uh I think we're still very much on track with what I initially presented. Um I think a lot of the the uh the the time will be spent on the formal verification on on on on one side and a lot of this time will also be spent on on testing and the reason is that it's going to be a very big upgrade to Ethereum on a similar scale to what we did with proof of stake. Uh we're going to have many different clients involved uh you know potentially 10 different clients. And so um you know I kind of allocated a whole two years just just for testing. Um but I think you know a lot of the exciting fast-paced development is happening right now. Uh

and now is basically an opportunity to uh to you know make a big contribution to the to the overall design solidify it over the next kind of year maybe a year and a half and then after a year and a half basically only work on on on quality through formal verification and and testing. So if if the proximity prize does not get solved in four years, then what do you do? Do do uh do you rely on conjectures or not?

>> Yeah. >> Yeah, that's that's a good question. So one of the advantages of our modular design is that you know we have the two parts. We have the leaf signatures and we have the aggregation. And um really what we want to do is make sure to never change the leaf signatures. That should be signatures that we have for the next you know centuries if not millenna. Um and the nice thing about those those leaf signatures is that they're provable secured. They're provably secure in the standard model and we can kind of aim for you know 128 bits of of security um without any conjectures.

Um, one possible way forward is basically to if we need if we need the extra performance juice um would be to um rely on on conjectured security uh and then basically at some point in the future um either prove the conjecture or if the conjecture is disproven um kind of increase the the parameters and that would be like a relatively simple hard fork that again wouldn't change the leaf signatures or if we don't need the which would be the best outcome possible. We just launch from day one uh with uh without relying on the conjecture.

>> What's the state of proving posed to strength? >> Uh so the next speaker literally after me will be talking about uh pedon. Um what I can say is that the foundation is putting a lot of effort into uh so just this year in 2025 I believe we organized three different workshops and we're organizing a fourth workshop very very very soon I think we've given maybe you know half a dozen grants to world experts crypto analysts uh and the other kind of cool story kind of coincidence is that when Satoshi picked chhatter 56 chapter 56 was eight years old when

picked ketchup. Ketchup was 8 years old and in three years time when we plan to launch the inner pose for 2 will be eight years old. So kind of eight years old is kind of the baking time I guess for these hash functions and not only are we accelerating and putting as as much resources on on crypto analysis, but there's also this very natural bug bounty program through billions of dollars being secured today on roll up ZK rollups that that use Pon. So I'm hoping that by the time we launch we'll have hundreds of of billions of dollars secured by Pon and it will be seen as a trusted.

Um, so what is the expected performance or like desired performance of the of this link VM and how many GPUs do you expect people to throw at it to to be able to prove, right? Uh, great question. So, Ethereum today doesn't rely on GPUs at all. like all of the validator nodes are CPU nodes and the best outcome is that CPUs are sufficient to do the aggregation that we want and it looks like we can get there. So the goal that we're trying to reach is a laptop CPU doing a thousand XMSSS signatures per second and when you do

the parallelization across subnets that is sufficient uh to to reach the performance targets that that we have. So the answer is basically zero CPUs uh sorry GPUs. Um now it is possible that in practice someone will be using a spare GPU that they have and they will get 10x the performance that we have on the CPU. Uh and they will you know plausibly be able to single-handedly prove all all of Ethereum on on this one CPU but you know we're aiming for the lowest possible barrier to entry which is just the laptop CPU and specifically a thousand signatures per second. Well, there is another performance metric which is how fast can we do the aggregation of

aggregates and that's really what we're looking at is 2 to1 recursive verification and my hope is that over the next few years we can get this significantly under 100 milliseconds but as of right now kind of the aggressive target is let's say 100 milliseconds um but yeah I think hope I mean we've seen that over the just generally get better. Uh, and getting getting that under 100 millconds would be really amazing. >> So, there's a lean VM and a lean ISA and they verify the leak signatures. Yes.

>> Is two-part question. Is the lean VM intended for other applications as well? And uh if If not you consider just basic circuits for lead sig lead verification >> right so the ISA is designed to be like very flexible it has general purpose instructions like add multiply a memory instruction the jump instruction and then basically a a hashing instruction and the hope is that we can build a general purpose virtual machine for any hashbased cryptography so it doesn't have to be you know xmss signatures it could the ST signatures. Um, and my personal hope is that we do such a good

job on quality, meaning security, and modification and performance that it becomes the de facto standard that all the blockchains use, just in the same way that ECDSA is the standard that every blockchain uses. Um, and you know, my hope is that even the Bitcoiners will like it, right? the technology will speak uh for itself. Um and actually I have a slide here for the Bitcoin. So um here's the the rough uh design space. So let's assume that we only have one CPU for aggregation. Um we can either have stateless signatures uh so those are the signatures that you would want at the application layer or the stateful

signatures which are the ones that we're using uh on on Ethereum. And if you go from stateless full you get a 10x performance boost and then on the choice of of hash you can e have a snot friendly hash which is peron or not unfriendly hash which would be sh and again you get a 10x performance boost now what I expect would happen is that the bitcoiners would want uh this square right they would want like to keep the hash function that they have sh and they would want it to be stateless uh and you would only only be able to do 10 transactions per second or 10 signatures per second of aggregation.

But that's fine because Bitcoin only does three transactions per second. Um so we would use here uh the uh this this quadrant for for proof of stake and then if you move to a world where you have a one single GPU then you get a 10x performance boost. Um and now you can imagine for example having uh the rollups uh you know the high performance blockchains like Solana uh using uh using lean VM as well uh for the for the post quantum signatures.

So the reason we have a link VM is because um aggregation is non-trivial for hash functions. But what happens if we have folding uh like NO uh that solves the issue? We don't need the link VM anymore. Yeah, great question. So, folding is one of the possible answers to alternatives to to recursive SNS. There's I guess a couple things that I'll say. The first one is that folding is not as friendly to collaborative aggregation. And the reason is that the you have to pass these witnesses in addition to proofs which will significantly increase the

proof size. And so, the cost of collaboration is just much more communication. So I think we need to wait and see what the concrete numbers are to see whether or not folding is is a possibility or a non-starter. The other thing that I'll mention is that even though folding uh can help in certain ways, it doesn't necessarily mean that it would completely remove the virtual machine. you still need to verify, for example, that the folding was done correctly. And if you want to have short witnesses, you might need a little like state machine or virtual machine um to to basically reduce the the size of the witnesses. So imagine

for example that a signature, you know, you're verifying a 100 hashes, this the witness for 100 hashes is 100 times larger than for just one single signature. And so you can imagine only wanting to fold uh a single hash, but then that means that you need to have a state machine in order to to keep track of that. So, a lot of researchers are looking into folding. We're in touch with them, but at this point in time, I'm very slightly bearish on on folding relative to recursion at least.

>> Question about um recursive marks and their security because they inherently have this like heristic step in the Were we instantiated on? >> Yes. >> Do we feel okay with that? Do you want to look more into it? And >> yes, >> I feel like maybe we can't afford it. >> Yeah, great question. So, a couple answers here. Um, the first one is that we are looking into it. We've given grants to researchers, some of them in this room, to look into the security of of recursive knocks. Um, the other thing that I'll say is that going back to the separation of concerns between the leaf signature and the aggregation, we want the leaf signature to be like World War II proof like is going to live for the for the rest of humanity never changes

if for whatever reason and that's provable in the in the standard model under you know collision resistance um and there's there's no recursive uh recursion and so plausibly know if we some sort of an attack. Uh for example, you know, there's a Mitri and Le's paper, right? Like they found this very specific edge case like potentially we could just fix the edge case by just changing the way we do recursion. Um I believe maybe Elon had like a new paper where they do like proof of work or something like I think we would want to have as much of the mitigations as we can given our best understanding. Uh but yeah, for sure it is one of the gaps that that we would likely have when we launch.

>> Okay. Uh final question and then we'll have Antonio talk about >> Hi, thanks. Um I just have a really quick question. Uh at a high level um in the in the stock road map do you have some sort of milestone from the perspective of sort of um putting out um an like a real time proving implementation or some kind of like performance um benchmark that you are sort of laser focused on that all of this research converges to or something like that just to understand sort of how far away we are from the um the realization of such implementation.

>> Yeah I mean Um so we have this uh lean multisig repo. Uh we can share the link in the telegram chat. Um there's like various graphs that keep track of performance. This is one of the the key ones like how many signatures can we aggregate per second. Um you know we believe we can get to a thousand signatures per second but we can get 2,000 3,000 10,000 on a CPU. That would be amazing. Um now there's there's all sorts of of places where we can squeeze performance. So um for example for were if we have if we can prove the proximity gaps conjecture that does a 2x you know squeeze uh at least on the on the recursion. Uh for the winter this is

going to be an open problem that we will discuss. If we can improve the the encodings we potentially can squeeze a 2x there as well. Um I just heard from someone in this room uh that he's working on, you know, an improvement potentially to work, uh a very significant improvement. I don't know. Uh that would be fantastic outcome. Uh maybe we'll have better POPS and we can squeeze a few percentage points here as well. Um there's a lot of room. This this is work that literally is a few months old.

Emil has been a grantee of different foundation for only three months and um you know there's probably some lowhanging fruit to be had here. If you're a compiler expert right like what what Emil implemented he created a new language and a new compiler that compiles down to lean is there's probably a lot of juice to squeeze to generate better lean is bite by code for for for the recursion. So overall I'm just very very optimistic that the performance will be good enough but you know we still need to do the work and it's quite exciting.

>> Okay last question. >> Go ahead. >> So are you worried about the recent attacks on here all this? >> Um I'm thinking of some counter Okay. Well, this is a question for you. >> I am worried. >> You are worried. Okay. Interesting. Um, then let's talk about it during the workshop. >> Okay. Thank you guys. And, uh, yeah, Antonio, the floor is yours.