All Core Devs - Execution #158

Transcript

foreign [Music] [Applause]

welcome everyone to acde158 um a couple things today uh quickly you'll go over Shanghai and and that which is a plan in the next two weeks um but then most of the call we've got some big updates on pretty much uh all the largest uh potential eips for Cancun so we can go over those and if there's anything else people want to bring up we can do that at the end um I guess to start uh so we announced uh chappella earlier this week um I linked a blog post in uh in the

agenda I can put it here in the chat as well and uh I think Aragon is the only client uh For Whom the version has changed since the original announcement um so if you uh had originally downloaded version 2.4 only one uh you now need to change to 2.42 otherwise uh everything that was originally listed is still valid anyone from any client themes or testing or whatnot have any updates or uh thoughts I want to share on the announcement or their client release um prism

Terence Tsao: is thinking about another Miner meetings probably sometime next week to

fix some of API RPC issue this this is our slightly optional if unless you're like this operator you are pulling up this API then you probably don't need to update but yeah anyway watch out for our announcement

Tim Beiko: okay anyone else

Marius van der Wijden: um yeah we started doing some evm first thing for Shanghai um and I have not looked at the results yet but I'm currently doing it with uh guess Pro uh this you another mind and I'm going to add Aragon and

Nimbus El to it as well

Tim Beiko: cool anyone else have anything you want to share about releases or upgrades

Parithosh Jayanthi: um we have the last Shadow for plan for next week it will go through the transition either Tuesday or Wednesday and the ideas that release are up and running then we can test the transition with relays um if someone wants to test uh the least they're planning to have in the next couple of weeks let me know otherwise I'm just going to use the recommended releases

Tim Beiko: got it

anything else

lodestar

Phil Ngo: has a 1.7.1 out um it's a minor update for people using Gourley for testing with lodestar we may also do a minor bump with a fix for our BLS pool but that's it keep an eye out for that

Tim Beiko: okay but the 1.7 not always still is still correct if people just want to keep that correct

correct yeah it also don't work okay

Tim Beiko: maybe a small reminder uh related to the

eibs so now shapila upgrade is in public test net and obviously we do have the name mainly date announced so ideally we should have all the proposals which are going to be deployed on mainnet in the last call so this reminder is for the authors for proposal 3855 3860 and 4895 please go ahead and create a pull request to move the proposal to the last call ending on April 12th um yeah please reach out to echf you want us to create a pull request and you are okay approval otherwise yeah do let us know if there is anything we can do

for them thank you

Tim Beiko: if not just as a reminder so the fork is

scheduled for April 12th at uh 10 27 p.m UTC that's Epoch 194048 uh so please upgrade your node before that and for all the validators we have a withdrawals FAQ that's Linked In the announcement that you should check out um to make sure your property ready for withdrawals and then uh similarly Alex you made a small update that the withdrawals the IPS for it nine five just to add the actual timestamp of the fork into the EIP anything else to add on on that

Alex Stokes: no no it was just TBD and so I just put in the uh I mean that timestamp

Tim Beiko: um anything else on chappella okay uh so for uh Cancun we have updates on eof self-destruct uh the beacon State Route and the engine API so we can go through each of those um sign with eof last week or this week there was uh the mega eof end game spec that was put together um I don't know Alex Powell did either of you want to give uh context on that and kind of share the latest on

uof

Alex Beregszaszi: yeah absolutely

um you can hear me correctly right

Tim Beiko: yeah yeah

Alex Beregszaszi: so just like a bit of background vtof we had a um a fairly stable version you know last December and then we had this this proposal um to avoid code um in inspection introspection and they also potentially avoid like gas inspection capabilities um and so basically we have worked since then um the work mostly started at Edelweiss um to redesign the UF in order to to support these um requirements

um and also meanwhile a number of uh smaller requirements arose um and so basically over the past like two months we have been working on uh fleshing out these questions and uh we took the unified spec which um many of you may be familiar with um and we made the changes to the unified spec um uh in order to support these requirements um I also have like a guest uh with the diff between the two and the diff actually isn't that big um I think it's around like 200 lines um just to show that you know this may look like a lot of features or a lot of

new things compared to last time but actually the diff isn't that significant um I think the the biggest so the requirements we had is to avoid code inspection and I think we successfully accomplished the supporting that requirement um what that means is that creation has to change significantly um and it also means that we want to remove um operations like um you know code copy and xcode copy um and we figured out a way how to deal with xcode copy especially for the

direction of going from Legacy accounts to UF accounts um it's describing the document what should happen in in that case and beyond that the create instructions and the create transactions are the the biggest changes um so what we came up with is um actually not that far away from the initial proposals back in I think end of December or early January um I would say it's a refined version of that we have two create instructions um the first one is create tree which takes a index for a sub UF container and this sub UF container

