All Core Devs - Execution #193

Transcript

[Music] J h

[Applause]

Tim Beiko: and we are live uh welcome everyone to

acde number 193 uh a bunch of things to talk about today uh lots of updates on the betra front so uh we went from devet 1 to De 2 this week uh we can discuss that and the issues we we encountered then there was the AA 772 breakout yesterday uh we can chat about that um and then there's two um engine API related uh topics one around the encoding and one around a new uh end point uh for get blobs V1 um so yeah let's get through all of that uh then uh last call we had the

7212 discussion where um we couldn't quite get to like a final decision about what we wanted to include it in pectra um and so let's yeah try to wrap this up today and then if we have time there's a couple more topics uh that are a bit less pressing but uh less urgent but um we're going over so uh uh Andrew had something around Quantum resistance and the implications uh potentially on the veral road map uh there's a new uh State expiry proposal and then um yeah if anyone has updates on 44s uh we can cover those two um but yes to kick us off uh Perry do you want to walk through uh what happened with devet one uh what

devet 2 is and kind of over at around that

Parithosh Jayanthi: yeah so with devet one we had the launch last week and we did have a few 7702 tests that were run um we're sort of working with a bunch of people um who are working on 772 to help us get our testing stack up and that seems to have broke the clients in in ways that we were called the forking um because of the forking it was quite hard to actually figure out which bugs were treated well on devet one um so we decided it was a bit easier to keep 7702 out of the picture for now and relaunch the devet uh and focus on testing the

other eips so we had the relaunch on Tuesday and since then we've had like a few bugs that have been already caught and fixed and a few more op so there's a bunch of open threads on the interrupt Channel um in case someone's interested uh on a high level there was an Aragon block production issue that's since been fixed um there's still an open prism issue and an open w issue and both the teams are looking into it uh for grandine so the network was non-f finalizing for a while and during that time grandine seemed to have issues but now it's fine um so I I still need to look into if that was during non-f finality or if there was some other

reasoning for it um but yeah those are most of the uh open topics so we back up to relatively healthy percentage uh but the idea is to first get all of these bugs sorted out so that we have like a clean Baseline and then we can start um testing whatever we want on

on Petra

Tim Beiko: awesome thanks um any of the client teams want to chime in with more details on their M okay um if not then I guess one thing uh that's is it worth trying to Spec devet 3 today or do we want to wait

another two weeks for that uh do we want to try and Run devet 2 uh basically as is um I know there's been some changes on the 772 side so we uh we can discuss those right after um but then I guess more broadly you know would would we feel ready and bringing say something like eof in the next St or do we still need a couple weeks to um yeah to to be ready for that

Danno Ferrin: I think for Eos a lot of us are focused on the fuzz testing part of it um we got fuzzers working on the various clients

fuzzing differentially other clients so um we would I would want to see successful Heros was asserted before I would propose putting in the devet so holding off two weeks we could be there it might work but I feel better seeing R kosis first

Tim Beiko: okay so then um yeah let's we can reopen this uh thread in two weeks and worst case if we launch a devet uh before then you know we can launch a new one in two weeks with with eof um Mario

Mario Vega: yeah so I'm still worried about the interactions between eof and the rest of eips because we are still in the process of writing these tests y um so yeah I would I would like I I mean um

generally EF and 7702 I think that's my main worry so we're still writing those tests and I think they are not ready

Tim Beiko: okay so let's table eof for another two weeks we can discuss it on the next call uh what we want to bring it in or not and I think this is kind of a good transition to talk about 7 702 some more um so there was a breakout yesterday um Nico let it I don't know if Nico's on the call um but otherwise uh anyone want to give it a recap about the yeah the conversation there if not maybe I can try and summarize it but my biggest takeaway from listening it to it uh afterwards was um that uh

We've seems like we've reached consensus on not having 7702 be uh like migration like a full migration to um to Smart accounts um and I know a lot of the you know potential design changes had to do with with Ena that um so yeah I think keeping the scope of 7702 um to like a temporary um like giving temporary extra extra functionality to the account since we would uh yeah we've landed on um I'm not sure though in terms of specific specs PRS uh what that would mean is this the currently merged 7 702

spec or whether there's a an extra PR we'd want to merge and and see uh see as part of uh the EIP have one plus one from Julian is this we keep the EIP as is

Ahmad Bitar: um from what I remember from attending yes we decided to keep it as is for now uh there are some minor discussions that we want to have maybe a little bit later at the point that eof has made a decision on what they're

going to do with code introspection features because there was discussions around if we should allow code introspection to the delegated account uh yeah to the delegated account like what happens when you do exit code uh hash exit code size and exit code copy of a delegated account uh currently as spec it just delegates those calls to the delegated account so it Returns the hash and the size of the delegated account um as far as I know um not sure if uh that changed but yeah as far as I know that that's how it spec right now so there was some discussions around changing that behavior or not uh

yeah waiting on this decision on the EF side

Danno Ferrin: um I wasn't aware that was something that was blocking e to decide um but my offthe cut thought is whatever the ultimate resolve bite code is um that's where we apply the EF z00 Rule and make the decision about the EXT code introspection

Tim Beiko: so that if it's dedicated to an eof smart account then it cannot introspect but if it's delegated to a non eoff contract then it can introspect is that correct

Danno Ferrin: exactly if it sees an e account it's still going to think it's nothing more than

e

Ahmad Bitar: yeah there there is there was discussions last on on the chat

yesterday that we want to potentially only restrict delegation to e accounts um yeah uh but we still want uh like to go through more Dev Nets on pkra probably with eof to see if this is actually what we're going to do with 7702 uh just in case

Danno Ferrin: by restrict deleg you mean not allow e accounts to be delegated to

Ahmad Bitar: no only allow e accounts to be delegated to uh oh contract sorry

that's

Danno Ferrin: that's an interesting idea okay

okay

Ahmad Bitar: yeah but all of all of these

