Ethereum PQ Integration

Transcript

Okay, cool. Um, yeah. Hey guys. Uh, today I'm going to be talking about uh postquontum and in particular uh how we plan or one way to integrate postquantum into Ethereum. Uh this slation mostly focuses on the CL. But if you want to ask questions about the deal and the EL uh feel free. Uh also if you see something that looks uh like you don't understand it, feel free to ask questions. Um, some of these slides do assume some knowledge about Ethereum.

So, if you see an acronym that doesn't make sense or something like this, feel free to put up your hands. Um, yeah, I encourage questions. Uh, so why am I doing this slide or these slides? Uh, essentially we have a plan for how we want to integrate Postquantum into Ethereum and as much feedback as possible uh would be great. um especially from experts like you folks. Also the scope of this seems small but once you zoom out and see the amount of things that we need to do um there's a lot from ecosystem planning even past the technical the technical things that

we need to um accomplish. Okay. So what is the problem? The problem right now is that Ethereum's protocol uh relies on pre-quantum cryptography and I have a bunch of cryptographers in the room. So, as you know, cryptography is safe because no one has found an algorithm to break it on the computers we currently have. Unfortunately, we do know an algorithm on a computer we don't have. And uh as you know the quantum scare tells us that uh this computer is coming uh well everyone has different timelines but this computer is coming uh let's say within the next decade. Um a different issue that popped up recently is that we potentially

may find an algorithm on the computers we uh do have uh with AI. uh we don't know uh what uh the probability of uh AI breaking or at least reducing the security of uh our current algorithms are on but it is still a risk that I think we need to um take into account. Uh so today what I plan to cover is uh mercy on the validators then the transitioning which is uh in my opinion pretty simple in conceptually and then just the sequencing of how I think we should uh get all the pieces together.

Just before I continue, how many people are roughly familiar with uh sort of how validators work on Ethereum? Like what validators are? Uh okay, this might be a rough next two slides. [laughter] Uh okay, never mind. Um so what I want to talk about is the validators the PQ material that they will uh now need to register uh the life cycle and their duties.

So with PQ the validator material is now uh 96 bytes. Currently uh on mainet it's 32 by uh sorry 48 bytes and the 48 bytes is for the BLS public key. The BLS public key uh has a lot of special properties. When you sign a message uh with the BLS uh with BLS, the message is actually deterministic uh with respect to the public key. So you can use it um for basically randomness or private uh selection if you want to call it like that.

With hashbased schemes because you can grind you don't have this deterministic property. So we do need uh extra material uh when we go to PQ and this is why we have a VRF tree route. We have two public keys which is pretty weird uh if you if you're familiar with the current validator scheme and I'll explain why in a minute why why we have this uh so 96 bytes. The first one is the attestation public key. Uh the next one is the nonatistation public key and then the VRF tree route that I mentioned.

Please ask questions. I it's [laughter] a mean like now in production or oh sorry when you mean what what is now now what is the plan or what is right now in production >> uh so right now in production we have BLS which is 48 bytes and you uh it covers basically all three of these the use cases that we have for all three of these >> but now it's written 96 with now uh that was >> uh you can think of now as in once we have PQ uh Okay, that's where I would go.

>> Okay. Okay. >> Um, on the consensus side, the scheme that will be used is XMSS, right? And so the, uh, keys are one time. >> Mhm. >> Yes. So those change every blocks. >> Uh, no. Uh so one way to think about it is that you have a Merkel tree of one-time keys and the root of the Merkel tree is your public key and that doesn't change. >> Uh is could you give an intuition again what why is VF3 root needed? You said some grinding.

>> Yeah, sure. Uh so if I go to the next slide and we just look all the way over to the right. Uh when you propose a block uh you also supply some randomness. um into the block as well. And obviously this randomness uh currently what happens is that you sign over some message and with BLS you can't sort of grind uh the output signature. With hashbased schemes there is a form of grinding. So we can't reuse a hashbased scheme to sign the message uh because the proposer can just grind uh to get uh a favorable output. Um does that make sense?

>> Uh slightly. I don't see what what is more favorable and what is less favorable. >> Uh you can bias the the randomness. >> I mean BLS is not only a signature scheme but also VRF because it's unique but uh XMSS for example is uh not unique right you have you can make it deterministic but that doesn't mean that it's unique because you can still use a different salt. Um, yeah, if you didn't have the salt, you could argue something like computational uniqueness, but we have the salt, so we need something else to implement the VRF property of BLS.

>> Okay, thank you. Um, okay. Any more questions before I Cool. Yeah, so what each piece is used for? Um, I mean, ideally we have one public key that's used for everything. uh this would be the perfect scenario and in my opinion it would be better if it would lean shrinks because it is uh stateless stateless in quotation marks because you can't really have a stateless hashbased scheme but let's just say because it's in practice stateless the issue of it is that it's a lot bigger in terms of signature size and in terms of aggregation uh so we use lean xmss for uh be for attestations em >> thank you I would say It's not um it can

be made not that much bigger like in terms of in particular if Linux MSS uh if you want to make it MPC friendly and we have these two layers it will be like 2 kilobytes in total and we can have 4 kilobytes sphinx that verifies in 300 300 hashes. So like two times bigger and 1 times more hashes at verification. So it's just say it's not 10 times bigger. >> Okay. Yeah. Uh my understanding was that it four around four times bigger. But if we can get something that's two kilobytes, >> it would be uh lfank I think we can make it 4 kilobytes.

>> Yeah, I think that might be a bit too big. >> Yeah, but like if ifs is on two layer trees then the totals is 2 kilobytes. >> Okay. Okay, that is true. Yeah. So it would only be 2x bigger in that case. But then you have optimization. If if XMSS is two layers, you can cache the first part and only send the bottom part. And so it's one kilob. But >> Right. Right. Right. Exactly. Um if we do go for this two-layer XMSS tree and it's a 2x in terms of uh the difference between lin xms and linx. I think we should re-evaluate whether we can just have uh lean spinx uh by itself without lins.

>> Sorry, I'm I'm a bit confused by it. So you say you want to go to this two- layer tree because of MPC friendliness and now you compare that to lean sphinx which is less efficient but it's also not MPC friendly. I mean then if you if you don't care about MPC friendly then you can just use the standard XMSS without the two layer tree right so it's a bit of a weird comparison but we can make friendly things but it will be >> so maybe we'll come back to this NPC friendly um uh question at the

Uh, a lot of this I'm presenting it as being normative, but there are a lot of questions like if you have questions and things just don't seem right, I think we can change things. Uh, but I'm presenting it currently as being some normative scheme. Ideally, we have one signature uh scheme as I said just because this is simpler. Ideally, it's not Linux MSS because that's also stateful. Um >> sorry Kev just very quick like what made you what was the consideration behind uh choosing uh lean xmss for these particular duties and lean things for the others? Did you mention this? Maybe I missed it.