would be um part of the the Creator contract and the sub-uf container is the runtime piece so this create instruction can be deploy time validated that it has um you know a correct payload for the runtime um and that is described how the creation process works it's not really any different to how it works in Legacy the main important difference is that we only have create two style creation which uses a code hash and we don't really have a need for announce um and then the create for instruction is a bit more interesting because with this create tree you can

imagine that uh somehow um this runtime payload has to I mean this init code has to enter the system um and there we have two options we can either create a specific create transaction or we can introduce this create for instruction which works a bit differently um so what we do is instead of having a specific create transaction the only um extend the the basic transaction format and in fact we we only want to extend the 4844 transaction format with the new field which is a list of init

containers and this list of init containers can only be inspected through the create for instruction so to create for instruction either um takes the index in this init container list or it could take this is the only question we haven't settled on yet it could take the hash of an entry um and that's the only way to inspect this data um and and at runtime this data is validated to be uh correct UF and then the creation process is the same as as it is in create tree so that's the only difference between

the two there's also an interesting um side effect of this uh we could have um basically a Creator contract or even a creator pre-compile but when I say pre-compile here it's it's actually not uh it doesn't need to be written in a sap compile it only means that having this evm coded a known address um there's an example um what such a Creator contract would look like at the end of the document um and it basically uh would take the index um of this init code list in the um and some additional data as the input

would perform the creation and return the address um the interesting effect here is that if you do have such a Creator contract and then instead of having to create transaction one can just send it regular transaction to this Creator contract in order to deploy code um and then the rest of the the additions is um instead of the return instruction returning the the payload we have a return contract um because that only that only re has an auxiliary data which is appended um to the runtime payload and the only

reason we we need this append option is to to support um this feature of solidity of immutables um this feature in solidity is um basically you have two options today on the on Legacy code had to Access Data you could just create storage slots or if you don't want to spend all the all that gas on S loads you can use this immutable feature in in solidity which basically translates into a pending constant data and creation time and then code copying um those data sections instead of s load

um so return contract is not returning the entire payload it is only returning a payload which is appended um to the the runtime container so that is the only piece which can be inspected and since we don't have xcode copy or code copy um if we do want to support this immutable feature we need a way to inspect the data section um and for that we have a number of instructions such as data size data copy and data load and there's a one specific instruction called Data load n which instead of taking a stack item for the offset in the data section

it takes it as an immutable as an immediate um and the the main benefit of this is um this basically replaces um this could be used instead of pushing constants in solidity you could just um data load from the data section where the the constant is something like an immutable so this piece is really just an optimization to State a loading instruction and but the other instructions would be needed to um you know perform this feature set um there are a number of other like smaller changes but I think this would be the I think the the important ones um and maybe I would close out with

think that every other question which um was an open question during um you know earlier discussions in December and January and anything which um has been um brought up by the community has been addressed into specification um and then they'll lastly be on the specification we have a implementation of each of these features in evm1 and we are in the process of creating um State tests for them yeah sorry this was a super yeah no thank you this didn't expect

Tim Beiko: yeah does anyone have thoughts questions

Andrew Ashikhmin: um yeah I think it's great but I I worry that if we try to deliver it in Cancun it just it's too big a change so I I would definitely want to have it in Prague but I just think I'm going to stretching it

Tim Beiko: got it thanks any other thoughts either on like this spec itself or like overall timing okay I guess where's the best

Danno Ferrin: I have a

question please yeah no go ahead um one of the design decisions calls we're adding a field into the transaction I'm interested to solicit um the opinions of the other core devs of their appetite for that Edition is it feel good feel bad great awesome you know some sort of a signal as if whether or not this is the right direction they would expect a transaction like this to move in

Tim Beiko: oh sorry my I lost audio for a sec Daniel I don't know if anyone answered do you

Danno Ferrin: uh no one answered no one raised hands so there's no concerns with

um adding an extra field into one of the new transaction objects to handle the new create uh approach

I

Marius van der Wijden: I do have concerns um one concern is that I didn't really fully understand uh the proposal yet so I cannot really comment on it so uh like not raising concerns right now doesn't mean that I might not have concerns in the future so we shouldn't take like not saying anything as uh has no concerns by default

Danno Ferrin: that's fair

um so but I do want to bring that to people's attention to please read it um and not just wait until two weeks before we're supposed to ship it on the test net

Tim Beiko: yeah and there's some comments in the chat about basically vertical uh being another thing we want to do you know after after Cancun um and and uh obviously you know if we push eof out of Cancun and you know potentially do it in the forecaster you know that also means we might push something like vertical out of the fork after do it in the fork after that