are like not anything immediate uh all of them as far as I know or as far as I understood from yesterday meeting is something to look into at a later stage

Tim Beiko: okay so I think it makes sense to then move forward with uh 7702 um in like the next devet um and then uh yeah keeping the eof stuff in mind basically and then when we um when we've actually um like when we've actually shipped the death net what not we can make a decision about potentially tweaking the spec with regards to eof and and maybe do that after we bring eof

in um one question I do have though so looking at the devet two specs it links uh the devet two specs I'll put them in the chat right here so the devet two specs link a relatively old commit of 7702 which is like two months old whereas uh like client merged something uh like 19 hours ago um so just to make sure we're all on the same page like should should what we have in devet 2 um I know devet 2 is already live so does it make sense to talk about defet 3 actually but like is the thing that we want is is the thing that we want this list PR that light Cent just merged for 7702 or do we want the thing from two

months ago

Ahmad Bitar: um so for devet 2 we decided two things we decided to keep the exact spec of devet one because it's just basically a basic relaunch of devet one and second is to not proc any 7702 transactions because the spec is going to change so we felt like there's no need to test an old spec

Tim Beiko: yeah and so okay so devet 3 we have the latest 7702 spec and just to make sure we're all on the same page here it's the spec would be uh including the pr that was merged 19 hours ago um that I just posted in the chat and no other or I I don't know minimal other changes uh to

devet 2 like we're not including eof or anything like that

Parithosh Jayanthi: yeah exactly so we wouldn't include eof but we would just bump up whatever spec releases are there besides that

okay

Tim Beiko: okay I think this makes sense um so yeah so I posted the pr in the commit in the chat here so we can uh bump devet 3 to use that for 7702 and then uh see if there's other tiny tweaks but no other major additions um anything else on that okay and then one other thing uh

that was proposed that might affect DEET 3 so Felix uh Felix from the get team said that we should discuss encoding the EIP 611 6110 request objects in the engine API using ssz rather than rlp I don't know if Felix

no no no no

Felix Lange: no so basically at the moment um so this came up a couple times during the code review of the 6110 implementation G so we kind of noticed that basically there's a lot of code now in G to specifically serialize the uh requests in and more specifically there's only the deposit request right now and the deposits we have to

serialize them to the Json but we also have to basically be able to decode them from Json and it's kind of the same issue we have in other RPC apis where we get adjacent object and then depending on the fields in that object we have to figure out like what type of object is this because there can be more than one type of request and we kind of thought that it's a bit silly that to have all this complexity on the API layer when these objects ultimately have to be handled as SSD by the s layer so we thought that maybe it will be would be wise to just handle them as s like all the way so basically make the execution layer in charge of encoding them as SSC

and then we would just relay them over the engine API as Opa hex encoded blobs just like we do transactions now so when it comes to transactions over the engine API we actually don't and call them as Json but we just pass them as a hex um blob and we would we were suggesting to do the same for these new request objects the downside to this proposal is just that the execution layer will now have to perform the SSD coding which they haven't really had to do before however we will have to start using S at some point so we feel like this is um very minimal entry into the world of S

for the Els because in the absolute worst case where no suitable libraries available you could always because these objects are purely fixed size they could just be decoded like by hand basically like it doesn't require like if there's no Library available that you can trust then you could probably just wing it and implement it like in a different way and it wouldn't be too much code either I guess would be about the same as just using Json so that's why I think I we were making this proposal and this was specifically me and Peter shilag who's not here today we're thinking like you know why don't we just start with this because we got to add the S at some point

anyways and we just wanted to hear like what do other people think about it or is it a bad idea

or thank you uh yeah Mikel

Mikhail Kalinin: yeah one potential issue is not only the um SS support onel but also uh ssz Union support uh by all ssz Library is I'm not sure it's um the union is not used anywhere else at this moment so that might be an issue as well we need Union because for different requests we have this type fi fied and we need to De go them differently they have different

ums

Felix Lange: yeah I understand this but at same

time I think it is a pretty again this the the we are we we we also talk about this this Union problem however in the end this is such a simple these types are so simple that it makes sense to start with this I mean we were discussing adding like uh encoding transactions at s at some point and we've also been discussing just generally converting the whole engine API over to SC at some point but for now just as sort of minimal starting point we could just like try to get this in and then just see how it feels prep like the libraries and stuff to make it work and then yeah I don't know I just wanted to hear it from maybe the clients as well anyone has a has an opinion about

it

Tim Beiko: um this is maybe a dumb question but I assume given that 6110 is on the dev Nets everyone's already implemented it with Json right like there's no team who hasn't done it with Json correct

Felix Lange: no Implement it's already implemented it's more like also a cleanliness question I mean on both sides of the of the API we have to deal with these objects in Json which are not really right I mean they are just internal consensus internal objects

Tim Beiko: so I guess my proposal if no one feels like strongly about it is um I would maybe keep it as Json for now at least

like for the next couple Dev Nets because we still have like some pretty big things we have not tested yet um and then I don't know it feels like something we can also choose to add basically like later on if if uh if we want to do it but um yeah given we're still working on 7702 we're still working on eof my sense is teams bandwidth is probably limited to like take on another piece of work and um and if if if we if we can effectively just add it later on um yeah I I know I personally feel more comfortable seeing the rest of Petra like a bit

Felix Lange: I mean like I said if it's not I just wanted to hear I mean we can

totally live with it being Jason for now for the future we definitely have this plan to work on converting the whole engine API to SS so sooner or later and at that point we probably also we will redesign maybe some of the functions to have a slightly different structure or something and then so I guess maybe we will get another chance then to like really clean this up I just we just felt like would it would make our life simpler anyways but it's fine

s

Tim Beiko: um anyone else have thoughts or on this okay uh yeah and then there's a

good comment by bzu uh that they just haven't had time to evaluate it so we could decide this in the future all

cev

Felix Lange: so pretty quick yeah yeah I just thought

