PQ Ethereum Workshop - Day 1 Recap

Transcript

Um, we're going to start the the debrief session in about 30 seconds. Um, I'd like to invite all of the technical leads or any notetaker uh to come forward for for any of the sessions uh and basically share some of your learnings. Um, so we've had four different sessions uh two, you know, two parallel sessions. I guess we can start with the deathnet specs. Is anyone from that session who would like to give us a quick summary?

>> Um so I'll do the first part and then uh Raul will actually summarize the networking part. Um so we basically discuss about like the priorities that we want to achieve for for these uh three days. Um right. >> Yeah. And so so um what we discussed is that for for day one we just started um talking about the the P2P networking and the different designs and how we incorporate that whether it's going to be in def one or two and it looks like we decide that we are going to be pushing some some networking um changes into definite one as well. Um hopefully but that's still to be confirmed but that's what we are aiming for. Um for tomorrow um we're going to be focusing mostly on the three client interop. So

one way or another we'll try to achieve proper like interrop between the three clients uh museum beam and clean tomorrow. um also disc sorry start implementing the spec test uh to confirm that all of the clients are are working together and then on the third day we'll be discussing about the net spec so so all the details regarding the P2 that we for one um and some discussion about signature aggregation I think the recursive aggregation is likely not ready anytime soon but we discuss about whether we can just do like no recursion so so basically just single signatures to mult signatures and then concatenate those aggregations as as part of some maybe deplet.

>> So so that's the the specking part that we discussed about and then maybe >> yeah so for the peer-to-peer part uh we went over different designs and specifically how uh lean would integrate with everything uh with the networking stack evolution that's also happening in the L1. We just uh set up the team at the EF that's driving a lot of that road map there like we're thinking of two different stages. There is kind of like from Libby to be going into a more minimal this is like very early so please kind of like for now um like keep it in this room. I want to make an announcement um like a broader announcement about the direction here.

Uh but basically going into kind of like a minimal distilled version of libby that consolidates the transport that redesign some of the u machinery inside lip to make it more mechanically efficient in general with the protocol and then expanding from that into a more specialized Ethereum uh specialized networking stack that instead of using a single um Gossip sub or gossip implementation for all different object types which have widely different characteristics in terms of sizes, dissemination uh patterns and so on actually reasons about each of the objects as a distinct broadcast um requirement. Uh so

basically building more dedicated protocols uh on top of like a more mechanically efficient stack. Um so kind of like that was the the one one big part of that. We went over many ideas um around um things like for example our browsers and mobile devices and constrained devices first class citizens of the network or not? Are they do they interact through an edge layer? Um we went as well uh like we we went over is every uh node that wants to join the network should it be a fullyfledged participant of the network or not or is there like some form of proof that we can make that a node like for example proof of validator that a node is

effectively valid a validator to uh build kind of like a high um performance like propagation layer between all these stakeholders and the network things like that um we eventually decided that for DevNet one we're going to be uh iterating on the gossip layer to uh build and uh simulate propagation of uh aggregates through erasia coded broadcast instead of gossip sub and this later would be like that that would be initially for global global aggregates then we percolate it down to subnet aggregates and all throughout we need to figure out how we going to do like the initial signature dispatch which is like the most intensive part of the protocol

and that requires more research. Um so those are some high high level notes. >> Love it. It sounds like you've had all of these ideas kind of in the back of your mind for improvements to networking and this is like the perfect playground and test bed for these ideas. >> Exactly. Yeah. And I think the lean theme in general, that's something that we've been wanting to explore for for a while because >> yeah, what we have right now is kind of like a general purpose networking layer that like and the way that we use it is very bandwidth inefficient, >> right?

>> Uh so as we push the the boundaries um it's a good opportunity to to re-engineer things. >> Yeah, that's fantastic. Um and oh, going back to your point that we don't have recursion yet. I guess I'm curious to hear like from Emil like when do you think we would have recursion and is that something for death one death two tonight? So maybe net one is actually reasonable uh to have have a um great anyone else from these sessions who want to bring up a learning that they they got key insight now we can move to the more theory sessions. Okay, thank you so much Owen.

Thank you so much. Okay, next up we have three sessions Benedict. Yeah, so we had a session on the proximity prize which I think was very useful for all of us to sort of see what the the questions are that that uh we need to answer. So what are the rules of the prize? When do we award uh results and how do we even decide which results to evaluate? uh and I think we made some progress there with respect to for example how to do some sort of spam protection for the judges so that they are not like spending uh 247 to to evaluate things. Uh so for example limit

the amount of submissions uh per per submitter or have sort of a ranking uh among the submissions depending on what kind of criteria they satisfy. They will be evaluated sooner or later or have sort of a keep track of a list of known to be flawed proof approaches that sort of show up over time. And we made some progress with respect to how to present it and advertise it uh to to communities. For example, the an article in the AMS uh some Jako suggested some press tours and workshops and ramp session at Stock and Fox. Uh then also doing like numerical experiments and

presenting them in the journal of experimental mathematics. And uh yeah, I guess the while the goal was stated to be reach agreement on the rules, I think this was a overly ambitious goal and I think it's uh nice that we now sort of have even more questions about what the rules should be. Uh I think that was also quite useful and we will have a continuation of this session uh in the proximity jam session. So Jak was there anything you want to add?

>> Well, I think we We have a lot of work to do. We need to get a move on and start uh writing things down like I think you know there's a lot of question in theory side but there's also question on like the it's called the administrative admin administrative way. So yeah, like if you want to like uh I think the price is already garing some attention, I think we just need to make sure that we get something uh you know good enough for when we when we decide to like properly announce the rules. So I think we just have to move on.