potentially we could do them together but uh you know that risks uh being a lot of big changes at once I guess where's the best place clearly like I think teams probably need some time to look into this more and kind of digest it where's the best place to share feedback comments questions

Danno Ferrin: there is an evm channel in the ethereum r d Discord um everyone who's implementing it is there we also have an evm implementers call um on the Wednesdays that are not El so it's the day before the consensus call I'm calling into that call it's about

the same time um just on the day before is an excellent time to come in and drill down with your questions and seek understanding

Tim Beiko: okay Alex

Alex Beregszaszi: um yeah so generally we had a number of different options had to to split up because you may remember in January I I said that I felt like um you know doing all of this at once maybe I'm quite big um I tend to think now that the chain set isn't actually that big as I

expected uh in January um that being said it is possible to to break it up um by skipping some of the create features um and rolling out um you know like for example skipping create four um or skipping giving create three and having um a intermediate server Legacy creates a UF code um we did review these these options and they they they are feasible so it would be possible to also launch this in two pieces but if we if we postpone all of these I would still be where that we introduce at least the

transaction field uh together with 4844 um and just you know it would be a field which cannot be really used but you would still pay the gas for it um because that way we can avoid like the prolification of new transaction types

Tim Beiko: any thoughts on that okay so I guess let's uh oh let's go

sorry

Ansgar Dietrichs: yeah yeah just variables wanted to say that my intuition would be that if we end up not bundling full UF with point before though that I don't I'm not very opinionated on specifics can we have some small pins already in that if still but what I would say is that probably it would be better to then just give UF its own Fork afterwards um in between like before the worker folk and just try to make it like a quick follow fog because if we keep basically trying to bundle it with another big change but then we keep prioritizing the other big change over UF we'll just keep pushing it so I feel like if we don't end up combining it with 24 it should really get its own talk afterwards

Tim Beiko: got it I think Theory I I also agree but I one risk like well I don't know if it's a risk but like there will be other stuff that people want to do at the same time as this eof Fork so we're just saying like you know the next Fork is eof and maybe there's not like CL changes that come in at the same time but I think you know there is some overhead to like having these Forks uh we can try to keep it minimal and and you know not have too many other things but um we don't we don't sort of get a fork between eof and or between like you know Cancun and Prague for for free right

like it just means we prioritize eof before whatever we would have done next um which is which is fine but like I think realistically you end up with like there will be other things that will be included along that and and um and you know it's another like I don't know three at least if not four five six months uh to put out a fork generally yeah so so basically yeah eof would be the big thing if that worked yeah um Lucas

Łukasz Rozmej: yes so we were actually discussing it internally in another mind and what looks sensible to us is not doing eof in Cancun but doing schedule another fork

for that uh that would the like the driving force or the fork would be eof and a specification um so that was like that that looks sensible to us right and then on the next for for example if the vehicle trees will be going in that would be for the vertical resource or something else but uh I think uh those two things are big enough to the to themselves that they uh if they want wants to do them they uh they occupy like most of the fork uh if we want to do them fairly soon after Cancun

again

Tim Beiko: uh yeah I'm missing the part where uh eof is more advanced than vertical and therefore should be scheduled first I really don't see I mean maybe I get the wrong impression but um yeah I don't want to push vertical again when it's way more ready than other things um eof I mean if you have needs more time I don't see the point delaying vertical as what I'm saying and what I'd like to understand why this is not obvious to everybody here so there's a comment about eof being much more ready than vircle does it make sense that maybe I don't know if on this call you have it here ready or maybe on the next call give a proper update on

virgo trees so that people can understand where it's at um sure I can do that I mean I can't even do that now if you want okay can we can we wrap up eof first and then we can yeah we can definitely do vertical today as well but I just want to make sure we wrap up eof yeah no but I mean if you if you have an agenda let's do it next time no problem yeah okay yeah so yeah if there's time today let's do it today but we can do it next time for sure yeah

uh Ansgar

Ansgar Dietrichs: um I don't want to say anything about better working emphasis already but what I would say is that actually it seems like but bundling them would really not make sense right because they're both

very heavy um El side changes so um I feel like if we are bundling something then it should be UF and uh 444 for Cancun but if that doesn't happen we should definitely have them in separate folks because that would just be a big mess and in my in my opinion

Tim Beiko: uh Andrew yes uh yeah uh I'd like uh to say like I I'm totally for vehicle but um um I suspect that the that that actually switching to welcome it's a huge massive change on the outside and

um it will take other teams a lot of time to be in terms of the engineering to be ready for vehicle so I kind of urge everybody to start looking at welcome and doing the necessary engineering work and it took Aragon like years to change the data model so it's it's a big and long change so I'm just thinking that realistic I'd love to be wrong but I think realistically it will take a lot of time just on the engineering front to be ready to switch to