Tim Beiko: um yeah so okay so let's yeah let's review it I thinkc and then you know we can decide this if on the next call or the call after that like it doesn't seem super urgent but if if it's something that um um yeah we we want to do we can uh yeah we can do it later in the in the for process um okay anything else on ssz okay um then next up uh there was a proposal by Michael on the light house

team for get blobs V1 uh I believe he's not on the call unfortunately um um so I don't know if anyone else has the context around this or is able to talk about it I see I guess Mikel you approved it about a month ago so I don't know if there was anything else we were waking waiting on or any feedback we wanted specifically by uh before merging this

Mikhail Kalinin: um yeah the change looks good in terms of the back and it's just you know adoption and consensus of core devs is needed for to move forward I think it's

pretty uh good optimization we have discussed some kevat some potential issues with Michael sprl about using this optimization in the sense when yeah when it can um hinder you know BL BL propagation so um yeah but I think it's why optimization use carefully should should be quite helpful

uh enrio

Enrico Del Fante: yeah I just want to say that uh we like we like that and we we probably use optimization um because we tend to try

to get from peers uh pretty pretty pretty soon uh blobs that we we missed or we are we are receiving late so it could be very nice if we can try first on our local y to get those before trying to get it from from the peers and will be nice thing for us but I also think that this should not be abused from the CL side I think I was thinking lately because if if C pretends to get it a lot of those blobs from from the L and I see

like the we should not do something like that affects the dissemination on on the P2P uh like a super optimized way of trying to get it and and and response I I I don't uh I don't want to all the messages that I receive because you are not actively participating on the top anymore if you abuse that channel

Tim Beiko: thanks is there a way we can like add a a limit or like I guess not really right

Enrico Del Fante: um I think like we should uh be add some more clean way of clean usage uh context

let's say the the Hest validator should use this in such cases but not maybe in others

I see uh po this

Potuz: so what is the problem the problem is that you're not going to be gossiping those blocks but can you just get it from the L if you have it you consider the da already satisfied and you gossip them anyways on the P2P side

Enrico Del Fante: image that you you receive a block uh first and the blocks come come after so you you know in advance a way to look up your local El for all the blobs and then you construct and I don't want message over the P2P because you

say I already have those so don't even send to me and it means that you're not even disseminating anything so you're not participating in the dissemination of the blobs

Potuz: but can you just send the I have messages and just gossip them anyways because you have them

Enrico Del Fante: yeah I mean you if you do that it's it's okay but it's it should be in the honest behavior of the validator you say if I get it from the l i disseminate and then give give the send the I I don't want if you ascend only the I don't want I'm I'm cheating essentially

Tim Beiko: I think yeah that seems reasonable I guess the the weird thing

is it would be we need to open a PR in the CL specs that effectively mentions that correct

Potuz: yeah it can be done on the onest validator guide or on the P2P Network perhaps

got it Miguel

Mikhail Kalinin: I just wanted to add that disregarding yeah we need c to use it first so it it makes sense to implement this um method but El DS should implement this so where is also check temperature on on this whether it's easy or not and how much of the efforts it

requires to get implemented on the L side probably not that much

any yeah

Tim Beiko: anyone on the El side have thoughts on this okay I guess if there's not a ton of feedback now what I would maybe do is uh I don't know enrio if you'd be able to open a PR against the the specs like the honest validator specs to kind of uh describe the the gossiping Behavior if we can have that PR open by like early next week um we can bring it up on the call on the SE call next week and then um if people are happy with that PR then

we can merge both the both the spec PR and the engine API one and if there's any objections on the El side with regards to complexity we can also um yeah have last week be like the the final final place to have next week be the last place to race them

Enrico Del Fante: yeah I can open the the the PR but I will be off from from next week so maybe it will be Carry On from by someone else

Tim Beiko: okay great yeah if you if you have a time to do it before you leave that'd be that'd be valuable and so yeah let's um yeah let's try and get this result in the next week or so and then um yeah worst case make a final decision uh on this y call anything else on

this okay uh yeah thanks a lot everyone for the context um so that's everything we had around pectra anything else people wanted to discuss about the current Dev Nets current Forks um okay and then I guess one thing we can also decide next week is uh assuming we did merge this engine API change do we want this to be part of definit 3 um but yeah uh for now we'll keep definite 3 as defet 2 and the change on 7702 um sweet I guess yeah moving on next thing on the agenda so seven I always

forget the number s 7212 the um R1 precompile we discussed it a few times already uh there's some desire I think by some of the teams to bring it in to L1 um on you know in large part because it's already implemented on l2s um at the same time Petra is already huge in scope we you know don't have it implemented uh there is some like concerns around uh the complexity of different eips uh being tested together um so I guess yeah the people think we should be including this um is now the right time to make a final

call on this uh the people want to see how Petra goes and then you know potentially push this back a bit more um I know we've pushed it back over and over again but we're also in a spot where we um we um don't have all of pectra implemented and so we're not necessarily um yeah we're not necessarily like waiting to implement stuff um so yeah I guess ongar as in favor there's another mind in favor

um client

Lightclient: yeah I kind of would like to see how Petra plays out over the next couple months I feel like we're restarting Dev in the process of restarting Dev Nets the things that have

been accepted into pectra aren't in the depth Nets fully yet it feels a little bit like yes 712 7212 is very easy to do but we're not we're not on top of Petra right now and it doesn't feel like the time right now is a good time to be adding additional stuff onto it regardless of the simplicity so I would rather make that call in three months like if pecture is going great and it's easy to add great but if not then you know we haven't added more stress to our festing load which is already being pushed to limits

Tim Beiko: okay um yeah Basu seems okay waiting as well um Perry is highlighting we have 20

eips um I guess yeah does anyone feel strongly that we should add this you know now otherwise yeah I am inclined to agree I guess I don't know Anar do you want to explain why you think we should make a decision now I'm kind of inclined to agree that we can wait three months with this and it doesn't really change anything um but is there a reason why it's yeah there's it like some urgency