>> Um right yeah good question. So uh beacon attestations are essentially something that we want to make uh aggregate as quickly as possible. Um which is why we're using Linux MSS for it. uh the PTC uh which is the payload timeliness committee. This is something that goes inside of the block. So if we don't uh aggregate the PTC, you basically have 512 times however big your signature uh scheme is. Um so we want the aggregation of that to be as quickly as possible unless you just put it in a block and concatenate the signatures.

Um and the assumption for quick aggregation here is like why like why does it happen more quickly than the others? Uh so the others don't actually get aggregated like beacon attestations you have about 32,000 of them per uh slot for the PTC you have 512 uh signatures for the others like block proposals it's just one proposal per slot so you can afford to have let's say a 4 kilobyte uh signature for example >> so there's no sync committee aggregation anymore >> um good question is on the next slide Um so what actually gets um aggregated um

there are three things roughly which is the attestations the sync committee votes and the PTC votes. If we start at the bottom the PTC votes are aggregated by the next proposal which means that aggregation of it needs to be quick which is another reason why we don't want to uh use lean sphinx uh for the PTC. uh the sync committee votes. Currently, uh we will need to aggregate it, but we're looking to just basically get rid of the sync committee. Um it I don't know what word to use for it, but it's like not being used uh that much and we're paying for it in Ethereum.

And then the attestations uh is the most important thing that we want to get for aggregation. Correct. Uh so we have 32 basically 32,000 signatures that need to be aggregated per slot. What happens is that these 32 signatures uh get split into 64 groups. 64 groups have 512 uh signatures each. You then use a stark uh or lean VM to aggregate 512 all the 512 signatures in each uh group. So at the end of the first layer you have your your leaves which are 64 300 kilobyte leanvm proofs.

Everyone good of that so far? Then we need the goal is to get one proof uh inside of the block which means that you now need to have this Merkel tree uh recursive aggregation to to get to the single proof at the top and uh you basically just have a 2 to1 Merkel tree going all the way um uh to the root. Mhm. >> Does all this assume decoupled consensus? >> Um, yeah, good question. So, I think most people are not familiar with decoupled consensus in here. Is that correct?

Okay. So, one quick way to think about decoupled consensus is that currently you have about 2 seconds to vote for the vote that's the block that's being proposed and you also vote to finalize a block in the past. With decoupled consensus, you have two seconds to vote for the block that's being proposed. And then for the block that's being finalized, you now have basically the whole slot. So it decouples these two votes. Uh which means that you now have a longer time to uh aggregate the finalization votes. And these are the votes that uh I'm currently putting up here when I say we have 32,000 per.

So this means that aggregation can actually take uh a long time essentially. And if we make it faster then it means that fi we we basically finalize faster. So yeah good question. Um so this is basically the most important technical component in my opinion for what we're doing on the CL side. Um how do we aggregate all of these signatures very quickly uh and put that proof inside of the block? There are multiple ways to do it. What you can say is that at the bottom we have 300 uh 64 300 kilobyte proofs. We send it to one aggregator. This one aggregator just grinds it grinds out and uh gets to one proof. A different uh strategy. So this

strategy really says that uh we want to decrease bandwidth. So we send all of the leaves to one person uh and then we just assume that they can recursively aggregate that very quickly. A different strategy is to say we have uh 64 leaves. Will will take let's say the first two. Kev will take the second two. Someone else will take the third two and we all aggregate it sort of in parallel and then we send it to uh the next layer. Um so this way basically says uh we'll basically sacrifice bandwidth here like this is very bandwidth heavy but compute-wise it's actually pretty good. It's more c uh sorry more decentralized as well. Um and these are

the two basically design yeah these are the two uh design uh spaces that I can think of right now. Is there certain redundancy in uh who aggregates because for example if in the trees thingy if someone fails to aggregate is there yeah >> yeah so currently uh when you see this uh committee there's basically 16 uh let's say aggregators per committee so there's a lot of redundancy um at the moment but also the aggregators don't get paid so which is an assumption we can make for BLS because uh aggregating BLS signatures is pretty cheap like just because uh BLS is has this algebraic

property but aggregating um let's say hashbased signatures is not as cheap so we may have to have sort of an aggregator role um this is something we're also thinking about right now >> is the go first Um >> no. Okay. >> Yes. >> Uh for the bandwidth. So today we have a uh uh recommendation of 100 megabits.

Would this fit into that or how much of an increase are we speak talking about? Um, so I I think we have simulations, but I don't think anyone has put those numbers down. I mean, one way to think about it is that currently we're sending around say 96 bytes for the signature. For these uh proofs that were that we now need to send around, it's about 300 kilobytes. Um, so I'm not sure. I can get the numbers for you, but it looks like we're probably just going to have to say that only a subset of the testers can now aggregate. Um which yeah wouldn't yeah it changes it definitely changes the topology um >> um besides bandwidth do we have some

expectation of uh hardware for the aggregators like do they need 16 core CPUs do we need a GPU because of uh the proof [snorts] >> um so we don't need GPUs thankfully um at the moment we have benchmarks with 787 70 hardware right now on x86 and ARM and it looks reasonable but it also depends on what you want your finalization time to be with PQ like if you don't mind finalizing over let's say 4 minutes or let's say closer to 6 minutes uh you can afford to have lower uh lower lower hardware requirements um we have a website with like rough numbers for aggregation um I can show it

after yeah >> is the uh unfin proof uh a stretch goal or what's the what's the rationale behind one a single proof versus multiple in the block >> right um yeah it's really a trade-off like if you have one proof in a block then that's the block becomes 300 kilobytes if you have two proofs in a block then you now have 600 kilobytes um so yeah it's really a trade-off at that point um a bit of a side topic uh currently we have the sync committee for light client Um, do we do light clients uh afterwards or do we just kill them?

>> Um, so I think about 5 minutes ago I talked about this decoupled consensus uh mechanism where you have your head votes and then you have this sort of uh finalization votes that you have. So we can replace the sync committee with this available chain committee or the people that are doing the head votes because there's only 512 of them. In my opinion, I think we should just remove the sync committee. Like, it's just not being used. It's being we're actually paying for it. Um, >> um, it can be replaced by a Stark. Um, [laughter] actually client sorry, light clients are never

been really a great success, right? So, I mean, do do you know any successful light clients so far? Uh, I think you'll have to ask uh Nikico Consini because he wanted to do um this uh private wallet with a light client inside. >> Helios. >> Yeah, we have Kohaku and it's using Helios. Um there are a few other ones as well. Uh, Canary is another one, but I think the cost right now is like $80 million a year if I recall correctly, which is >> probably