buckle

Tim Beiko: got it okay so let's make sure to cover

if we have time today we can do more vertical um but otherwise next call let's make sure to go over it and get like an update from yellman and the different kind of teams any other thoughts on eof specifically okay uh in that case next up we also have an update on self-destruct um so uh young vitalik and then crowd have put together a spec uh for the uh basically self-destruct but allow allow it if uh if it's called in the same uh transaction as a contract creation which

addresses a bunch of the uh edge cases we we've discussed previously uh Dan crowd dooder if you want to give an update on that uh thank God you're completely breaking up

um so uh okay

Tim Beiko: yeah we can't hear you super well

Dankrad Feist: is this better

Tim Beiko: yeah much better

Dankrad Feist: okay so um so basically it's a it's a new version of deactivating

self-destruct uh we've had a few iterations so this one what it does is it's um uh it mostly works just like um the complete deactivation which just uh makes it basically only send all the funds um except um in the case uh where it's called in the same transaction where a contract was created in which it uh in which case it will look here or the all the storage and everything about the contract so like it will be from events point of view actually at least it will

behave exactly uh like the current self-destruct you cannot detect that there was um any contractor that address and um so the reason why uh yeah we suggest this is that at least for one of the examples we know that has like at least some amount of TBL in it which is the spine Finance contract that would solve that problem because what they basically do is they use self-destruct to limit who can call that contract basically they have a contract that everyone can fall but um but because it only lasts at that address for the durational transaction and the stands off destroyed um if nobody else can ever actually call it um so it's basically using this pattern for Access Control and

um and yeah so that that kind of functionality would be uh unaffected by this change um yeah um and the reason for this is that uh well we have had the different versions and uh all of them we ran into like either a security problem which is the one where we don't hear the storage um which uh was suggested previously um or like the other possibility would be of course to have like fully functional self-construct maybe we should show contact versioning by having this reincarnation columns

um and um I think that would be from what I thought significantly more complex to implement I think Beyond had to go at it and basically it's it's at least for gas it seems to reach the solution that hopefully doesn't break

Tim Beiko: um okay there's a first question in the chat and then we can do Andrew but uh there's a question from Daniel about uh if there's pending storage rights in the destructed contract well they'll storage right be persisted as part of the contract finalization

Dankrad Feist: sorry what is the pending storage right

Danno Ferrin: so if you're doing a self-destruct in a contract that exists and before you do the self-destruct you wrote to one of the storage slots do those storage slots get committed before the contract is marked as self-destructed

Dankrad Feist: no like the storage will be empty so like what the client will have to do is have to track all the rights that the contract does and if it does get self-destructed in their transaction then rights will not

happen if

Danno Ferrin: this is the case where it's not the same transaction we're an existing contract and they in the logic inner code write some stuff

Dankrad Feist: okay I would assume that in that case because at least the way it's specified right now

Danno Ferrin: it's it's not clear the way it satisfied

right now that

Dankrad Feist: uh I would say this but we can if we can happily add another bullet point to clarify this

details right I just think you should clarify

Dankrad Feist: okay sure yeah feel free to like add a bullet point on that

Tim Beiko: cool uh Andrew uh yeah I think uh the this version it hits the The Sweet Spot between uh reducing complexity and not breaking too many things so uh I think it's uh yeah it's a great option and uh I would see a fight for Cancun got it and do we know uh on your second point about not breaking uh too many

things does anyone know like if and what would break based on um I know we've done a bunch of analyzes but I don't know if we've had one where like we specifically look at like you know how much like what what would potentially Break um from this so I'll take this as a no

yeah sorry

Guillaume Ballet: if uh I'm only aware of two contracts that would be broken by just a simple removal of self-destruct and this fixes the there's some their problem so if uh yeah we need to we need a new

analysis to make sure this solution fixes it all but as far as I can tell it's the good enough solution no one else has come up saying this is not good enough for me so far

Tim Beiko: Okay so uh and there were two people at least you asked about making this CFI I feel like what might make sense is to actually make this CFI for Cancun and the sort of signal that it's happening and then in parallel to that's to you know run like it like a more thorough uh scan on the Chain you know with this uh potentially with like you know a prototype client implementation and and and try to analyze

yeah if anything breaks uh that you know we did not expect um but I think just yeah the signal that this is happening to the community and that if somebody's application or contract is affected by it you know they might reach out um yeah I think CFI will help with that does anyone disagree with that um so I'll I'll make that change after uh after the the call um so yeah the EIP number is six seven eight zero if people want to review this and if you are listening and are potentially affected by this please have a look

um to make sure that uh yeah you can raise uh you can raise an issue uh yeah what else anything else on self-destruct okay uh next up uh Alex you wanted to talk about uh making uh giving access to the consensus layers state route on the evm um you wrote a little doc uh give me some context but please uh walk us through it

