PQ Testnet Roundtable: Signature Aggregation

Transcript

um this this postquantum test net as quickly as possible and hopefully by the end of this week Tom can prep prepare a report detailing all of the next steps uh to uh to get to get that test. Okay, Tom. Thanks Justin. So hello I'm Tom. I work at EF as a researcher or project manager. You can call me what you want. Put the slideshow better. So today I'm going to present you briefly like the postquantum Ethereum and more precisely the postquantum signature aggregation. I will try to do an overview talk. A lot of technical details have been talked this morning. So I will not go again

about this but more about what we have done so far what needs to be done and what's need also to done right now. So about postquantum materium as we can see as you may have heard like postquantum things are not just science science fiction it's need to be done a lot of tech leaders say that quantum computer can become a reality in five to 10 years we don't really know but this is a real really important situation for Ethereum and we need to be prepared so right now the problem is that we have BLS signature enshrined into the consensus And to prevent like postquantum attacks

we need to change this model and we need to have a new signature scheme. So for this we thought about different solution of course and like XMSS is one of the most promising one. This has been presented this morning. So I will not go again over the details of this but this is one of the possible candidates. For now it seems the best one but we need to investigate also of course other possibilities. You have amazing research posts that have been made about latis stuff and all of these things. So this need to be open. But the problem with this signature scheme is that the the aggregation of them to submit a proof on on Ethereum is a bit more complex than

BLS that were that was very easy to aggregate. And also the signature size it's a a bit larger than BLS was with 2.5 kilobytes or 3 kilobytes approximately against only 96 bytes for BLS. So we need to handle like this larger signature and harder to aggregate signature for this. uh as XMSS is an ashbased in nature as it was presented this morning. We need first to benchmark ash in stock. And so it was our first uh ideas to do this end of last year by hand. And so what we did is that we benchmark a different hash function such as

classical ones, black three, ketch and like snark friendly one posed 2 over different proof system to see a bit what can fit and what would be the b best choice both as a hash function and as a prover system. So as you can see on these charts like procedon 2 clearly stands out. This means that with plunk history as you can see on the left you can aggreate you can proof in a stark approximately 1 million on a classical 1 million hashes per second on a classical CPU where while the other ash functions such as blree or kak are way way slower.

So this lead up to the fact that probably at the moment posed 2 is our best choice for the for the ash function and our this initial benchmarks by studying all the proof system and studying the different ash function revealed principally three major adults for onchain usage. The first one was the prover speed. We need something that is pro that is fast to prove uh to be used onchain for the ethereum future. We need also something with a reasonable proof size. We cannot afford like one or two megabytes proof. We need something around like 128 kilobytes something around this. And also the like the the bottleneck that we have right now

between fry performance and proof size. So I have listed different elements in the table where I put different comments. So first procedent two is the best choice for now as a hash function. Second fry leads to very fast proof but they are often too large of the order of one to two megabytes. Recently we talked with Jako with the author of the we paper and like we is a reasonably like optimistic way to do a PCS. Why? Because the prover speed needs to be improved but we know that there are a lot of rooms for improvement and we are discovering that each week. But on the other side, this is to very small

proof of the order of 128 kilobytes and very fast verification time. So this could be a very promising alternative and we pushed a lot of effort on this. And we have also three different other topics that are under construction and that I will detail over the next slide. So as I just mentioned at the Ethereum Foundation, starting from this uh all all of this context, we started to push an a effort So we basically is a PCS so a polomial commitment scheme that can be directly introduced into our proof system to aggregate together signature.

So it is based on two main principle. The first one is a recursive folding inspired by steel and fry. So at the at the the beginning you start with a very big polomial problem and then you shrink your polomials step by step round by round similar to steer or fry plus you integrate during each round a sum check that is inspired by best fold and other works that are doing some check for having at the end a very lightweight verification. So now if we try to integrate this weird PCS into our signature aggregation we can have very tiny proof of the order of 100 kilobyte that is perfect for us. We can have also microscond verification

and this is very important to have this low query query complexity to have ultra fast verifier that can run on chain and we have also finally a postquantum alternative to what we know today. So right now with this setup we can achieve on like a quite performant GPU like a 40 90 1 million hashes per second over a wallproof system with this uh tiny proof and on the CPU consumer laptop we achieved recently like 100k hashes per second and our final goal is to have 1 million hashes per second to be really performance and be able to consider that as a possible alternative uh to

aggregate the staff related to that we have like two different ongoing effort and one started effort so the first two one is the XMSS hair so it's a work led by Han from the beginning of the year so is a transformation uh the transformation of the XMSSS signature into into an air constraint system you have a repo and a technical note there when you can find all of the details about this arithmetization thing and all of the work that has been done and also on the side we have like a POP system that has been developed by Emil and that is tightly coupled with weird effort because we can um we can make the two

together to have a warp proof system to aggregate the signatures. So this basically encodes the entire system into a single multilinear polomial instead of univaried polomial on each column and it use the same check instead of the coian polomial. So thanks to this we can have very small proof and we are starting to optimize things week after weeks and we started very recently the recussion effort. We have a lot of background a lot of research that we have done since couple of months about the recussion meaning that we should be able to aggregate together fresh signatures but also fresh signature with proof of aggregation of signature. This is

basically the recussion that was explained by emit this morning. For that we have different possibility and a lot of research to help. We have the it proof um initiative from the Ethereum foundation where we have a lot of feedback a lot of alpha from the different ZKVM vendors and this is a place where we share some numbers benchmark solution uh and all of the research effort ongoing about the ZKVMs and we have also a lot of academical research paper about like folding scheme accumulation scheme latises technique that can lead to some recussion So the solutions that we have identified as possible for the recussion are

twofold. We have a medium long-term research perspective that is about folding and accumulation scheme and a short-term solution that is a minimal ZKVM. On the long-term side the folding accumulation technique seems very promising because this is a single mathematical model. You can code that but we need much more feedback and much more perspective on adoption plus implementation or tooling. We can think about VAB or uh Neo on the latis side but we have at the moment no existing implementation. So we cannot have enough feedback to say that it will be the the proposed solution. But on the short term we have like the minimal ZKVM. What is that? As described by Emil this morning,

this is a very minimal ZKVM that can handle this recussion. And on this side, we already have a lot of feedback and we know that is tractable because we know that all the ZKVM vendors almost 30 at the moment have done like general purpose computation with this DKVM. We use a lot of different techniques that we can grab inspiration from. But here our design philosophy will be completely different because we don't need to be general purpose but we need to be to be application specific because we only need to aggregate the signature and not do any arbitrary computation. This is not the purpose of this. We need also as a result of that a very minimalistic ISA

with probably one or two like built-in co-processor and not 10 of them. And we need also a very simple uh predictable recussion model and a very simple memory model. So to finish the talk I will just mention and it will open the session about like the round table what else need to be done. So we need a python spec this will be a reference for future implementation to onboard new contributors to onboard client teams uh for them to have a reference for the implementation.

This is very important and this will be a tricky one because we need to have spec for different aspect. For example, we have the PCs that need to be spec out. We have the PI POP we need to be spec out and we have also probably the minimal ZKVM, the hash function, the signature model. So we have a lot to spec and also a test net. So at the moment we have only worked separately on uh the signature aggregation problem but we have never tested compatibility with all the other bucket of works of the beam chain. So we need to run the model in reality with the other components the peer-to-pe layer to know if this will be a good fit if and if everything will

will be okay. So yeah that is my the end of my talk and that will probably open the round table. Thank you. [Applause]