Ansgar Dietrichs: so I mean I think in general I just think it's valuable to to make the decision as early as possible because there's a bunch of things that depend on it specifically with this there's a lot of tooling a lot of like wallet

developers and whatnot that I think would really appreciate knowing is early as possible at least that you know that there some sort of preliminary decision towards yes and then even if we can still work the back but at least that they can they have some signaling that they can rely on

Tim Beiko: isn't the on l2s though like for Tool engine wallets did they

Ansgar Dietrichs: yeah more like in terms of strategy of like do you do you forever basically have to maintain two separate like the the the chains that do and the chains that don't or I mean I don't have a strong preference If people really want to keep it out for now and then make the decision later it just feels to me unrealistic that three months from now we'll add any in and so I would just I would just make the

decision now to like add it in at least on a preliminary basis and then just look at a later point which definite it would be a good fit for for bringing it into the process form but I'm happy to be over I don't I don't feel strongly it

Tim Beiko: um anyone else have strong opinion

Andrew Ashikhmin: um yeah I think um um I'm slightly in favor of including it

Tim Beiko: and I guess yeah maybe um on the client implementation side like do all the teams already have this

done um I guess yeah does any team not have an implementation of this already or does everyone have it done so beu has like an open p request um on the E rip process uh Anar what what I know uh yeah there's some stuff in the dock um yeah that UL has shared but like can you give a quick summary of what the like core things are

Ansgar Dietrichs: yeah and I'm also happy wants to to

explain a little bit in my mind it's it's it's a several things so for one it's just like more procedural questions so like what do we do about numbering do we create a new EIP copy over the specs how do we physically reference the the kind of the status between the two but then also in terms of actually just making decisions do we ship it at the same address so that is within the R2 pre-compile range or do we move it over to the A1 pre-compile range on a one how important is it that basically daps can just use them as is across across the different layers um do we want to make small changes to the spec or are we okay with using the absolutely identical spec like I think those yeah those are questions they're like terribly like like hard to figure out but I I would

just hate to have them to have to do them on a rushed call three months from now

yeah

Tim Beiko: yeah that makes sense um I think Dan has a good question around reference tests does anyone no like we it does feel like we are bottlenecked on L1 by testing um because there's just so much stuff already so like is this in a spot where if we include it like the testing work is already gone is already done or like would we expect there to be a you know some fair amount of testing because um I think that's probably one of the things as well that that should play like do we include it now versus 3 months from now like if there's there's a bunch of testing work uh yeah it

feels it feels kind of unreasonable to to add more now um but if you know the testing coverage is pretty much complete um that yeah I think that's interesting um okay uh usas do you have a link to the testing coverage but I yeah and I guess oh yeah

Mario

Mario Vega: yeah even if it's already covered I don't think it's going to be so easy just to merge it into the L1 tests there's there's still going to be we're still going to have to review this um and and eventually merg it yes but it's not like it's not free is what I mean

Tim Beiko: and the tests yeah and the test that us just shared are like get tests they're not like uh specs tests

yeah um yeah

Mario Vega: so no no yeah so we we so so the process would be that we have to review them then convert them then merge them to L1 tests so it's it's not free it's definitely not it's definitely extra work

Tim Beiko: so I don't know I I think given

that i' probably lean fairly heavily against including it now um I think if the 7212 folks want to like you know continue pushing for it like it seems like there's support but um yeah having like proper like L1 level test coverage

um yeah I think um what

Mario Vega: what I would suggest is that uh to to help push this um on the testing side is just converting if if if someone that is championing this EIP could help Port uh these tests into the execution spec test repository that would be a very good

help um and and that can be done in parallel because right now the testing team is focusing on brag accepted eips so if someone that is championing this EIP could help us out to port to that would be uh I I think that will help the EIP to get to get uh to get into PR thanks

yeah I guess me and my team can help lot yeah

Tim Beiko: and I think yeah um yeah like uh Mario do you want to just share the two repos but basically um like yeah we can kind of show you where we need to get the cross client testing and what it would look like and I assume something we'd want to do as

well for this precompile is like pretty extensive fuzzing of the implementations against each other like we we tend to do for other pre- compiles um I don't know if there's been any work done there as well um I I guess I assume not but like um yeah I think if if we want to add this on top of the already sort of really really huge Fork that we have um yeah effectively having um yeah having very thorough test coverage coming from the the champions of the EIP uh I think is what we'll

need um and yeah there's also some comments in the chat uh Tony um around you know concerns about the quote unquote government curve um I don't think like most client teams have like raised it but um yeah do you want to just maybe give a quick overview so that everyone has a context

yeah I can do that um I hope you can hear me well enough um yeah so I'm basically against the um just because um yeah SE 56 K1 was initially chosen for certain reasons and

R1 was is different when it comes to um the parameters of the curve and also the kind of a second reason would be that this is kind of a perfect example what we can ship on L2 and yeah my my opinion not needed for L1

Tim Beiko: thanks um yeah I don't know if there's any comments or thoughts about um okay then I guess um yeah on the testing front uh it probably makes sense for the the 7212 Champions to uh kind of get it into

a spot where it wouldn't be kind of an additional burden on the uh testing team um yeah it's still CFI um so we can reconsider it like in a few months when we've done a bit more progress on Petra um but yeah it seems like the main objection from the client team side is really just uh or the main objection I guess you from including it is you know do we actually have the bandwidth to test this property um so to the extent that you can help with that um Ulus and your team then um I think yeah it it might make it more likely to to it will make it more likely for it to be included in Petra but um yeah I think not making a decision today is probably

the right call given how early we are anything else uh I don't know uh onard like client both your hands are up but are they still up from last time uh onar gone and times if you have final comment you can save now okay I'll just assume your hand is still up um okay sweet so next up uh Andrew uh you wanted to chat about Quantum resistance um so do you want to give a