Alex Stokes: sure yeah so the dark uh Tim dropped in

the chat is here and basically is like you know just a written form of what I'm about to say but essentially uh I just wanted to get some opinions on the path forward for verifying uh as a z-proofs so there's like kind of two big pieces to this and the first piece is having some accumulator from the consensus layer in the execution layer so the way we usually think about this is having like the state route or the block route for each block or State uh you know have some op code or something that exposes that into the VM and then you have this thing that you can make proofs against um that's generally the approach of

eip4788 yeah so the thing is though there's one other thing which is that the way SSD works is that you basically have these things called generalized indices and basically they're just like pointers into this whole like Merkel tree structure that you need the problem is that they theoretically can change and so now the question is like you know how do users of the system deal with that change um you know the straightforward answer is like the protocol it gives them nothing and they just have some governance but you know if you're like a staking pool using this stuff that's not ideal because now you need some like governance answer to like change this technical thing

and uh you know one other option that gets around this is just having say a pre-compile for these things um that could be updated you know as we need it to be and then essentially it becomes you know you can imagine there's like immutable you know contracts using this stuff because uh you know they just have The Changing State behind the pre-compile so uh I think for now my question is first uh you know does anyone have any takes on this problem and like in particular you know doesn't make sense to maybe add a new precompile for the generalized index thing uh we can said so the way we have it right now is with the ip4788 that

would expose the root and then you can imagine a different recapile for this generalized index accessor let's call it the question is like do we want to have two pricker piles for this we could imagine fusing them and just have like a generic SSD proof verification thing that does it all or yeah maybe some other option so yeah I wanted to bring this uh to the floor and I wonder if anyone has any thoughts on that

anyone

do we understand their problems yeah uh decrod yeah

Dankrad Feist: yeah I would generally before um having some way of getting generalized indices inside the protocol just to avoid the upgrade problem um but yeah I mean it's not gonna be there there's not going to be a super elegant solution because it also changes right so here the the pre-compile will at least have to also take Fork versions and I don't know what else to like know for each specific State router interpret it

Tim Beiko: okay any other thoughts

Alex Stokes: yeah I'll take this for now it's just uh evidence that no one has any particular preference and uh yeah sometime later maybe not the next walk or devs good enough for that I'll have some updates for 4788 and maybe I'll also have another EIP for some pre-compile here for

generalized Industries

Tim Beiko: sounds good next up uh Mikhail I you wanted to talk about get payload V3 with uh the Builder override flag

Mikhail Kalinin: um yeah thanks uh so

the um if I if if I understand correctly during one of the previous calls there was a kind of rough consensus to have this feature of filter override flag and then it was an agreement that we want to implement heuristics on the El side and it will suggest cl to switch to local execution um to block obtained from local execution engine rather than like go into Builders and get a walk from there if we see some censorship is happening so uh so I mean like there is a rough consensus that we want this feature and this proposal is in the field of uh when do we want it to

be implemented so this this particular proposal creates like a separate document and makes it in a way that makes the specification in a way that um it can be implemented separately from here next work so right after Shanghai for instance um yeah and the main question here is that is uh if there is any anyone from your client teams who wants to really work on it right after Shanghai and uh before Cancun then it does make sense to spec it out separately um and yeah do it this way

if yeah when I'm talking like work on this uh I'm uh it implies that really work on heuristics and really make this feature enabled not only change the format of the response of the get payload uh to and stab out this for the next update with the real heuristics so and the other option is that nobody wants to is willing to work on on it before say before cocoon then it would make sense to not do it separately and just spec it out as a part of like um Cancun specification so that's the kind of main question and this this proposal

suggests that right we will do it when I pushing high before I just wanted to bring this to everyone's attention and if there any opinions right now so from your client developers mostly great to hear them

Alex Stokes: I think you'll be a nice status functionality of the reasons you gave and if it's as simple just add in this extra balloon field that should be pretty straightforward and yeah that being said we don't want to uh I think block Shanghai for that change so pulling it out into like a separate stream makes a lot of sense

but probably sorry go ahead

Tim Beiko: I was just gonna ask is this something that all the clients need to have implemented at the same time I assume not right

Mikhail Kalinin: like no it's not really so we can do it really in uncoordinated fashion yeah but if nobody will really Implement heuristics for a censorship that photos has outlined or maybe some else algorithms before Cancun um yeah it doesn't make sense you know to spec it out like separately yeah I mean like prison will do it um I I I'm pretty sure but we need some

El clients to kind of say that yes we were willing to work on it as soon as possible and then it makes sense

Potuz: I mean like to to wait a minute beginning so why do we need the CLS to do anything I mean for the CRS the change is absolutely trivial right we either accept the recommendation or we don't