[snorts] less expensive, >> right? >> Yeah. Okay, cool. Uh so yeah if you want I think the f the if you can take away one thing from this talk like this is the most important part that we need to solve like how do we aggregate um all of these signatures as quickly as possible. Okay. So, let's go into the life cycle of >> uh is that something we could do a sig golf kind of thing for?

>> Um yeah. Uh that seems pretty hard because one of the constraints is networking here. Um so I'm not completely sure how we do that. >> But I mean you can always spec out some environments. Uh I it's probably possible but I don't know. Exactly. >> Yeah. Yeah. Um let's go on to the life cycle. Uh so I'm going to assume that most folks don't know how deposits work. Uh so one way to think of a firm is that there are actually two chains of stitched together

and there's a bridge between uh one chain to the other and a bridge to go back down. >> Is this going to also change some point? Uh I don't think there are any plans to make this change currently. >> Uh this is this is different than a unified uh client just >> okay uh yeah so one way to >> potentially uh um yeah so we have basically two chains and there's a bridge to go from one and a bridge to come down. So the bottom chain think of it as the execution layer. The top chain is the consensus layer and the way we go from one to the other is via uh this thing called a deposit contract. So you

deposit on the execution layer. The these funds essentially are burned and you now can register a validator on the consensus layer. Uh and to come down it's basically called an exit. So you exit your validator uh from the consensus layer and you get your funds back. Uh bit of an asterisk because validators do earn rewards. So there are funds that do come back down periodically but roughly speaking uh this is the way to think about sort of the execution layer and the consensus layer. Uh I'm currently proposing that we split deposits into two steps. Uh this might require more background than I think is [laughter] uh

maybe in this group but I'll just try to quickly explain the two-step idea. So it basically works like this. Instead of uh doing a deposit and registering at the same time, you basically do your deposit, you get a stake ID and uh the stake ID now lives on the CL and the EL. Now this is what you use to reference your validator for sort of the rest of the life cycle. So instead of a validator ID, you now just use a stake ID on both layers. Uh as I said, yeah, this might require more [laughter] uh uh more reading of the EIP, but uh roughly speaking, my plan is to uh change the way we do deposits and uh it seems to be a promise in direction.

Um can you give us the EIP uh number and also tell us maybe a bit about why we need to change? Mhm. Um, so I don't remember the EIP number. I think it still needs to be merged in, but it's called a decoupling registration from staking, I believe. Um, the reason why we need to change is because currently pre-quantum we've just assumed that the BLS public key is a stable identifier for uh validators. So we have like staking contracts that are using the BLS public key. Um but obviously postquantum this is not this this assumption just doesn't hold anymore which means that to switch from pre-quantum to postquantum

uh there's going to be a lot of changes that need to happen to staking contracts this might be a bit blasphemous but if you imagine a future where we have to switch to latises um [laughter] having the the BLS having the uh identifier being the root root or the XMSS uh tree would also mean that we need to do another sort of hard migration. So if we have this staking ID which is not linked to the BLS uh to the public key credentials, this makes it a lot easier to sort of switch to another scheme.

Um yeah. Um so >> ah okay. Uh so you say the problem is we we reference the val the validator via a public key and you if the signature scheme changes then you would have to change that again. But I guess let's assume we have one hash function where we agree this hash function should be secure forever.

Then couldn't you for I mean for any signature scheme you could just take the hash of the public key to be the actual public key and then the public key format for every signature scheme is the same forever, >> right? Yeah. So we could do that. I think they h Yeah. Yeah. So we could just use the hash of some public key from today as the identifier as well. Um that could definitely work as well. Yeah. >> And there is a EIP that was already merged uh 6 years ago. EIP233 free uh that added lamp port signatures based on the uh seed that we have and that was uh made so that we can uh make it easier to

switch to postquentum uh scheme >> right um I think that doesn't work because it requires everyone to follow the same uh like of I think everyone has to register it in whatever uh wallet they have and as far as I know it was broken but I don't have the specific details as to why it doesn't work. >> Do you know the the specific details? I I don't remember. >> Actually is I don't think it was really an EIP by the way, but was something official, but maybe more an ERC than EIP. I can't remember. But >> free free.

>> Yeah, but I mean, forget about it. [laughter] Is some mistake has been made. But basically like you could recover the discrete log. There's some association between I I can tell you offline. >> Okay. No, because it was derived by HKTF. So that's surprising to >> I will tell offline really. It's a it's a bit convoluted but yeah it's broken. >> Uh yeah, >> right. Uh so this is a good question.

Can the validator index be used instead? Because uh we have validator index. The main uh issue with using validator index is that you don't have it as soon as you stake. Uh so you don't have it on the EL. You need some process to get the validator index uh uh from the CL. With this mechanism, the contract that you use once you stake 32 E, let's say, you get a staking ID uh straight away. So you can think of it as close to the deposit index. Um, so this is why it's kind of nice because as soon as you stake, you have a staking ID that the CL can reference and the EL can reference.

Um yeah >> just for completeness, it's EIP 8413. >> Okay, EIP 8413. uh on the validator index. Uh in the past there were discussion to retire old validator index because they were taking space uh on uh consensus client uh memory. Uh is that still a thing? Uh currently there are plans to do it. Um but I don't think anyone has like seriously given an EIP to it. Uh the issue is that uh the validator records don't have the validator index in them.

So the placement where they are in an array basically determines like what the validator index is. So if you have an array that says like Bob, Kev, Alice, uh Bob has validator index zero because it's index zero in the array. Uh this means that you can't actually remove uh remove uh records from the array. One easy solution is just to say Bob comma 0 uh Alice comma one kev comma 2 and then you can start removing uh validators from the array. Um so this is like one solution to it but I don't think we have anyone that's proposed anything.

Um okay. Yeah. So I think one thing we can take from this slide that is not maybe intuitive is that with deposits you now need two signatures in order to exit so in order to enter the CL or register because we now have two uh public keys as I said at the beginning. If we have one then obviously it gets uh better and yeah >> can you explain again why you need two signatures because two public keys what does that mean?

>> Yeah. So if we have lean xmss and lean shinx uh when you register you need to supply a signature for both the public keys to show that you own it. >> Yeah I think that that's exactly my question. Do you still need to do that? Because for BLS, the reason why we do that is because the BLS aggregation is only secure if you add that proof of possession right? >> But now we are aggregating with STS. So you the for BLS you have these row key attacks if you don't do that. >> But for the signature aggregation uh >> with with with stocks with LINVM, you don't have these attacks. You can prove it is a secure aggregation scheme even if the malicious parties don't provide a signature. Right?

>> So I don't think we need these signatures. >> Right? So uh so the the situation that I'm thinking about is that let's say I see what your public key is and I say I'm going to register one E uh against your public key so that you can't use it because you can no longer use that public key if I register against it. >> Why? >> I mean if you register the same public key it doesn't mean that you can sign. So I could still use it. Uh but if uh when you register a public key, you also register the withdrawal credentials. So let's say that I register your public key and I say the withdrawal credentials go to Kev's address. If you try to register uh the same public key, but then say actually the withdrawal