bit of context there and I think it's worth breaking this into two different topics so um first just uh the risks and and concerns around Quantum and then second um you know if that has implications on veral and what they are

um yeah

Andrew Ashikhmin: right so it's like what vitalic highlighted at ECC that um a lot of um experts forecast that in the 2030s quantum computers will become powerful enough to break non-trivial cryptography so I mean it's it's difficult to forast especially the future but assuming that

there is a good chance of that happening so we are essentially with veral being Quantum resistant we are replace sorry not not being Quantum resistant we are replacing um um the commitment scheme in ethereum with the the current commitment scheme which is M Patricia try um uh with something that is potentially potentially vulner vulnerable so two questions if I I am no expert on quantum computers and and cryptography so uh it's it's it's a genuine question like that vulner vulnerability of veral to quantum computers is this like super

theoretical and uh yeah so it's something that we is we can like sleep well and not worry too much or is it is it a very real thing that's that's one question and um assuming that it is real then maybe we should um actually change the cryptography in vericle to something uh Quantum resistant because I imagine that well so the cryptography will have to change of course but things like maybe the key embedding scheme and um and the migration strategies a lot of work there can be reused so it will not be like a

total uh total waste so yeah we have something like so and yeah assuming that this vulnerability of vle is is is is is real then we perhaps should move to something like C Quantum resistant vle rather than because it will be a massive change for not not only for the protocol but like for the for the for the clients but for the entire ecosystem uh and if we are asking for this bigger change we we shouldn't ask for another massive change in in in five years yeah that that that's my I just want us to start thinking strategically

about it

Tim Beiko: thanks for the context and uh yeah uh sudip shared the talking question in the chat as well for reference for people um yeah Felix have your hand up

Felix Lange: so basically one thing to understand is um uh from what I understand about it uh the veral implementation is very vulnerable to Quantum Computing should it come to pass because it's like 100% based on the elliptic curve cryptography however current ethereum is generally reliant on elliptic curve cryptography and it's built into the protocol at a very low

level so basically it is if an exploit like if a quantum computer comes to pass which is capable of breaking this cryptography then we are screwed generally because I mean in the future there are these long-term plans to introduce full account obstruction but until this is done we are going to be vulnerable to these types of things and it's a we are very very far away from implementing full account obstruction I think thanks so this just something to keep in mind

yeah ignasio

um yeah so just to add what on

What Felix said um I want to also remind that on like three months ago we included blobs in the protocol and blobs used G commitments which also use cipic curves so as far as I know the strategy there was considering in the future changing Ki commitments to Starks to make blobs be Quantum resistant so um yeah I just want to make the point that uh unless something really relevant changed in the last three months regarding a real risk of quantum computers being real um I think maybe the overall sentiment around this

risk shouldn't change um but what I know is that um shos has started talking with the research team in the EF so they can start talking with um like experts in the field so we can get a more updated um I wouldn't call it forecast but you know sentiment around this risk which uh usually like people always think is 10 years away but um at some point that will be actually true and we should have a more like overall plan on on this topic not only for Burl but as said before for for a

lot of other things for blobs for signatures for having a destraction or things like that um so yeah just

thanks uh G yeah uh just fored to

Guillaume Ballet: try to answer all the questions uh by Andrew in order so one of them is can we rescue veral uh not really uh because yes like others said it's based on elliptic curves and in fact it gets a lot of properties from elliptic curves unfortunately elliptic curves uh rely all that cryptog graphy relies on Diffy assumption which is broken in by Quantum algorithm namely

some form of theore algorithm so if quantum computers uh come like become a reality which is still a big if even in the 30s um it would break verco and like ignasio and Felix pointed out other areas of ethereum that are probably just as important as the state is not it's not the state is big but uh yeah there's a lot of security assumptions in ethereum that's are beyond the state that also rely on that U one thing I wanted to add is uh or at least to dispute is um the idea that if we switch directly to Quantum resistance a Quantum

resistant uh feature well first we we lose a lot of the features of uh that vco was created like uh there's a lot of things like smaller proofs this is something you you will lose um homomorphism things like this that are extremely useful for building for stemming State growth and and doing other things but what I'm getting at is if we uh if we go straight to the final product uh it assumes we know what the final product is and that's that's a really tall order um because for example we expect to use binary trees for Starks but the Stark uh like the the concept of star star the the security of stars is

mostly conjectured so in a 15 years frame let's say quantum computers happen mid-30s uh we might discover something that is going to to break uh Starks or um or even some hash function we use so I think it's a bit optimistic to say we should go straight to the last uh the last tree model because we don't know what the tree model is we will have to upgrade the tree no matter what this is not the last time we upgrade the tree and the advantage of verco is that we are currently developing all the techniques to update the tree uh which can be reused later on so I don't think if we go to veral now or let's say in

two years and we uh find in 10 years that uh quantum computers are approaching fast which is uh I mean I I haven't really heard any experts say that I uh yeah um I uh I he I hear a lot of stuff on the news uh but I don't see any actual progress we still don't have a big registers like big enough registers that this would be a Quantum registers that would uh that would be a danger um but even if it happens we'll be able to react because we'll have all the tools already so I'm not worried about uh having to to change in a rush well in a rush in a relative Rush of

course if it happens from one day to the next will be uh will be U taken by surprise but if it's like a two-year process we'll be ready to do this and on top of that uh there's no guarantee that uh I mean yeah it's it's a bit naive to expect that we will never upgrade the tree ever again it will happen the the MPT tree you know it it was um created in 2013 2014 uh since I joined the EF people have been talking about replacing the tree so there's nothing uh there's nothing guaranteed like there's definitely no guarantee that we will never have to replace um uh the tree whatever it is uh so that doesn't mean

we want to ignore everything uh that is like that doesn't mean we want to ignore Quantum resistance we should have this conversation but uh I think we should separate it from the question verticle it should really be is uh is eum quum resistant is the internet Quantum resistant and then um not make that a showstopper of