Mikhail Kalinin: yep

Potuz: so for us it's just a one-liner and for the Els well it depends on how much of our heuristics they want to add

Alex Stokes: I mean it's probably more than just one line but either way uh you know one

thing you could do is work with like say Geth if you want to write go and like prototype it out uh just like put out the idea you know yeah so already Marius put up a couple of PR's uh with uh with a proof of concept for one of the tour heuristics which is uh forking um for consensorship so and it doesn't seem to be such a large uh such a large line count

at least

Łukasz Rozmej: yeah I would have to look into like who does what and who can potentially help her but I think never mind can also do it like I mentioned on some other call

I'm like a bit um not sure about like coming up with proper heuristics but I see that there are some already

Marius van der Wijden: so I actually think that the eldest coming up with their own heuristics is really good uh because we don't really want everyone to like if if I don't know if the heuristic can be attacked um we don't want everyone to stop uh doing math stuff um at the same time so I think if we all come up with our own mechanisms then it's it's uh it's

a kind of Clan diversity improved pause I laid out a two or three uh heuristics that seemed very simple in the in the in the issue or in the VR which is just uh tell us if transactions are being reorged consistently if blocks are being invalid when they include particular transactions or if transactions are being delayed consistently it'd be nice if someone comes up with something

better to add it to that PR or to add it to that description um I I can't think of more that I would like to see and all of them seem to be easily implementable I'm actually willing to write the PRS if the Els or go ahead and put up the Boolean in the in the in the get payload I can actually try to help them writing some vrs for something else

if there's I mean lack of people writings never mind

Łukasz Rozmej: we'll pick it up and we'll

prototype something

it

Mikhail Kalinin: it it would be great if if like we can't yeah we can definitely come decide something right right away right here on the call so it would be great if just the alkaline developers look into it and then we come to some consensus that one or two teams are willing to work on it before can goon and have been have enough capacity to do that um so in in one of the next calls so doing some prototyping May really help to answer this question whether it's difficult or not

Tim Beiko: and I guess yeah if we can have one

client at least show that like on the El side they can Implement something before Cancun then it makes sense the spec it independently of the forge but then if no one sort of has the bandwidth maybe we bundle it with Cancun is that what you're saying

yep

Mikhail Kalinin: yeah exactly exactly that

Tim Beiko: okay

so I'm

Potuz: talking about stacking the actual heuristics or just the specification is going to be just include the Boolean

Mikhail Kalinin: I'm talking about the specification because the Boolean because if if it doesn't make sense to just add this Boolean to the specification if no one will really effectively use

its

Potuz: consensus that someone would write

some some non-trivial heuristic and that's gonna be good enough to specify the Boolean uh yeah what's going to be specified is only the Boolean right

yeah yeah

Mikhail Kalinin: yeah definitely I mean like uh I I'm trying to understand whether it makes sense to specify this movement separately from

chemical that's that's amazing

Potuz: that makes a lot of sense to me thanks

Tim Beiko: yeah does anyone disagree with that okay so yeah let's do that um obviously we can keep this PR open um and uh um um

yeah as we as we have more El clients Implement things uh you know if if that happens before Cancun we can just merge it in and otherwise we'll add it as part of the Cancun specs um okay uh so that got us through all the stuff we had on the agenda today we can discuss Virgo in more depth uh depth gilm if uh yeah if you're if you want to give an update now sure um yeah so um I mean vertical's been going along fine there's been two test net that were produced uh one of

them is called Beverly Hills um and this one is closer to what well hopefully Prague would be which is uh just using a vertical tree without producing the proofs so of this uh on this type of network you don't need to have any work for uh like on the CL side so that would be uh that would be a four that would not require any any change on the on the CL side and then there's another test net called calcinon which this one uses uh like adds to proofs to the to the execution payload or execution data um so this one is also working Netherland has just joined the two the two test Nets uh last week I mean the

last one was today but uh casting was today but uh been really Health was last week or two weeks ago and uh yeah there's uh there's been some progress in the performance as well I think we're only currently 40 slower than than regular MPT and uh yeah we still have a few things in the pipe so I'm not saying it's ready to ship in Cancun um but I still get the impression at least the spec has been stable uh transition is uh okay still an open question but uh yeah I I don't really want to share stuff about the transition because it's uh it's improving greatly

uh Ingrid strikes at the moment so I I hope to share something about this soon but I don't see why uh it would not be ready for uh for another like for the next Fork after Cancun excuse me simply because uh um yeah I think like most of the questions have been answered over the last two years and it's just a matter of implementing so I understand that for arrogant database model is a bit more complicated but I would say the the real problem is that people don't look into it um but never mind has implemented it in uh in less than a year so I think at