credentials should be your address, how does the system >> I mean it would just take the first one. No, >> right. Exactly. So this is a front running attack that >> can only be solved if you show that you own the actual public key. you that's the only way to stop it. >> Okay, that makes sense. Yeah. >> Um so the transition is pretty simple in conceptually speaking. Uh so what happens is like today we sign duties with BLS. You basically register those PQ materials that I showed at the beginning. Then at a particular fork you stop uh you stop using BLS as in BLS is no longer possible to be used and you

just start using the PQ material. So conceptually speaking this is pretty simple. I think in practice it's kind of difficult. [laughter] Um at this fork everybody needs to basically stop using BLS which I think is going to potentially be a problem. So, what we might do is we say that the old uh deposit contracts uh might just refund you at the fork for maybe like 10 slots after cuz people are going to lose their funds. Uh no, no one's just going to stop using the deposit contract at the at the PQ fork. Tom, >> uh I think the question was how long is

it between the PQ fork and the BLS cutoff? Uh so first I'll explain why we have the BLS cutoff uh just before I say I answer that. Uh so essentially let's let's say that you sign at slot 100 before the PQ fork a particular block and then after the PQ fork you use your PQ credentials to sign to basically equivocate. So you sign a different block. Uh I need to be able to know that it was you who basically tried to equivocate by voting on two different uh blocks at the same slot. If I remove your BLS key um credentials, I can't like I don't know it's you. Uh so that's the reason it's there. How long after? I think we're still

uh debating. I I'm currently thinking that it should be just once you finalize, we can just remove like once the PQ slot is finalized, just remove everything else. Uh JD and Franchesco think that we should just do some sort of social slashing. So don't even keep the material and just socially say that anyone who does anything we I'm not I'm not completely sure of like how that solution works but some sort of social solution instead. >> I'm actually the the opposite take why we don't do like similar what we did for the beacon chain that we have like a period where like we had for for for a while we had like proof of work and then we had the beacon chain just there like to prove the technologies. So they were running in parallel for a while and of

course the proof of work was the one that the official one the other were yeah we're kind of losing a bit of it because we were still paying the people doing this fake proof of stake but maybe it will be a good transition time to have like both working and the one like BLS the official one and the PQ one that is there but not like means nothing basically for for for the chain. Uh I'm not sure how exactly that. So the PQ1 would have no waiting and anything.

So it's like an optional um we did this for the beacon chain, right? We had like for over a year Bon chain been there. We're like minting new new ETH but the official things was pro work. But actually in this transition period, we had a lot of time to validate the technology. Okay, I see what you're saying, right? Yeah, I mean, I think this is a good idea and I think you might have mentioned it yesterday as well. Uh, so just to restate the idea, uh, instead of cutting off at the PQ4 E, you have maybe some another line where the PQ fork has started, but it has no waiting on anything essentially. So, it's like testing out uh the PQ.

Um >> I mean the issue is the issue with that I guess is the time like increase of timeline that would likely impose right >> but it's well spent. >> I mean at least it was for the for the was well spent. >> So >> yeah but we didn't have this potential attack coming at that point. So >> but it's a a double-edged sword as in we have a lot of risk of bugs uh synchronization issues networking issues um and I would be very uncomfortable if uh the BLS cut off is below the week subjectivity periods uh for starters which is two weeks and um

I think it's important to have uh attack nets and then uh plus it it's something that has been used uh consensus client don't know how to do this. Uh there are many uh people at consensus team that were there for the beacon chain uh fork and it there risks uh a lot of the timeline uh that's quite um stretch like you can have this time uh of overlap to figure uh the last finishing touches. >> Okay. Yeah. I my understanding was from your proposal was that uh as soon as as long as we're not at the PQ fork, you can still modify it and do whatever you want like fix changes and it's not a hard fork or anything. Uh but I may be

misunderstanding. >> Yeah. >> Or was it that once we have peak readiness, we keep it like running as a secondary chain for like over a year and >> Oh, I see. Not not okay not over a year but like few months at least like again like we we keep it there. >> I see. >> We test how things goes and but if something happens you have it you can always push a button before but if nothing happens you run these two things in parallel. >> Okay. I see >> and validate that it actually works. I mean for for the beacon chain was useful. I mean we found a lot of stuff in the meantime between the beacon chain and the merge was really useful to have this this this time that we can actually validate the techn technology. It was a loss for the network because we were

actually minting new it and without having any meaning for the for the for the block but still >> and one of the reason is that uh there is a lot of synchronization uh risk on this kind of things and the current consensus team execution team and uh lan teams are different and so they kind of need time to learn how to talk together >> right um May maybe maybe this is contentious but I think that if you look at the timelines like we need this to go into the consensus layer from the beacon chain side not from the lean side. So I'd say to probably decrease risk because uh I guess the lean clients are

also working on more things than PQ it's probably better to start off with the beacon chain clients and then iterate iteratively add these features that I'm talking about. Um I guess uh to maybe a segue is what I think we should be doing in the next uh 12 months. So we need to upgrade all of the validator and builder contracts like all of the contracts are basically uh assuming BLS. Uh we need to retire the zer Xerox zero credentials which is a really old credential type uh that is basically very BLS specific. uh lean VM which is the most important part of all of this because it's used at every layer

uh needs to be ready. If anyone has questions as to when uh feel free uh to ask um I'm just going through the list pretty quickly. Uh we need to stabilize which signature scheme uh all the signature schemes we're using. If we're using lean xmss and lean sphinx um we basically need to have this done. So the sig.golf golf things need to be done as soon as possible so that we can figure out what are the signature sizes, how does this work on the network. We can start telling like uh uh staking teams like this is the signature scheme that's going to be uh being used.

They can maybe start looking at how they integrate these things. Uh formal verification is also pretty important because if we don't our current strategy for ensuring uh we don't have like a single bug a bug in an implementation is just to basically implement it multiple times. If we need to implement lean VM multiple times uh this is going to be pretty expensive. [laughter] Uh Emil is saying aokay but I I I don't believe him. Um so uh formal verification is in my opinion one of the most important parts here to reduce the redundancy or the amount of work that uh we need to do to ensure that uh the implementations are secure

networking we really need a plan for how networking will work with these larger objects it's on the CL but it's also on the E as well like lean shrinks on the E plus aggregation so actually the total node capacity is going to be going up quite significantly. Uh and then the last point is devets. I think we should start having devets as soon as possible, especially with the CL layer to just figure out how things work, especially how the transition works. Like this is the most sort of uh sensitive part of switching to PQ. Right at the transition, we need to make sure that everything works perfectly.