>> Yeah. Does anyone else want to add something? >> Okay. So we can move to the final session which got high technical and lots of parallel discussions. So I guess Jacob, do you want to kind of or anyone else who who had some learnings about this this very dense session? >> You couldn't use any with any linear code.

>> You can use with any linear code. That's a great property unexpected one that you can't explain. >> Yeah. No, it's weird. I don't know. >> Um there's one optimization around using base fields for the eval. Um >> yes, exactly like uh we like by changing a few things like we think that we can do a lot more of the first round in the base field which should give us like some good optimization over there. There's some optimizations with respect to out batch the in domain samples and there's some optimization about like figuring out how much we can shift from the polomial into the PCs. So I think >> again does this mean that your your

multilinear is over a small field to begin with? >> Yes. >> Why not just use ring switching? that the way we can do it >> then you have a fully blackbox invocation of war over the big field and you don't have to >> worry about >> this something else that we can do like I actually something that I think we should at some point uh figure out like to me like I wishing I don't have any feeling I know you guys have considered it and I want to figure out a bit more of the thating extension degree which is a power of two.

>> Yes, >> but it works. The issue is that if you want 128 bits of security even with the up to capacity conjecture, you need a degree five extension of >> that's a pain in the ass. >> Yeah, >> make five. I feel like that it's a shame that such a kind of seemingly technical obstacle would disqualify >> I think you could maybe get around it somehow.

presumably. >> Other question with ring switching. If we >> if we do need ZK and have ZK as a requirement, do we have techniques to get ring switching and zero knowledge? >> Um yes, I mean using the sort of blackbox IO. Okay, >> you don't leak the sizes of the actual things you're dealing with >> the sizes >> with your ring search. Don't you have like you're you're packing very small witness information into like larger field elements, right?

>> Um is that leaking to the verifier the sizes of the witnesses >> field over should be known to the verifier. Right. >> So I don't I don't think that should be a problem. other words. >> This should probably be a side discussion. >> Any other learnings? I mean, one learning that I got was that uh I think Angus believes that the DFT is like highly suboptimal maybe in Punk3 and we have this way of potentially measuring the efficiency which is like look at the number of multiplications that you need and then measure that and then take it relative to the actual running time.

>> Yeah, better paralization. Like I think this technique like of computing the arithmetic intensity of the program you're dealing with is like in high performance computing is a is a very like well used thing like like if you go model >> exactly like uh this is how they for example Google publishes the performances of their GPU model for their GPU processors. So like it's is very good like if you understand like what is the theoretical maximum of the system that you working with and the address utilization then you can really like uh do a lot of cool stuff. Yeah, maybe we should add that to the like a lower bound >> best implementation of where possible.

>> Yeah, for example, I don't even know if anybody did like roof line model for like field multiplications and field like operations. >> It's not for log end. >> Yeah. >> Uh because you have uh n login operation for end data. to your roof line model like there will be like more band memory. Yeah, like uh there's also like uh things to try with cache oblivious like the algorithm. There's a lot of things that we try with that. Yeah. So on FFT you have uh either you can express it at recussion and um in that case you can um if you do uh uh depth first uh iteration

uh the things that stay hot in cache uh and but I think lots of library are using the iteration things to uh remove the function called cost. uh I guess it needs to be benchmarked and also the bit reversal permutation can be optimized maybe away as well depending on uh how you arrange things. >> Yeah, in one of the original like implementation we also had the square root FFT approach uh which according to RO I have no idea how these things work.

It's quite good for like the cashness part. So that turned out to be I think it's quite nice. I don't know how it compares with the plunky free approach. So it's like all you know the FFTs there's a lot of tricks everyone can play >> probably another side discussion. Um I mean one of the meta learnings for me is that a lot of people that I thought were kind of very deep in were and kind of experts were asking a lot of questions and so I feel like very few people understand the guts and all of the implementation details and there's possibly a lot of juice to squeeze from the fact that we're all just learning on the fly right now.

>> So I think uh everyone uh missed uh some optimization that were coming from uh lat cryptography. Uh there is this uh I think so far everyone is using Montgomery representation for helping but there is uh something called plantar arithmetic that was released in 2022 and improved in 2024 is about 20% faster for uh field multiplication on small fields. >> How does it look? >> Uh I can send you I can put uh uh my research uh in the uh telegram channel so that people can have a look >> other operations the same like is

addition the same >> uh addition is the same speed but it's field multiplication that's uh much faster >> curious if Angus Nico >> Ben have learnings >> I haven't heard this >> no this specifically just general learnings >> I mean I have something I want to push which is often this protocol the multilinear points are helpful for us to understand it and to write it out but our implementations don't really need to think about them right and yeah we can just deal with raw data and just reshape it and deal with matrix check products and I plug the le implementation as maybe an example of how to think about

these things >> and please serialize properly like this something over the summer If you're proof >> you can very easily use a transcript API instead of >> well it depends because you also need to have a miracle tree API which supports capping and buning for example so you know this tend to be a pain for recursion but not in native and there's a lot of these few things that yeah you know if you want to if you need to squeeze the bandwidth >> like I think we see like the work implementation is like 20% redundant something like that. So you know if we need extra bit

we can also do that which maybe it was a learning conversation but I just want to point it out. Yeah. Okay. Perfect. So this concludes our first day. Thank you so much everyone. So we'll meet in 15 minutes. So that's at 5:35 at the porter's lodge um just uh next to the big chimney which is the the big entrance and then we'll all walk uh together to uh to go to uh to the restaurant.