this point it's uh it's quite clear it's uh it's looking realistic to to be shipped in private and yeah I don't know if there are questions about the the current status but overall I think it's it's getting close to ready

I have seven questions

Łukasz Rozmej: okay so uh have you tested the implementations against reworks against

reals

Guillaume Ballet: uh yes

Łukasz Rozmej: okay uh Json RPC uh does it does have any degradation in like eth call things like that right

Guillaume Ballet: so okay Jason RPC hasn't been tested

okay have you tested mainly okay may not like blocks

Guillaume Ballet: yes

Łukasz Rozmej: have you managed to do a mainnet shadow

Fork

Guillaume Ballet: right so this is uh the problem um I mean but when you're doing a maintenance settle for you pretty close to the end um it's uh yeah okay new um there's a new decision that has been okay there's a new design that has just been decided yesterday so no it hasn't been done but it will be done this month

Łukasz Rozmej: uh sorry

multiple client transitions uh so we will be good to have more than one client doing the transition right uh generating things in the traditional results finders just have one client do that

Guillaume Ballet: no no yeah we should have that I agree yeah

Łukasz Rozmej: okay that will take long time so it's good to like maybe work on it earlier in parallel but just just lighting problems and last one and that is a big one snap sync for vehicle trees

Guillaume Ballet: no yeah there wouldn't be any steps thing for local trees yeah it would be a

vertical thing

Łukasz Rozmej: okay uh how would it perform compared to snap sync

Guillaume Ballet: I mean yeah I mean presumably better but yes we don't know until we we have tried

that

Łukasz Rozmej: okay so quite a few uh question marks right

Guillaume Ballet: so um no okay yes I'm not like I said it's not ready yeah I agree a little closer to being ready I said it's definitely not ready like it can be shipped in

no

Łukasz Rozmej: no don't don't worry I'm probing I'm probing where we are right um decision when to ship it right and um yeah uh I still think it's far away uh it's a lot closer than it was like some few months ago and so yeah I'm I'm reluctant to to

uh rush it right until those uh questions are we have answers and we are happy with those answers for those questions

Guillaume Ballet: fair enough uh at the same time I think that doesn't change what I said um this pack is stable so it should definitely get more interest than it does now people should look at it that's the point yeah

Łukasz Rozmej: yeah fine I'm just a bit you know uh cautious that's what I want to say

Guillaume Ballet: okay fair enough uh I think that was five questions

Tim Beiko: you want more I I can't I counted six uh questions okay my bad yeah Andrew you have your head up as well

Andrew Ashikhmin: uh yeah I just I'd like to clarify uh like Ferrari gone at least my understanding is that it's easiest for Aragon so uh uh I I'm not worried about Aragon implementing vocal trees I'm worried about other clients because how I I see it like I don't understand how you can do it without moving to the data model with unhatched keys maybe I'm wrong but I just don't get it and it's the last time when I spoke spoke to Peter uh the get is not moving to the gas is still using hashed keys so I I just don't maybe Mario's can comment I

just don't understand how Geth is going to implement velcro tourists will if they are not moving to unhatched keys so you need to rehash so where where do you get pre-images from or you don't need

premises

Guillaume Ballet: well I mean yes you need to distribute the pre-images but what happens is uh we're looking at a solution where only a smaller number of nodes uh I mean talk to Julio about it he has uh he has worked on that topic um the the idea is that uh some nodes that do have the primages typically arrogant uh will share the converted database with other

nodes

okay

Andrew Ashikhmin: yeah that that's that's fine but it's still like uh a uh yeah again my point is that for Aragon it's easy but uh other other clients should be happy with the with with this plan

mm-hmm you have

Łukasz Rozmej: to comment on that I I really uh like uh I know that you can verify it and it's verifiable etc etc but I like have uh anonies on this topic too right so I somewhat agree but this is like maybe maybe maybe just just a feeling that is wrong but I I'm I'm honest about it that's too uh

get the state from one note for example but how verifiable is that how easy verifiable is that

um right

Guillaume Ballet: I mean that would be very easily verifiable you just have to check if your data can be reconstructed um but yeah no if I agree with you that this is not uh the my favorite uh method either either sorry either but that does that seems the the simplest at this point although I might change my tune in just a couple days um I'm actually lost I lost the point of your question could you repeat your

questions

Łukasz Rozmej: was it

really a question just was a comment more so okay

Tim Beiko: yeah that's relying on Aragon only to distribute at the database is uh yeah concerning yeah we can do something like oh sorry go on you're breaking up yeah we no we can't hear you at all big red uh what I was also thinking is that we

can have a special small uh sub protocol for for just pre images uh we and um we can implement it in in Aragon and then our other clients can just just get the primages they want uh but it's it's we need to test that