Mommy. >> Um, so give you some perspective on how the beacon chain transition went. Um, about in February, we we did this in December 2020 when we lighted up uh the beacon chain and in February uh we had attack nets and uh we had uh a bank bounty. I think um Antonio knows uh with leaderboards etc. This was super useful because uh formal verification is great uh for the state transition but a lot of bugs were like I remember Bezu they had a DOS vector because we were using ash table from Java with which we're using two to the^ 31 uh hashes uh and so collisions were really easy and it's all

those things that you take for granted from uh TypeScript from Java from uh even Rust uh that can uh crash uh especially on the networking side that cannot be formally verified, >> right? Yeah. So, I completely agree and I think we're not even at that stage yet. Uh I think we're sort of at >> there's not much useful >> right assumptions about >> for the networking. Right. Right. >> Right. Um, so I I agree with mommy said.

I think that we're not at this stage where we can actually test any of these things because you need sort of these primitives that I mentioned with lean XMSS and lean VM to be ready like properly before you can actually test these maybe DOSs vectors or things that happen in a node. I think you can uh fake uh the crypto part and always say yes and uh deal with networking uh fake objects that are uh kind of the size that we want just to uh figure out networking because uh historically uh Ephraim has been really good at cryptography and very bad at networking [laughter] and uh yeah it's important for the transition because uh of uh the

questions about uh bandwidth uh about uh if you have those um uh Simeon army or cow monkey style of Netflix where you have aggregator dying what happens we really need those answer uh not one month before the release but we need those uh 6 months so that we can have uh audits uh and uh lessons learned >> right yeah so I agree that for networking and figuring out the latency parts you can just like uh uh um like mock the cryptography I think we also need to know what the node resource requirements are with something like lean VM because it's definitely not non-trivial. Um so to me that's also a missing component and but but I

definitely agree like simulation testing uh which is what our current strategy is is uh like one way to do this. Okay. Uh so that was basically the next 12 months which is HAR for AR. Uh the lean sphinx on the E so the signal golf uh related work I think just needs to be finished very quickly uh in order for us to even think about putting it on AR. Uh we can potentially do PQDA in AR if lean VM is ready. Um decoupled consensus which is a hard requirement for PQ needs to be ready. Partition binary tree is a separate thing on the E, but I've put it

here just because it's going to take up a lot of our resources. So, it's mainly just trying to get an overall view as to what is going into AR. We can potentially also activate those new contracts, the the PQ related contracts. If we if we think that there's a benefit in having it be backwards compatible, we can activate it in advance and then have it sort of activate at the fork where PQ cuts over. If we think that it should only be for PQ, then we can't activate it early.

And then JAR is where I think we should do the the actual cut over. Uh I'll say that one feedback I've gotten is that this is pretty aggressive. So if that's in the back of your mind, it's okay. Uh [laughter] Tom, >> I think you said where is PQ privacy? Um this is the wrong session. I all day stuff. [laughter] >> Yeah. >> Um I think PQ privacy which is uh is important but I think there are a lot of open questions that I think we need to solve before even trying to put it on let's say the

main one is just the which ISO we plan to do. But this is also a possibility that we put PQ uh privacy and AR. So is actually getting packed already without even is similar to Linda. would say like meaning is >> okay >> could be done in in some sense >> right yeah if it's the ISA approach I think this is a lot more non-trivial >> I agree >> um yeah I think this is one of the reasons lean VM hasn't stabilized is because we want to use it for so many different components like privacy we want to use it for the DA layer the

protocol uh circuit so lean xmss so it has all of these requirements but if we just want it for pq there is in my opinion a straight road path to get there very quickly. Uh [laughter] uh so yeah, that's roughly my presentation. Um I went through a lot of things pretty quickly, so if you have questions, I'm happy to answer them. Uh questions on more timelines or Yeah, >> I'd be interested in the status quo because we you mentioned there are a couple of EIPs uh which have been written already. So there was the uh separating the um the deposits from the stake. So so the stake ID idea and then there's uh there

was the hash chain run. So there are multiple proposals basically out there already but maybe you can map out what has already been done in terms of uh grunt work for EIP specifically and what still needs to be done I guess in the short term. >> Right. Um so in the short term uh what we need to do is uh two EI or or one EIP for the signature scheme that we plan to use uh one EIP for the registry. So how do we register these things which is basically just hash chain randal but with extra material. Um the other one which we don't know just yet is EIP for uh networking that will make propagating

these objects uh easier. I I just don't know what they are right now. And >> sorry, >> they don't have to be part of >> right. Yeah, networking doesn't need to be a part of the hard fork. Uh and the last one is the aggregator sort of maybe potentially having an aggregator role or just what the aggregator is going to be doing. Um I think those are roughly the ones that we need to get over the line and will be quote unquote done. And how do you think about the um the bundling of those like what can be I mean you tried this with I guess what you just show showed on your last slide.

So was pretty packed uh also with other things but what what how do you currently think about the EIPS or the the mechanisms you just mentioned which can be bundled or which would make sense to be bundled and what would be the sequence of those bundles >> right? Um I think the first ones would be the deposit uh the contracts that we have. Um just because they're very easy. You can deploy a contract today and then like test it out that it works. Um so I think probably the contracts would be the first things that we get over the line like uh dep uh do the integration for the contract uh potentially just have a switch over where someone switches over from uh the old beacon deposit contract to the new one. Um so I

think that would be the first step. We can potentially have a mock signature scheme for that if we wanted to. Um, and a mock lean VM uh pure Linings question. So yesterday we said that we're going to take uh quite a lot of time for someone or a group of people to review uh the formal proof and to understand fully uh how it works and how do we know the resource allocation for this? Uh can we plan this now? So if we're saying that we cut the challenge in let's say 6 months who's going to be that person or these person that are going to uh to do this work uh can we

make sure that we lock them and that's their main priority. Um and second is so if we target AR that's like sometime 2028 >> and um are we okay with with this knowing that usually these forks get delays so it can end up being sometime 2029. um or can we have linfings as either HR or as an individual component that requires a special hard fork.

>> Right. Uh so I'll answer your first question. Um we don't have like a particular person that will take it over. It will likely be someone from the cryptography uh research team that looks into it. Um on your second question, I think we should probably just decouple ourselves from hard forks. I just wrote it down there because everyone's familiar with it. But I think we should be ready for PQ in roughly let's say 12 months. >> Um potentially even earlier. So >> even before like star >> I Okay, I love this idea. C could we like have a group and prepare like some sort of presentation to go to ACD and say this this should be the case and like in my opinion there is it's just a riskmanagement approach and we can

probably even come with risk management numbers and say okay this is how we should value you know uh the asset if you have 5% chance of the asset going to zero in 2029 like I can give you some numbers then it's not super good looking, >> right? I mean, yeah, I think we should do this, but they're they're then going to ask us, okay, where is where is the signature scheme? And >> and >> yeah, I I think >> we can commit we can make commitments to get scheme out.