overall

Tim Beiko: thank you um yeah so um I guess I agree yeah so I agree that separating out the quantum risk broadly from like veral and possible veral Alternatives is probably

the best way to think about this um and you know there's a lot of different ways in which uh you know quantum computers could could affect ethereum and and more uh you know things much beyond that so I guess what's the right place for people to discuss this like we're not going to figure out uh ethereum's Quantum strategy in the next 20 35 minutes um yeah is there some place that people are discussing this or people would want to discuss this or some concrete thing that people would want to see happen

Guillaume Ballet: uh I was hoping for Josh to to

answer that um but if he's not around um oh yeah Josh is here

do you w to

yes so I'm creating a group where we can continue discussions around this uh if anyone would like to join I guess I'll drop a link in the Discord after

Tim Beiko: should we should we create just a Discord channel for quantum resistance

can also do that yeah

Tim Beiko: yeah um do we have actually so we have a cryptography Discord channel does it make sense and it's not I don't know it gets a couple messages every now and then but like um yeah does it make sense to use that um and then just direct people

there and I see vitalic is among the frequent posters so if we want to like ask him for more context on The Talk uh um might be a good place to uh yeah to have that

yeah that sounds good we can continue the conversation there

Tim Beiko: cool okay so let's do the cryptography uh Discord um and and yeah continue there and I think trying to figure out like yeah specifically what the estimates are based on and then um you know what um yeah like what the actual risks are

Guillaume Ballet: um yeah um if I if I may add something uh regarding design itself it's also

been built uh in a way that we can swap last minute uh a a veral tree with a binary tree um but yeah like I said we would lose something but it's still an option so we can take our time to study the thing and make a decision when you know first we identify that the danger is present and um and that we have the yeah we have the the response to that Danger

Tim Beiko: thanks and yeah I guess that is that so there's a couple comments in the chat as well like this this is kind of the second thread is um you know given this and potentially other things like different you know developments on

different type of trees and whatnot um what's the best place to discuss whether veral um is the right next thing so we have sort of scheduled it for the next Fork already um we decide this de decided this I think early this year because we wanted to make sure we would keep it as a priority um I know there's the veral implementers calls but obviously those are kind of focused on you know actually working on the veral implementations um but yeah like are are those the best place for people to come and discuss you know potential alternatives to veral should we should we do this here and if so what are like the what are like the factors we want to consider

Guillaume Ballet: um

um yeah so to be clear there is no alternative to verco currently there's a couple ideas that maybe in three years will be a a correct like an unacceptable competitor to veral but if you want to discuss those ideas yeah we are happy to discuss that on the on the veral implementor call just because yeah if if those ideas are relevant we want to hear and discuss them

Tim Beiko: okay anyone else have thoughts on this okay so if people have you know alternatives for veral we can uh we we can

um yeah we we can discuss them on the the veral call and then obviously yes like once we ship ptra we should you know make sure that veral is still the right thing for the fork after um but I think that will be that will be late in if what we want is is to ship a state TR transition and use a different approach than veral so like if we arrived after pectra and we said you know there's this other completely different urgent thing to ship and maybe it's more urgent than veral you know that seems reasonable that we would we could make that decision but if we arrive to Osaka and you know we think like veral is the

thing we still think we should chip but there might it might be worth exploring another type of tree um that feels like the type of thing we want to start doing now um so that by the time we get to Osaka we actually understand what the trade-offs are very deeply so um if people do have like candidate uh Alternatives um yeah I think it it'd be worth looking into it now and we can we can discuss those on the viral calls

um Poes

Potuz: can we phrase the commitment of the form bi Osaka we're changing the tree and if there's any alternative to Burl that wants it to make it to Asaka then it should be at a level that we feel

confident as we feel today about verl being in Osaka so this might be this might sound impossible but what would be a tragedy would be to delay changing the tree because of some some statements about being in early research at the time so we should probably commit to changing the tree in Osaka um with the candidate today being

viral um ongard

Tim Beiko: do you want to explain why you don't think it's a reasonable commitment

Ansgar Dietrichs: yeah I think physically making that commitment would very severely restrict the design space it basically only realistically would allow for veral and maybe one or two potential alternativ and I think what very realistically could happen is that we

basically agree that hey given these advances in Decay or something we think that verle already has these and these downsides that we don't like and that within the next 3 years or so we would will be at a point we will have Bly Superior Alternatives and we will not make two UPG upgrades so we would rather wait for a few more years I think I'm not sure I'm not definitely not confident that that's where this conversation will end up in but I think it should definitely be a option that should be one outcome that we might land on and so I think making this commitment now seems arbitrary and no I don't see a strong reason for it

Tim Beiko: okay I guess Josh when is the next

virgal implementor call

uh so we had one this week next one is in uh not this not this upcoming Monday but the following Monday

okay so I guess yeah it might every two weeks yeah yeah

Tim Beiko: um I think yeah it probably makes sense to discuss you know specific Alternatives there um I don't know if anyone wants to do this in the next two weeks uh it doesn't feel like the most super urgent thing but um yeah it would be good to not wait you know 6 months to do this if we think there are other options um but yeah I agree that like having a

discussion there and like people having time to prep and and like actually read up on things is is the most valuable way to approach this rather than uh trying to like come up with Alternatives right now on the spot um yeah so I guess yeah moving this to the vertical calls um and then if I don't know nothing has happened in like 3 four month um 3 four months we can we can follow up on it here again um and yeah maybe one last question I so like what's the urgency to making to changing the tree in the next 24 months I know we talked about this a few months ago around the state size growth but I don't know if Gom or joshh you have a quick uh answer to that

Guillaume Ballet: I mean yeah it's a stat State Side growth it's also unlocking a lot of things with statelessness including smaller proofs to do many communication like improve the the way we we communicate for example between uh between shards sorry rollups if they if they choose to adopt there's a lot of there's a lot of features we we want to have and yeah it's also like you said initially it's it's mostly a state growth uh thing