short

Guillaume Ballet: uh just to address another comment uh and like so far uh the best implementation we have is with arrogant um I never said it was only going to be arrogant I would do this it makes sense that everybody tests uh like everybody tries to produce the same the same image

and needs to to verify that that it matches

Łukasz Rozmej: so another mind is in the process of reworking its state DB and we have actually two streams one like more more proven to to work and one very uh very uh experimental so I think we would be after we if we managed to ship it and we can ship it to this year a question when this year um we might be able to to do that

migration more easily but yeah this is still an open question uh we also this more experimental layout it's also done in this way that then later could be uh uh with a lot of changes applied to uh vertical trees so uh it's called paprika if anyone is interested and it's a direct um direct storage of the Patricia Miracle 3 on the disk using the map memory mapped files in a way so there are some good docs being produced by

Shimon so if someone wants to check it out I encourage

Tim Beiko: any other questions thoughts on wrinkle trees okay I know Guillaume you said not to ask about this but I'll try anyways but I'm curious if even if you don't have a full spec yet about the transition like if you can share just a bit about your thinking about that and that maybe like the trade-offs and and

yeah just because we have plenty of time now to talk about virtual trees so it's probably worth going over as as much of it as we can

Guillaume Ballet: um yeah sure I mean once again I'm about like we're having some results star coming in that uh might make this change or plans um but so the idea is that indeed because so far the translation was taking so much time you have to rehash everything um that I mean except arrogant um that you have to do it offline like you need some powerful machines to do it and

um from our benchmarks so far um to be updated soon um it takes about um yeah 18 hours in the case of uh of Aragon and much longer for gef to produce to produce a conversion that then is sent all over the like to all the all the clients on the network and well more exactly all the clients on the network download it and they start replaying blocks on top of this conversion and catch up with the with the ampg head and they have to do this before a given four block and at the fourth block the MPT

um is no longer updated is jettison and uh the vertical state becomes the the official state so yeah that's that's roughly the plan so far um we're having some uh yeah okay now I don't really want to talk about this yet because it sounds too good to be true but yeah the idea is that we would somehow be able to ensure that everybody is able to do their conversion themselves but currently with uh with all confirmed benchmarks this is not realistic so we need to to help uh like the some very

powerful nodes need to help less powerful notes to do the transition

Tim Beiko: got it so and then okay and so at least I guess the the thing I was worried about this the earlier specs of vertical trees required like uh the network to stop producing blocks for a while or something like that but with this spec you would not have this issue correct like you obviously you need to figure out the way to do it efficiently but you're sort of swapping in the background from the vertical the Merkel Patricia tried to the vertical try um when the fork happens but yes

Guillaume Ballet: got it yeah it has never really been uh seriously considered it was more meant

like a joke maybe that was a joke that was too catchy but uh yeah

Tim Beiko: yeah but yeah it wasn't clear that there was an easy way to do it without downtime basically and so I just wanted to make it clear that uh there is or wouldn't necessarily called Lizzy but there is a way

yep I'm

Tim Beiko: cool any other questions oh does it okay there's a questions about do ZK EVMS make vertical tries redundant and the yeah I don't know if you haven't been crap do you want to take that

Guillaume Ballet: I don't know if dencrat is closer to a

connection my understanding is that yes well ZK VM the long term uh plan is to get rid of uh like to replace vertical trees with uh with a CK um like construct uh I don't think it will be made completely redundant because some of the choices we have are specifically designed to be ZK friendly um but yeah that's just my understanding I don't have uh yeah then credit should be able to answer that better

Dankrad Feist: can you hear me now kind of so yes like a full ZK VM that can

decentralized in a fashion uh prove in like say a seconds that the block is correct would indeed make robot 3 is like not necessary but I think we are quite a few years from that I'm willing to be proven wrong but that is my current assumption that yes like I mean ZK VMS are coming but like they still have much higher latencies they also have massive prover costs so I kind of have my doubts that they would currently get say a majority from the score like say oh it's okay to just rely on them uh to know whether L1 blocks are valid so so

far I think we still need

blockages

Tim Beiko: any other questions on vertical trees um any anything else anyone wanted to bring up okay well uh yeah then I guess we can wrap up so um we'll move the self-destruct EIP to CFI um and I think yeah if in the next couple weeks people can review the stuff around eof uh the the 4788 and the other Beacon State

proposals um and look at SSD as well we can continue those conversations uh on the next call and the next call I believe will be right after chappella so uh yeah last time uh I guess this is a time for users to upgrade and uh we'll go over how the fork went on the next uh next one of these um yeah I guess we can wrap up thanks everyone and see you on the uh CL call next week thank you

all right thank you thank you thanks bye foreign foreign

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