I don't want to say anything on ACD's behalf, but I feel like they I they won't. >> Yeah. >> Which is why we should do it. >> So, this second part of the presentation, this workshop came up very impromptu and basically to your point, Alex, we've got this L1 uh research and development days in just a couple of weeks in Mumbai where we'll we'll have an audience in front of the core devs. uh we've got a whole morning talking about the PQ roadmap and we wanted to sort of use this opportunity to get all the questions answered and sort of anticipate uh what we might hear from the core dev so that we could try to put our best foot forward because when you look at this road map Nico to your point

um headliner scoping for AR is if past this prologue it's going to start in like February so what do we have to have from now until February to convince constantly get all core devs to be able to approve lean sphinx as the e headliner for and then you also have to work you know from there onwards uh you know what are all the dev nets that you need to have the audits the formal verification um everything that's required to you know the specking the testing to get us to um to actually have a shipped IR by say Q2 of 2028 >> do

Yeah. Do we want basically I think to stay on the hot fork schedule or maybe can we plan some fast lane whatever we call this just for lens so we are safer if there is some headline uh going out sometime in 2028 >> but but we are not I think we are not ready right like it's we can speed it up at some point but for example now it would be hard to push for something as like a fast track in on ACD without having something that's ready for them to even ship if you wanted them to. I feel like preparing and being like extremely ready for a star is like the

probably the best we can do sort of like making sure we we ship like we have our part sort of like figured out because it doesn't really feel like it's the case on all fronts right now. >> C could you be more specific in the unknowns uh that need to be figured out? things is not stable, right? Like it's uh there is still like this auto research competition, people are like iterating on it. >> Um so I mean all these different parts like the networking is absolutely not figured out. Um the aggregator role that Kev talked about like we don't even know if there is going to be one or if we want every meode to be an aggregator like or if we need to actually have incentives. So I feel like it's you know

um at at some point all these things need to be ready before we present them on ACD. Ideally we have like dev nets of these things that some core devs worked on um before we also present it on ACD. And so I don't know I feel like you know saying we want to accelerate the timeline without having like concrete things that are like completely stable and tested on devet and everything is a bit um counterproductive. like we have a grants budget. We have the ability to engage external you know service providers and you know to help us accelerate on those things parallel process those things I guess is there anything that like is literally an

unknown unknown or known unknown that is preventing say the I don't know around the the sig.golf golf the the actual cryptographic primitives from being uh finalized so that we can start to move some of those other things forward or not. I honestly think that we can have 100% of the cryptography production ready in two to three months and the like the difficult it may not be the optimal cryptograph like maybe on sphinx it will not be the optimal the optimal like up to 5% but I would say it's not that hard and I would say the difficulty that remains is in

the details protocols incentives networking but overall like Sphinx is kind of solved. >> So I think our our checklist for our checklist for going into let's say uh the end of January of 2027 where we would expect the headliner window to open is we have to have an EIP like all the EIPs that are required a proof of concept and a champion that's going to be like willing to marry themselves to this thing and take it from that point over the finish line. Um do we do we have those things or what do we need to do to have those things?

>> Right? Just adding like a couple of things about like the the fast track, right? I mean let's assume that really we have a quantum computer. I mean and we had a fast track and we solved the but we still have all the CL that is not there. I mean we'll be really doing a big difference to have like E ready and not the seal ready. Honestly, like if something really bad happens like having a quantum computer that breaks the cryptography, even if you solve the L, the CL is still like um what I heard is that there is a lot of um synchronization uh risk or concerns with the ACD. So uh what happened with the beacon chain is that >> what happened with the be

what happened with the beacon chain is that uh for uh a year and a half we had two chain and they had different um release uh schedules uh different hard fork that's why we have the name like glamsterdam with uh two uh hard fork at the same time and you could do that for the postquantum chain if we uh do this uh decoupled uh with a parallel releases where the postquantum has accelerated timeline with maybe hard forks every two months, three months and then the ACD can look at this and say oh this is kind of derisked. uh they have their test net, attack net, they are uh they have the processes in place to make good

quality releases and then you come back into the nests of the ACD uh for the production uh AAR uh timelines for example. Okay. Uh so the reasoning behind having the E uh ready first is because the migration is going to be user funds is going to be Dows it's going to be more um action from different stakeholders whereas like on the CL if we have the registry validators can start to to register their keys and then um putting the like triggering the emergency button is more

of a you know one-way thing where validators think pretty fast whereas on the Yale the transition is going to be migration of individual accounts migration of Dows and this is going to be months of uh voting like if you take the biggest target uh actually on Ethereum is the governance of like the big lending platform like if I were to attack something I would attack you know like some of these big governance I would upgrade the contract and and withdraw the funds. Um, so there is yeah there is a a reasoning behind like just putting the EL first and having an emergency plan situation on the CL that allows us to go very fast if something happens. So I think what Kev did with the pushing the registry forward is

exactly going in this direction. >> I agree but I think like HAR is still okay for I mean >> for for E. Okay. So you say LINS in AR >> but to me it's like look on this optimistic view that we have it's like a Q2 2020 8 maybe it's going to end up 29 with >> it's not going to end up >> okay let's say optimistic like with the recent papers and what we've had in the last few weeks do you feel comfortable like putting your entire networks on on this date no Q day no headline that is going to crush just me I'm not super comfortable with it. I would say it's

maybe 5 10% chance and I don't want to gamble 5% or 10% chance on my network. >> Well, there's also the the risk of AI breaking existent C++ I guess. So that's another thing I think what you mentioned about the migration process is very true. I think that will be quite a massive effort and I think with regards to the let's say two mount cadence on hard forks and such I think we're in a bit of a different world now compared to the merge. Um now there's about 15 different clients um in different stages of development um on the CL and E

together. So getting all of those to interrupt and such I think it's more complex and this is probably another discussion we need to have on how should we deal with that long term. Should we just keep adding support to test nets and devets and whatnot for you know all the different clients that comes with all the diff with all the increase in um time that means when it comes to getting new hard forks and so forth out. Um but yeah I definitely agree that the migration aspect is going to be quite quite a lot of work.

Do do we really need to freeze a spec because I guess like we could also have just like a pipeline where we have try to aim to always have a working version so we can deploy it and like if we don't need to deploy it and we see okay maybe we have a quarter more like we iterate to LIN fix lin things like 1.1 or something and we we keep like moving the pipeline forward until we want to deploy. As long as at every point we have something ready to deploy, it should be fine, I guess.

>> Um, so it really depends on the diff between your one uh your 1.0 and your 1.01. What we said today is that we really want someone to have a someone or some people to have a deep look at the proofs and to understand fully the scheme and everything. So if these people are locked in for three months and you keep iterating then you know it's not Yeah. >> So just like adding I'm a big fan of the SE golf initiative and hopefully we'll bring something spectacular but if things stays like are right now that are with the performance I mean unless it's going to be a really spectacular breakthrough on a new signature scheme I will stay with the current number of cig I will stay conservative. For example,