so

Tim Beiko: thanks anything else on veral or Quantum otherwise next steps are the cryptography channel for Quantum and then add a veral implementers call for

veral okay uh next up then uh we had an EIP uh by a few different authors gum and way a leaf level State expiry um I'll post it I guess the draft the IP but yeah g you want to give a some overview

Wei Han Ng: um I think I can take this yeah perfect yeah yeah sure uh is okay if I share my screen yes yeah okay um so just going to do that and I've also put the link to the EIP in the chat so I'm just going to spend like uh 10 minutes going through this EIP so this better me everyone so thanks for having me here um

I'm going to introduce this uh e called 7736 this level St expiry it's written by Gom and I so the goal here is to get some feedbacks on this EIP and at the same time to um reintroduce the concept of St aspir to everyone because the progress of St aspir has been stagnant in the past few years due to different complications and uh research paths so we not only want to make this EIP work but we also want to spark disc discussion on the concept of St asiry how we can um integrate different ideas into the protocol yeah so without further Ado let's get uh right into it so the motivation for this EIP um as I say the previous C Solutions are very complicated and complex to implement and

they usually require require heavy changes in the uh etherum structure I.E um address Bas extension so um because they are so complicated people are not motivated to proceed with the um research so um hence we came up with this EIP 7736 which is a much simpler approach um to ciry and uh it's also better compatible with veral tree um so this EIP is um is a St asiry solution that is that can be enabled after vot Tre is implemented yeah um let's talk about specifications and the specific details on how this e work um I'm just going to talk briefly on the constants that introduced in this EIP but want to

highlight on three particular concerns here we are going to introduce a new concept or new domain or a new field whatever you want to call it um called Epoch but this Epoch is not the epoch that we know in the current protocol but you can think of it as an expir Epoch so you have like um Epoch length um which is the duration of the epoch here we denote it as six months then you have the initial Epoch counter um which basically the initial OT when we implement or execute this uh EIP then we have num active EPO which is the number of concurrent unexpired Epoch which is in which the default value is two so if you combine this information together you can just think of it as um these values denotes uh when a state is

considered as active or not U we will look into it in the next few slides um so changes to the veral tree so the current veral tree structure is like internal noes you have internal noes you have extension noes and you also have le note after thisp is method we are going to make a change to the extension Noe uh in which we'll add a last EPO uh field or variable to the extension node right so this um additional field is going to denote if a set of value is considered as expired or not and the exact expired rule which I'm going to show here is as follow right so for every R event um the last ort um field is going to be updated

with the value of the current Global Epoch that we have the epoch here again I'm referring to the expiry Epoch and for any read or write events if the current Epoch um the current Global Epoch is greater than or equals to the last Epoch plus the num active Epoch then is this particular event or this particular operation is reverted um because the set of values of this particular extension node is deemed as expired right so this is the expiry logic that we have um um in regards to the um how client teams want to do the expired logic like putting away the uh expired nodes um it can be implemented themselves right whichever logic you

guys prefer but minimally for each extension node uh data that needs to be kep our um the stand value of the LEF Noe um sorry for the extension node um this needs to be kept because we need to find the location of the extension node and we also need to keep the commitment of the expired extension node which is used for for validation when we do Resurrection so um talking about resurrection of the extension Noe um we will need to introduce a new transaction type called resurrect DX type which essentially contains the encoded form of a vector which contains the stem the last EO and the values right so this three simple field um we are also going to introduce a new form of cost which is

based on um Resurrection gas cost um based on the constants um introduced in EIP 4672 um the brief logic of how this work is that um you send a US send a transaction then um we want to resurrect a certain State we going to charge the gas cost uh after the gas house is charged we proceed with the validation and the validation process is on the high level is something like to uh just reconstruct the um extension Noe and from there you can validate against the one that is in the database and you can do a comparison between the commitment if to check if they they are valid or not right so why or rational of this EIP so again no ESC is required it's simple

it only references the veral tree that we have right now except for the additional field that we add to the um extension uh node um and we don't have to introduce like multiple pero trees as compared to the previous asiry Solutions um we we are going to have like smaller Resurrection proofs because we just need to provide the necessary data through the transaction the gas cost um for the retion is clear and uh overall we only need to expire the cold data the hot data or the active data will still remain in the state it's for comp compatible so in the future if you want to do like es or multiple EO trees is possible right and some questions that we have while writing this proposal um

most important question how effective is the expiry so it's a simple approach U but we expect that most but not all data are deleted we still have to do the simulation to check against the corner cases um so we need to post the statistics when we we have done that and the second question kind of the also the important one is why only right events update the last ort counter um because if you think about if it include read events as well it will refresh the last ort in the extension note then essentially it's considered as a right event because you have to recalculate the commitment of the exension Noe then you have to update your database so it's potentially adds a Dos Vector so some potential solutions that we have is to

increase the read event for the initial ort read to match that of a right event but we are still exploring other Solutions as well so feel free to give your opinions um yeah that's it um for my introduction of this EIP again welcome everyone to go to the discussion page to give your opinions and feedbacks on this EIP and hope to SP some more discussions on thep as a whole thank you

Tim Beiko: thank you H that was great presentation um yeah if if you can share the slides either here on the agenda that would be great um I had I had a question um and then there's another one by lqu but uh basically this is clearly more efficient

on like flatter trees but is there is there aside from like the efficiency Gain Is there any other like reason why this has to be closely coupled with veral like if we switch to like some other type of tree in the future or if we did it on the merco petricia tree would it still work but just be sort of less efficient or are there some other like um dependencies or earth type coupling uh with

Vergo

Wei Han Ng: yeah understood so I think the nice thing about vgo tree that let us to this proposal is that um the invergo tree the values are like sort of like you can think of it as group under an extension known so when they are group we can expir all of them at once if all