there's like a version of of a meal of of normal lin or normal things that's not so fancy and that's sometime they're not so bad compared to the current version of se golf, right? >> Because doesn't have doesn't have Yeah. >> Yeah. It's it's because S.Golf the the missing feature is hypatri printing because so it's not perfect but honestly from my point of view uh users do not care if it takes 10% less verification hashes or 50% more byes in the signature as long as you have something which is

not 10x far away from of the optimal that that's personal opinion but what what what we care is to have something that we agree on as soon as possible that is makes everyone life happy NPC ledger whatever and then we ship it and it's good it works >> yeah I think I agree >> I think like we have to fight the urge to try to make the thing perfect which is like something we sometimes do uh and we iterate and there is like a new development and we're like oh but what if we can get this sort of like 3% more and like and then you redo the whole design and that's been done across the board right like for for crypto but also for consensus for networking for for a ton of things and when you do have like emergency situations, you just need to

settle something and push it and you know it's not going to be perfect, but like as long as there is a you know a decent upgrade path where it doesn't actually break contracts for everyone or like is catastrophic, you just settle, stabilize it and just ship it. Yeah. >> Don't let perfect be the enemy of good enough. Uh Emil so if you said earlier that there's like two to three months to finalize this could you speak about >> who who's doing this work and what is the work I >> mean need to agree on some hash function let's say black toss they need to agree on a sphinx honestly in like we can even be very very simple and take the the one

from the new candidate of of N ch you change h a and k and it it kind of works and then you need to agree on the Linux MSS the lin VM but everything like is like it already works we just need to fix to say this is good enough and then we we make it production ready and that's it like >> I just think a point like I mean I think everyone is aware in this room that we already have a kind of test net the version of sphinx is not there is no perfect we have already aggregation thanks to a mill that adapted the the linv to this not perfect version of those things. So in my opinion we are we're having a lot of pieces there. We can just iterate and getting better and better. The test net is there. Of course

we need traffic. We need to try the like having more people giving effort in this test net but we we are kind of working on on this spirit of not going to something perfect but to adapt and and improve on the status quo all the time. I think the me aggregation part and networking is something we don't have at all and non-trivial and not figured out and I think that's one of the things we need to sort of like speed up and but I agree on the iterative approach it's just like this part is like not there yet at all we got aggregation three days ago >> yeah yeah yeah for sure >> I I think this is not mentioned in the

on on the table there But when do we want like to have an agreement on LINV VM or if we want a VM or not or the design of LINVM? Because I think that this impacts a lot of stuff that are on the ball like for example the EIP I2 A28. This has LINVM has a big impact on it uh for the linfings aggregation as well and for the PQ devet as well. And we are still iterating like over lean VM with the lean ISA originally and then with a risk five ISA. So when do we want to to close this and and finalize the design and just make it work with a test

formal verification and things. >> Do you have a question? >> Yeah. >> So am I correct? I misunderstood. So the idea is to not go for the fancy stuff from sig golf and just use let's say multiig things like scheme and deploy it or I I didn't fully understand. I mean I don't know but in my opinion what we must ensure is that we don't miss a breakthrough design that would give us a 2x but >> so unless it is 2x the optimization will

be >> I don't know but like um >> but this is I think the this this distinction between uh 3 months deployment ready and uh completely different timeline. Yeah, >> if we say 15% increase is sufficient to change our mind, that's one thing. This is I can expect 2x maybe something breakthrough is there but probably no. But uh maybe the progress we can do here is say okay if we don't have a let's say 50% uh improvement by end of December

we just go with uh the NIST version for certificate which is the one uh Em is talking about with pruning and and that's it. And if later on we find a crazy 10x, we actually we discussed this yesterday. If uh two years from now we find a a 10x improvement, then why not just push it to five years from now? Because if any from the new schemes from CI Golf is considered to be in production I think okay I don't know but I cannot see two three months deployment ready is I think it's almost no way >> curious to get

>> so this is what was also in discussion. So we have this shrinks proposal where we have a stateful part which is a little bit more fancy with flexible xms and what's plus c leaves and the stateless path was um slhdsa like with just tweaked parameters. uh but uh I think there was quite some feedback on we don't want to use stateful at all in on our hardware device or in our software wherever and please try to make the stateless part much more suitable to use and then uh to make it more suitable to use you either decrease the allowed number of signatures or you

go with fancy stuff And um I don't know where will be the solution because this is also again the question on uh when we will ship because essentially the current proposal is close to be ready to submit it for a beep and then there will be a discussion complaints maybe some changes. If we go fancy then there needs a new proof to be done new spec new discussions and stuff like this.

I think what is also maybe a possible path is actually doing two proposals. You start uh proposal with the current shrinkings SLHDSA compatible look at their analysis work on a new proposal run it in parallel and maybe it's very complicated. I don't know if it is a good idea or it is a bad idea. I don't know.

>> But but the problem is like over there there is not even a consensus on the fact that this has to be done. So the timeline is so completely different that like there's still a big portion of of the community on Bitcoin that is just not even on board yet. But also like if you take a minimum improvement like let's say okay 50% onwards we work on the new scheme. It's fancy but it's too big of a saving not to do it. The problem is that for example on C golf now there's c certain things that are part of the improvement that maybe you want to do and then there's others that maybe are also part of the improvement but you don't want to do so. So it's not like you take the all the improvements

that together give you 50%. It has to be like different. Um, but I think the most important thing of of what you said before is like why would you just try to find the best thing now forever like you can find a very good viable solution that at the moment is even sphinx plus just a good parameter set of spin plus a different hash function and you can do everything. um those with constrained hardware as we discussed yesterday can go the other direction that is already potentially there and there's probably others. Um and then if in 5 years 10 years you really have the groundbreaking

completely different improvement then you go for it but you have all the time in the world to release it just as a operational optimization. I had the same argument but I think it also from the other point of view on this is uh the things we do with post quantum they are in most cases worse than we had with classical uh cryptography. And so essentially whatever solution is deployable it usually hurts you in why one way or another. And so not doing something better will hurt you more. So for example again with um bitcoin if I put uh 3 kilobyte signature on chain or

4 kilobyte signature on chain it's not 2x but uh it will [clears throat] it may result in significantly higher fees lower throughput and then the question is like okay we we went for 4 kilobyte because it was like okay it was ready and and stuff and then for 10 years everyone will pay the price of not going for something better. Maybe it's just there is no good I think good strictly good answer what to do.

You need to move faster but you also don't want to miss something. It is this kind of two sides of a matter >> white is arbitrary number. [laughter] I think a good piece of information for decision- making would be to know for example if for Bitcoin the version that we're talking about the certificate version is 100% no if um if Bitcoin joining the research and like accepting or potentially accepting uh the new scheme I think it does justify like spending like three four more

months of exotic research to do improvement that are going to enable the ecosystem to move on the same scheme. If we could know right now like no it's never going to go with the certificates then maybe that would be an additional incentive to go for the exotic stuff. Uh and the opposite if like we could know if Bitcoin was okay with this pruning of the certificate one that would also be a good piece of information to just say okay then maybe let's stop there and you later >> 3 months like it it's like uh it's not even enough to just >> you know for most of them to to think of it like it's uh it's impossible but also

over there in Bitcoin as he said 10 years I think it's more like the the by the time you manage to do a fork in Bitcoin there is not like a plan to then do another one then another one and and another one improve things this this style it's a completely locked in thing so I don't think it makes sense to wait for that type of consensus I just actually it would be ideal I agree on that but it's not I don't think it's coming whatsoever like it's a in my opinion it's a 0% chance and also like on timing the signature scheme if 0% that in a one-year time there's

there's agreement like there is a strong signaling from people starting signaling alataproot it's like 0.1 okay 0.1 um and also if you do the process once like recently for the policy things and it's a no then instead of being um not in one year, it's going to be not in three years. So, it's even worse. But like you don't know when the threat is coming. So, it's impossible to quantify how much of an improvement you should desire today. Like if if the thing is oh maybe within two years we are Then good enough is not only good is is perfect. It's great because you get the

network into shape. You are a first mover. You have it. It's fine. and then fine 10 years down the line, I hope there is going to be a groundbreaking something and then maybe AI is cooling down in terms of the acceleration on cryptography and so you can afford to be a bit more adventurous with the with the changes on the scheme. >> I agree with Yeah. Um yeah then maybe we can converge uh towards something faster but yeah it's still worth I think running the initiative for one two months then we

see and and and we decide uh to to me from the beginning I wanted to do the basically sphinx minus pruning is exactly what Emil is saying. So I I have actually technical question and actually will pointed out there like here we have a clear set of EIP. So we have APA 288 but I mean technically how does it look like a new AAP for having the clients embedding the LINVM and we actually there's a gap in this list right we we actually need a new document that that tells okay clients needs to embed the the LIN VM for aggregating and verification this is not in that list like like will pointed out so we actually need the we need what is

missing there so only one EIP How do you what do you guys think? >> Uh I mean there's not an EIP for embedding libraries. It's more of there's an Yeah, we just don't have EIPs for that. So maybe an EIP for um shipping maybe the PQ registry and in that process they'll embed the library potentially. But >> uh I I will keep separate EL and CL right because I mean that okay the regist I know yeah but I'm say like the regist as well has a component >> but I am I'm kind of sure that some EIP that tells okay clients you ship an LVM and some other things must is needed I

mean it will not go in APA 288 for sure it will not go in in this registry uh >> right Yeah, I agree. Um, you're basically saying that there's no EIP where the clients can say once I implement this EIP, I will need to take lean VM as a dependency >> and and and like and the IP to sell to the to the core dev saying, okay, this is the AP for the sche the signal new signal scheme. Here's like more a plan than a single things you can point to, >> right? um potentially the aggregate >> I think the original SEC 256 whatever you guys wasn't that EIP2 >> where you that would set the original

elliptic curve cryptography signature scheme >> I I can't remember >> yeah yeah it's really low I can remember which number exactly what yeah >> just on this point um we have been doing some work on execution proofs um in which we've been integrating verifier libraries into CLS for the purpose of you E um block execution verification. So that um you know same kind of deployment pipeline um could potentially uh kind of frontload some of the effort here um in regards to kind of shipping the VM into the clients. If we can kind of standardize that um you know harden the pipelines and uh you know get the

ecosystem kind of um aligned then potentially down the road it could be more efficient. Right. Right. My discussion was as well as bit political because for example the in Hegota people were wanted almost to ship a deleting one because there was the only things that that connect them to okay we have a postquantum signature scheme and here like even in this list we don't have a a single EIP we can point hey this is going to be the new official signature scheme is postquantum so I think for core dev we kind of need to have one of this >> are you talking about the EL or the CL or yeah >> oh for the eel >> right >> but that's 8288 right >> 8288 is that's why I don't think it is

828 is more I mean at the moment at the moment is contains the aggregation and the the the privacy that contains way too much stuff so we in my opinion we need one other EIP that the core dev can easily connect to say okay this is going to be the new postquantum single signal to scheme H >> scoping is >> no I star I star mix call it I star I star >> but I mean for HR the there was the delithium thing right and the the core were almost including this into HR because for them say okay this is actually the only things I see here is a postquantum signatures and from this

list is one one things like that is missing to date is way too big contains way too much stuff in my opinion >> I I think the everyone agrees that 8288 is too big and I think one idea would be to break it down as a metaip into sub EIP because it is sort of like nice I think as a bundle in a sense because it like it is you know what ships sort of like PQ for for [snorts] transactions um that are public and private but but we need to break it down and we need to have like several components and and you know what you're talking about could be one identified component And that is part of it, >> right?

>> Um, yeah, I guess for me it's what I'm trying to figure out is what are the actual hard dependencies for shipping a lean spinx signature scheme that we are happy with like not the optimal thing just something we are happy with. If we've chosen that now and we have a scheme, I think we should say this is the baseline that we're going to move forward with. If the auto research stuff comes up with something better, then the onus is on the auto research to justify maybe a 10% or 20%. But for now, this is like the checkpoint >> even when it's accepted. Like I agree with that strategy because even you know if people go with an EIP and they accept it and they decide to sort of like in

add to a fork like you know if you have like like a really good improvement later on and it's proven that it works and everything like people do modify APs right like in Glamsterdam like literally until like the last the very last minute like IPs are are modified and sort of like changed and so I feel like that's fine. >> Can I can I ask something? So we we've been focusing on lin sphinx but the row below the 8 to88 also brings linvm as a dependency like are we also implicitly discussing linvm by discussing linfings in like do we want to freeze linvm as well because we haven't discussed it at all today and

>> I think both are independent like we can [clears throat] yeah like uh we could just have linings and not have 8288 >> okay I see. So there are two paths in the >> kind of dependent part. >> Exactly. >> Exactly. Yeah. That's what I mean like freezing linh is one thing. Freezing lin VM is a even bigger thing and we have sort of been ignoring it. I think yeah I think they are independent just because they need the same networking sort of like aggregation thing like sorry dependent but you know we could definitely ship linfings and the mele aggregation part first

>> if we haven't figured out the sort of like linm part >> yeah the linv is a bigger discussion >> basically >> so aggregation and uh linfings are definitely dependent but the linv side of The tree is is independent. >> Okay. Yeah, we're done. [applause]