of them are not being access um together right so if you compare that to like for example MPT it's not the case so it's harder to do that on MPT um uh currently based on what I know for other types of tree um it depends on what what kind of data structure that you're referring to but if you have the sort of U um an a feature of like group elements together then maybe a similar proposal will work if not then I think is we have to consider other other Alternatives yeah so that's my take on that

Tim Beiko: awesome thanks uh then there was a question by like client asking um does does this stop the state from growing or does it

just means it keeps growing but slower forever

Wei Han Ng: um yeah I think that's a good question um so definitely we are not bounding the state completely um uh definitely the state is going to grow slower but at at what rate is going to grow at and um how efficient it is again at expiring the values we still have to do a simulation on against the all the entire state that we have and do the expiration and get the statistics so I I don't have the exact answer for that we have to do more analysis on that yeah

thanks

Guillaume Ballet: can me add something yes the like it's not necessarily tied

to veral trees but uh it's really especially interesting with veral trees because uh the veral tree is very shallow and has very extensive uh uh nose the nose are very large but their storage on disc is very small so while you're not bounding the disc uh sorry while you're not bounding the size on disc you only retain long term the smallest part of the tree like uh yeah the structure that remains on this long term is uh is much smaller than it would be in the

MPC

Tim Beiko: got it thank you and there's a last question by Lukes asking would client teams be expected to prune expired noes in the background

Wei Han Ng: um yeah um I think that's a

logic that you guys determine um it really depends like some client teams you can choose not to put it at all right so it really depends on the implementation

Tim Beiko: got it thanks any other questions comments oh yeah Daniel

yeah so I I just wanted to say that the the EIP from a from a tech point of view I think is very good for me it's just really the questions I mean every sort of State expiry comes potentially with very bad ux because I think it's very hard for users to understand that whatever state have disappears after some time if if they do not write it in the last

year something like this so I mean for me is more the question if you really want to do that in in the first place

Tim Beiko: I guess this is more a Dev ux than user ux thing in a way right like because as a user you would expect that your wallet would sort of handle this for you right like you tell them you want to interact with this contra track make this transaction and then the wallet will have to figure out like um you know what when is it but

I mean yeah but there are some cases you know people are losing their their phones with the wallets or they I don't know they they

they they just uninstall their old wallets and reinstall a new one and it might not have all the data for the for the resurrection so I mean it's not it's not impossible that there would be users who cannot resurrect State anymore the only the the only thing would be if there's like a third party where you can go to like orals or or something like this

Tim Beiko: yeah and I think that's always been the assumption that like either you can Resto you can save you know your like copies of the state or you rely on some third party to give you a proof um yeah and then you know this is like many many years ago the other idea that we had was

like State rent where um you can think of a way you can think of like State expiry as like an outof protocol market for the state where either you you manage it yourself or you pay some third party and state rent is effectively an in protocol market for the state where you could pay ethereum to keep it for you forever but um yeah I yeah I think like yeah we would need to discuss this um but yeah I I don't think there's a there's a way to resolve that it's kind of like the the core tradeoff yeah um any other comments or thoughts um okay Anar has some uh

comments around just understanding the density of the notes which uh might be worth looking into um where yeah so there's there's the discussion TR on each magician is that the main way for people to continue the conversation and and like reach out to you

Wei Han Ng: yeah I think just um go into the discussion link um we can yeah continue our discussions there

Lightclient: yeah uh maybe I missed this but was this something that needs to really go in with veral from the beginning or was the expectation that this would be something that is added in at a later point

Wei Han Ng: no we can do both right um if you choose that

we think that this EIP is good to go with verle directly then we can do that or we can do that we can decide when we want to enable this EIP after VOD is implemented yeah so that's one of the good things as well about this

CIP

Lightclient: what do you mean by um the ladder like we can just decide to enable at a later Point like we have the same similar situation with the MPT We could decide to change it or to change the format of the account header but we don't ever end up doing it because this is a complicated piece of code and we're afraid to change it so is this is there something about verle that makes it different in that sense

Wei Han Ng: yeah I think this is mentioned in the EIP as well um under the backw compatibility section so it's power

compatible with veral because um in the the default value for the like the fourth evaluation Point um um if you check the extension node structure it is zero it's default to zero so even if we add this um new EIP um this new counter field to the extension not it the when we recalculate the commitment is still going to be the same and hence it's better compatible

Lightclient: yeah okay I understand thank you

Guillaume Ballet: yeah just to chime in uh like like H said it's been built to be very backwards compatible because yeah the value zero all you need to do next time you when you activate the EIP is to add the time stamp on every right and then

the older tree values the values that were not written since the fork are automatically seen as old uh but we will definitely not do this during the veral fork because the veral fork is complex enough so that would come in a later Fork

thanks uh Lucas

Łukasz Rozmej: so my two sense here is that if the portal Network the devs manag to start the state Network uh before we go to veral trees and I supposedly heard that they planned to

start in like alpha or beta stage this year uh well then I'm I'm all for uh for this kind of expiration and pruning because there would be a good decentralized way to resurrect that for example uh the wallet or anyone could integrate to so just my two cents here would be good to catch up with them how are are they going how is it going for them with the state uh Network

Tim Beiko: yeah we can definitely do that um okay anything else on the

C and okay if not uh last thing I had on the agenda so I know we've uh wanted to prioritize EIP 44s more um anyone have updates on this

Parithosh Jayanthi: uh yeah there was just one tiny update I had made an e search post on using Torrance for EIP 44s and there was a request to add the proofs in the torrent so I've done that and publish a new torrent file um so in case someone wants to I guess download it or use it make sure you use the latest version of the torent

Tim Beiko: thanks can you share the post

yeah anything else okay then uh otherwise we can wrap up here um yeah thanks everyone um we'll talk to you all on the CL call next week cheers Everyone

by bye thanks byee thank you bye bye time

than

Speaker names adapted from ethereum/pm, CC BY-SA 3.0.