All Core Devs - Execution #129

Transcript

[Music] [Music] [Music] [Music] so [Music] so

[Music] so [Music] [Music] [Music]

[Music] [Music] so [Music]

[Music] [Music]

[Music] [Music] [Music] [Music]

[Music] [Music] this [Music]

[Music] [Music] [Music] [Music]

[Music] [Music]

[Music]

Tim Beiko: and we are live uh hi everyone welcome to awkward devs number 129 um first one of the new year post the agenda in the chat right here um basically three things to cover today first uh updates about the merge and uh

kenzugi uh there's the issue that uh we found and uh marist recently wrote about um then uh moody is here to talk about eip 1153 um and then the last thing is uh now that you know we're starting to see kind of the final stages of the merge uh there is a bunch of things in the backlog for shanghai and it's probably worth starting to have some conversations about uh how we want to think about that what we want to prioritize and what not um i guess yeah to start on the the merge stuff uh maybe it makes sense i i don't marius

because you had the the tweets today uh do you want to give us kind of a quick recap of you know what you saw in kinsuki over the holidays and then the issue that came up today

Marius van der Wijden: sure can you guys see me on this mic yeah probably um so uh over the holidays um kenzugi went pretty well uh no major issues um i created a a bad block generator so note that like generates bad blocks uh with like different different strategies and one of the strategies is to replace

fields in in the block with other fields and today or maybe yesterday this actually hit a bug so what the fuzzer did was replace the the block hash field in the in in in the execute payload parameters uh with the parent hash and so implementations should uh get all the get all the fields from the from the from the execute payload parameters construct the block and verify that the

hash of this block is equal to uh the block hash that is passed passed in um with the with the para with the with the execute payload um the problem here was that because um the past uh payload the past uh the past block hash was a valid block hash from the previous payload some clients had some caching in place particularly nethermine had had some caching in place just looked up the the the block hash

and returned valid even though the the block itself was not valid regarding this this rule and so [Music] uh yeah that will there was a big problem that that created a fork between uh geth and nederman bisu so another man bisou both had this issue that they didn't didn't check didn't correctly check that it's fixed on another mind already and then there was also a a fork between

lighthouse and teku on the guest site so the geth chain went on for a bit and it split and um [Music] i think we currently think that the issue is uh similar that there's some kind of caching in in tikku going on um that was not really uh yeah that was not not working properly if you provide the block hash of a a valid block um with with another payload and yeah so it's it's really nice that the fuzzer actually found this

but it means that right now kinsugi is not finalizing but we hope to update the notes soon to have it finalize again

when did it last finalize um [Music]

Danny Ryan: 129 epochs ago

a hundred and twenty ninety bucks ago thirteen thirteen point seven hours ago got it is there a a

Tim Beiko: case where like i guess we can't fix kentucky i assume like as soon as we have a fix on on basu and nethermine deployed uh as well as the the lighthouse deku one then we'll we'll

just finalize again and we can keep using the

networks that correct

Danny Ryan: it's probably worth going through the exercise at least to some amount of our effort to get it to

finalize right just because uh sometimes putting things back together is harder than we expect right then like this is going to happen on main net eventually um so like we're not going to give up maintenance hopefully not

Vitalik Buterin: right well okay we have well we need to be prepared for the chance that will happen on

midnight yeah yeah

Tim Beiko: right yeah great work on the fuzzer mirrors uh very cool that we got this

on

the devnet thanks perry

Tim Beiko: i think i saw you come off mute do you want to add something if you're speaking we can't hear you

Parithosh Jayanthi: sorry do you hear me now

yeah

Parithosh Jayanthi: just for argument's sake the netherland and bazoo fix won't give us enough participation um such that we'd finalize we need the teku fix in because takeover comes from about 36 percent so as long as taco is fixed then we reached finality

but yeah

Tim Beiko: and that's okay i mean even seeing the other two join back and seeing us at 60 you know for the next day is also like a that's a reasonable uh state for the network to be in for us to

observe

Parithosh Jayanthi: definitely and we still need to figure out why tekku off again because right now we see three forks um most of the analysis so far has done has been done for the first

four

Tim Beiko: thanks for sharing um aside from basically this issue was there anything else that anyone wanted to discuss about

kinsugi

Danny Ryan: i just want to say there are probably there are one to four test cases that should come out of this just they must

so i'm um yeah go ahead so yeah i i

Danny Ryan: i spoke with mikhail a couple days ago i was off during most of december so i i'm playing a bit of ketchup this week but um the feeling was there are a few things coming in the pipeline on the execution api i think there's a refinement on

what returning syncing means um in in the execute and the for choice and i think there's maybe like a one naming change and a couple things like that so the the goal is to get this done very quickly and get get an update out and likely to once that comes out on the order of three four weeks do a do a test that reboot for a public test net get things in order then from there decide you know what is the timeline unfortunately their test nuts and and stuff um so there is a minor spec update in the pipeline um

and so i would say we continue to play with kingsugi continue breaking be continuing to resolve kenzugi um until that comes out i think simultaneously uh perry and others are looking to shadow fort gourley and to be able to do that on an automated basis the nice thing there is that we can on a more continuous effort actually test the transition um so kind of two two efforts there on like test nets would be the the path continual path on public test nets and then a path to kind of continuously test the transition process which obviously could give us issues and has done

complexities

Tim Beiko: makes sense and i think the only like two other bits that that are probably like uh kind of outstanding uh there's all the stuff around optimistic sync but that seems in progress uh the other one

Danny Ryan: right and i i did catch up with michael allen paul about that one and there is um there's a spec for optimistic think um it has been implemented or is being implemented by clients and is generally agreed upon as some of the the corner cases that they were concerned about um are resolved here but there's plenty of testing to do on that so

Tim Beiko: and then the last bit is the auth between the consensus

and execution layer so that's something we talked about uh a couple times but i don't think have settled on a specular or a standard for

Danny Ryan: um and i think mikhail in our conversation was hoping that uh martin twende he had said he might jump in on that i hope martin's here um so i think maybe you uh mikhail and i should think on that in the next early next week uh so that we can get that into this final update

yeah and martin yeah sorry i'm in drag my feet about that yeah we should have a discussion about it does it make sense

and i think

Tim Beiko: i think that's the last kind of feature or big thing aside from all the testing that that um that was still missing and if we're targeting uh another kind of long-lived test net we probably want to have this in so that we can test it as part of that

Danny Ryan: yeah that was on mciles list i had just around about it

cool

Tim Beiko: anything else about kitsugi or the merge that people feel we should we should discuss

Danny Ryan: that's all on my plate till the you know

two weeks from now i think we'll be the spec will have been released by the next one and will give us you know the new discussion on what the next segment looks like

Tim Beiko: yeah and we uh yeah we also have the the consensus there call next thursday so we can use the first bit of that to also cover anything that comes up cool um yeah thanks everyone uh it really feels like we're kind of getting there and and there's more and more uh yeah just more and more finalizations

to do

Danny Ryan: yeah awesome work on ever from everyone on kimsuki before the holidays uh it was really awesome to do that

Tim Beiko: um cool and yeah okay so we have uh

moody here uh who has been uh working on eip 1153 and he wanted to take a couple minutes to chat about it and why it can help uh lots of applications uni swap included uh on mainnet um yeah so moody do you want to take a few minutes kind of walk us through the context yeah share your thoughts

Moody Salem: yeah sounds good thank you uh hi everyone i'm moody i'm a smart contract developer at uniswap um and yeah this might be a little bit early to be discussing the cip but uh but the context is that i'm experimenting with

um some improvements to our smart contract design um and just give the full context the idea is that we want to put all the pools in a single contract and allow you to flash uh do any action across all the pools and so basically you'll be able to like mint swap burn without paying anything but the diffs at the end of the transaction um and so you're also not transferring any tokens so it's a lot more efficient um in terms of like how many slots it touches um and so there's two ways to do this as far as i can tell uh one way to like create some sort of like vm within the evm where you pass uh some

some bytecode to the singleton contract and then it executes so you're just telling it's like a custom set of operations that you can give to the singleton contract and store the diffs the balance diffs in memory but this isn't very flexible it's not very elegant the other way which i think is more elegant is that you call into the singleton contract and you acquire a lock and then you can do whatever you want and the contract just keeps track of uh what the diffs are um and at the end of the lock you just have to have net zero deltas of any tokens you owe um so this just feels a lot like easier to work with

as an integrator or developer and also we get to reuse the evms so they can make all the calls they want to like other contracts but it requires us to have some sort of like persistent memory between these like calls uh to the single spin contract like swaps and mints and burns um so for that all we have today is like storage and storage i guess as everyone here probably knows is uh has some like refund mechanism for transient storage so if you set a slot from zero to non-zero then back to zero uh then you get a refund a large refund which is the majority of the storage costs but that refund is capped uh in the latest hard fork to 28

of the total gas costs but you can't do it you can't do this efficiently if there's a lot of slots that you need for like accounting um which we do need a lot of slots um and um and yeah you also have to s load each of these slots just to know that they're zero um which they always will be in this pattern so like s load and s store don't work very well for this um it also doesn't interact very well with uh execution parallelization because you should be able to paralyze all the transactions that touch these slots because they're always zero at the start and the end of the transaction

um so there's there's some interaction there like access lists that is messy um so the proposal is that uh aip 1153 introduces these two new op codes t story and t load which operate basically exactly the same as s load nest store except uh the first t load of the slot or the the slots always start at zero um and uh at the end of the transaction the slots are never persisted so in between transactions uh there's no interaction um and uh

and yeah it's also uh has much lower gas cost because you have to load anything from from disk um or from the state tree um and and yeah i think i think this would be like a very successful pattern if there was some sort of like persistent memory between calls um and i think like these auto codes can also just be a lot more efficient than the existing storage drop codes there's also existing use cases um like uh like obviously re-entrance ceiling blocks um but that's just one slot so it's not as beneficial there um and

yeah i guess i'm interested in hearing if there's like other solutions that uh that are better than this that i can push forward because one of the big cons here is that any existing contracts that could make use of this will now need to upgrade and deploy new contracts um so yeah that's anyone has any feedback love to hear it

Tim Beiko: yeah thanks for sharing it um martin's hand is already up so we can start there

Martin Holst Swende: yep thank you um so i remember this uh proposition it's fairly old it's from 2018

and as i record so this one is basically a store which doesn't exist and then it persists across the the transaction so you have the across call frames and i know there were other variants i think there were at least one other variant of this of how temporary could women [Music] and they differ somewhat and i'm just curious if anyone recalls the other flavors of temporary storage that i like if we're considering it what which ones which variations would be on the table that's kind of my question

i guess we collectively

forgot

Tim Beiko: yeah and i guess alexa is an author on this eip and from what i skimmed on discord i think this was his kind of counter proposal to some of these variants so uh it might just be worth also asking alexa offline with the different variants where and and their

trade-offs

Micah Zoltu: where we have witnesses um for everything uh one can imagine i think uh providing as part of the witness providing just an assertion that this slot will be loaded and i guarantee

you that it will be zero at the start and i guarantee it's easier at the end so the um contract didn't actually have to do any reads so hypothetically this would allow us to also back port transient storage to legacy contracts if that was something we desire because we basically put it at the transaction layer and say the transaction can declare um you know what some storage slot is going to be at start and end and it will guarantee that it will be the same so we don't have to do the disk hits

so are you suggesting changing the semantics of a s load in the store in the cases where they coincide with the slots that have that guarantee

Micah Zoltu: yeah so basically you write a guarantee as part of the transaction and then um the evm would then say oh i already know this is not going to change and so i can treat it as transient storage even though i'm doing that in a store um i channeling my inner um aragon team the uh this will add complexity avm versus just adding new op code is much simpler so i can definitely appreciate the argument for just using the new

op code and that and

Moody Salem: that design would you not need to load the original value to see if it is what the transaction says it is

Micah Zoltu: yeah you're basically just asserting

that you know you could even just assert you know when you can imagine it this way when you submit a transaction the transaction as part of the signed transaction it says um yeah nevermind this won't work ignore me nice little break stuff yeah never mind

yeah and i was gonna say also that that scales with the that scales with the size of the storage that you end up touching like the maximum size that you end up using in [Music] in the process of executing the transaction how many transient storage you're using which we might not want that scaling in the witness um whereas if you have the t-load store then yeah

Martin Holst Swende: but for for

like the the concrete use cases would this um i'm not asking moody [Music] would you use this typically a lot of this or just like for the re-interesting log there's just one or two right um feeling that the the win in having a separate key low key store it's not that great if you're just using one of them um but if you were to need like 20 or 30 or 50 there would be a huge difference in the gas consumed

Moody Salem: yeah so so for the accounting and the example i gave i i've written a

prototype and uh it's like a minimum if you just do one swap it's like a minimum of six slots um and that one swap itself might cost 100k gas but then these 6s stores cost another 120k of which you're only gonna get uh up to like a 40k refund so uh it's it's very expensive to use storage transiently but and that's why we need this op code because otherwise it's not it's not really feasible this pattern

Micah Zoltu: yeah and back when i worked on auger um we ran into this class of problem quite a bit where

we had some piece of data that we're basically just passing from one call frame to the next and it would need to be passed you know through all of them and so your options are pass it as call data through everything and you just have to keep passing it over and over and over and over and over again like for the entire call stack if you had some sort of transient storage you could just write it to the transient storage and then the entire call stack would now have access to that so you don't have to keep incurring the um the call data cost each each frame um so just another place where this comes up where transient storage could reduce costs

so there's no call there's no call that the cross frame

Micah Zoltu: there's not

although there's a memory expansion cost

but no there's no quality to cost across frame even uh cross um contracts

Martin Holst Swende: yep even yeah i mean

okay

Micah Zoltu: well ignore me i'm apparently totally out of it today i must be misremembering

Martin Holst Swende: but yeah i mean there's still an overhead because when you access this in the next contract you have to expand the memory in order to read it so so there is an overhead just

Micah Zoltu: yeah maybe that wasn't

hold it over

Moody Salem: um so if i remember correctly i think that this eip was originally like

preceded by like the different accounting for s stores of transient slots um but i think what makes it kind of unusable is just the refund cap um so if there was no refund cap this might be workable even though you have to pay a bunch of gas up front you still have to slow the slots but um but yeah i think like i think it's worth putting these into a separate op code because we don't want them to break and they have different semantics as far as like parallelization and um yeah and like yeah

storage around a lot of stuff

Martin Holst Swende: my feeling here is that th these this is one of those eeps that a lot of us think are like fine and and it would be really nice if we had it many years ago and just a good thing but it's kind of hard for us to like put uh how important is this and how much better would the world be like for contract developers if it exists and kind of how do we prioritize this against other future changes in the ibm and i think that's probably maybe why it has not been implemented um

there just hasn't been a large enough cry from the like community of developers that we need this um and i think so what i mean technically i mean it's worth but it's it's not undoable but yeah how how important is that and i think there needs to be some kind of work done to make it um explicit how how much better would it be what kind of savings are looking at how often i know how yeah how much do people want this is there a strong developer that desires this feature

so we can like rate compare it with other features

and prioritize yeah

Vitalik Buterin: um one thing to add also is that there is a yeah like in the yep in the eip for changing gas costs for vertical trees there's a version of the proposal that um adds back the refunds in the case where the slot is uh the same at the end as a of the transaction as as it was at the beginning um so like there is an alternative that like work sort of works perfectly like it but but gets part of the benefit i guess would be interesting to compare both

with the status quo

Micah Zoltu: is that something we get as soon as we get virgo trees or is that something we'd have to add on top of vertical trees

Vitalik Buterin: um so there is um right now there's two of these proto eips one of the protoe ips only changes gas costs for reading and then there was another proto-ipa that changes the gas costs for writing which is uh that's right in my opinion we should do well and we would do eventually it's better it's more comprehensive um it kind of it puts things like storage edits and sending people eve under the same framework and that one has an extension for or

or always has a version in it for um making the gas costs um or refunding the gas when you when you reset something um so yeah it's like so basically it's it's in an extension

Moody Salem: so so with that um you still have to pay the loan costs as far as i understand

Vitalik Buterin: right you still have to pay the load costs um though like that can be shared across an entire transaction or across many operations

once

Micah Zoltu: once we have witnesses hypothetically um

the initial gas cost initial s load gas costs do we expect that's going to drop down significantly since everything's just going to witness

Vitalik Buterin: um i think it'll be about the same actually because witnesses are still a significant amount of data like the the gas costs have been increased like over the last like a few times over the last five years five years like part of that is the dos issue but part of that also is because of the witness sizes issues um the ones actually the one thing that will happen is actually this might even be important um is that the gas costs for accessing adjacent uh storage slots will uh cut decrease to i think the cur this the current suggestions are either

200 or 150 and so like you'll be able to pay the 2000 once and you'll have a pretty big chunk of the storage that you can use for all the transient stuff you want

um and

Tim Beiko: you've had your hand up for

a while

Ansgar Dietrichs: yeah i just wanted to add to this that i i would also say that basically the most important question for this erp would be first i think to answer like is this something we can make work for the existing storage mechanism um say with something like like vocal trees or is it some something that that will be an actual feature edition because if it's a feature edition which i can't

earp at least this i think we should really kind of take the time to go through all the alternatives um as we were talking about earlier i like that they were in the past were several alternatives and kind of really get this fight if it's something we completely add new because for me for example it's to me it seems like if it's completely transient um it would make more sense to have it be like a new type of memory rather than new type of storage because the whole kind of key value store stores kind of design of of the storage system is is really just designed that way to to be optimized for like databases and trees and whatever and none of this really is relevant for transients uh um kind of

storage so it seems like it would make more sense to have that just be like a continuous new type of memory block that's shared between contact unifications within the same protection so they're saying like i feel like we should really for this erp it should be really important to figure out can we just basically modify the existing storage mechanism to make this cheaper again or if it's a new thing really get the design for the new feature right and take the time for it

Martin Holst Swende: yeah and that's actually um so in this eve by alexey he does reference the point number seven uh shared memory and it says board from an early draft of a similar eve by holloman so i think i did write the similar iphones which

did not um so the difference was that it used to share memory share the memory which could be shared by different contracts so this you you could have a temporary storage and you can come back later in another call frame back to your same contract you can read what you wrote earlier but another variant would be to have a shared memory which you can write and then you can go executing another contract and that can read the same memory that you wrote to earlier which is another way to to yeah make life different for contractors and and there are i'm sure there are different and then we have the guests using stores with some new

variations yeah someone should really go through and figure out the different options we have

Moody Salem: so i think so it sounds like good it sounds like there's a couple follow-ups one one is like how impactful is this for like all smart contract developers um which i'm not sure what like evidence would be most convincing there like i could maybe uh get i guess some some feedback from other teams uh if that would be helpful um

and then the other one is like what other what is like the perf the ideal design for this for solving this problem and it might be memory instead of like the the key value storage design is that are those the

two

Micah Zoltu: i think for um metrics that would help evaluate even if if you have a prototype for like two versions one that has the temp uh transiting storage one that doesn't and you can then show at least four you know the next of uniswap the gas cost difference for doing the exact same overall thing is x um that alone i think provides some evidence like if you can show hey you

know it's going to cost us three times as much to build our next version of unit swap with without transient storage then that's that's meaningful um even if we don't have like a you know blanket from every app developer just having one dev developer who has done the research to show that this doesn't have a meaningful impact um when designing things would be valuable i mean the more the more data we can get the better of course

Moody Salem: uh for that particular i have written a test of a swap that uses the transient storage and a swap that just does it and the difference is like double the gas and

i guess i don't know exactly how to best share that stuff

Tim Beiko: um definitely linking it in the 8th magician's thread uh i don't know if you have uh maybe it's already there but that seems like somewhere where yeah we can just

uh yeah yeah i don't think it's

Danny Ryan: i mean writing or writing a report in there or linking it external with like not just unislop but a number of case studies that would be very compelling

okay i mean the the code is in public so oh right now yeah yeah so

Tim Beiko: uh yeah

at the very least if you can just share what you you know like shared on this call like high level like you know uh it saves about half the gas savings and and you know this is this is why that's valuable i think if there's other applications that can you know chime in similarly like if they think that it would help with another version of their application and and and provide like significant gas costs um yeah that's also great um yeah and i guess you know looking either at just like you know number of users or the amount of gas they use on mainnet or something like that like where um just to have a feeling for like how like that their scale and and the impact

they would have on the overall network would be good

Micah Zoltu: i suspect realistically the thing this the decision is likely to come down to whether or not we're going to get a solution to this for free with purple trees if we do then it seems like there's no point in spending the energy building this if vertical trees essentially solves this class of problems but if it doesn't then like martin said this is one of those things that is useful and valuable and we can probably i can imagine the core devs being convinced that it's worthwhile um so i don't know if how far away are we from knowing which vertical tree path we're going to go

down are we like years away or next next call

Vitalik Buterin: i feel like the spec for vocal trees hasn't really changed significantly for quite a while it's just like in an execution and testing

swag so yeah

why does it's not obvious to me why does vertical fees give us this for free

Vitalik Buterin: um because for the virgo tree ip includes these gas cost changes that make that like can be extended to add refunds and that make it easier to or that reduce gas costs for things like uh

getting many chunks of storage that are beside each other

Tim Beiko: and i guess that's kind of an assumption we have on the protocol dev site but like movie that's maybe also something that that can be valuable if you know like you can just say for unit swap specifically like how much you know how much better or how close does verbal tree get you to this similar gas savings that would be really good to know

Moody Salem: yeah i i think the one thing that like sparkle trees as far as i understand we'll never be able to solve is that you still have to load the original value like it's still going to impact parallelization because you don't you can't assume that

the value is going to be zero at the beginning and and gonna be thrown away at the end so it's like

the there's just like some oh

Vitalik Buterin: um i uh i posted the link in case anyone wants by the way

Moody Salem: i think there are some principle differences between what vertical trees helps with and like what this op code does like that just can't be fixed and then also like there may be refunds but like if there's the cap right but i think metallic said earlier that there wouldn't be a cap on these

Vitalik Buterin: right i think i mean there doesn't need to be a cap

yeah yeah

Moody Salem: and then one other thing go ahead one other thing with vertical trees is that if you write to a slot you can't you can't remove that from the tree as far as i understand um so like you're gonna have some additional leaf which has zero in it even though it's always gonna be zero

Micah Zoltu: if we start an end transaction at zero is that true don't do we actually write the vertical right true state if it stays zero

Vitalik Buterin: we do um well i think in the current spec like if it does if it was none before then it switches over from none to zero no but if it was your before then it

stayed which is zero to zero and there's no right

Micah Zoltu: i see so but but it does like create this kind of bloat that is unnecessary

Vitalik Buterin: so actually no though thinking out loud there might be arguments against doing refunds because if we do refunds and we do erc 4337 then there might be a possibility that gas tokens come back need to think through this more um right so even if there are no refunds um with the virgo tree gas costs the extra cost of using storage drops from being like 5 000 to being like 700 for a slot

Moody Salem: are you thinking in those first 63 slots

Vitalik Buterin: yeah exactly

Moody Salem: um that does prohibit the use of mappings for this transient storage which

which

Moody Salem: and then we and then our worst case axis like we have to make more accesses to see um i mean yeah maybe we could do mappings in that first 63 slots somehow but it's pretty it might be difficult

Vitalik Buterin: right i see what you mean the yeah the application gets uglier [Music] right i guess like the challenge with

all of this is that like it's adding yet another type of memory is a significant increase to the uh kind of total complexity of the execution layer and so if we can discover some way to get like either all of the benefits or even most of the benefits with uh tweaks to existing stuff that's something that probably should be explored first but if there isn't then maybe there isn't

Ansgar Dietrichs: so one thing that i would just want to point out because i think in general um um like one thing we could do better is all

could have just to be a little bit more kind of open in setting expectations for your piece and and in this specific case i would just say because the the kind of the the issue uh the the pm repo of course is called proposals to include the ap in shanghai um and so i would just say that right now i would probably say uh i would give this erp a 10 chance of actually ending up in shanghai um if it's because just because there's so still so much that would have to be to be done here it's like first of it's exploring the vertical direction and if it really turns out that this is just not sufficiently it doesn't get us sufficiently fine to that direction then really kind of explaining that very clearly and making sure that everyone

agrees that that's indeed the case that there's a need for something like this then really figuring out what the very best version of this looks like including having a lot of people kind of look over this and agreeing that this is the best flavor of this that we can do having everything prepared and ready and even then it kind of still depends on kind of there just being room in shanghai and so i would just basically say that like if this is really something that would be very important to try and get into some high for you then that would they think that is something that would require a lot of effort between now and even relatively soon from now uh to still have a chance um just just a bit transparent about that

Moody Salem: yeah that makes sense i agree i would

love just more like attention on it because i'm not really a client of and i feel very like out of my element trying to like figure out what is the best version of this so if anyone has any ideas to put on the thread like that would be great i feel bad i've already taken so much time in this meeting but um yeah i would i would love other ideas or other proposals to look at and [Music] just any guidance from devs i could definitely provide stuff from the smart contract side

Tim Beiko: i think i think that that makes a lot of sense and like yeah trying to again like we said

quantify the impact on the apps uh figure out the best design see the uh like pros and cons of vertical tries is probably the right next steps and um yeah the the speed and at which we do that definitely plays a big role in whether this this might make it into shanghai uh yeah right did you have one last comment on this as well

did you

say that

Tim Beiko: sorry what

did you call me i didn't hear

Tim Beiko: did you have a final comment on the eip

yeah

yeah i just uh i wanted to uh just check some my intuition about the parallelization it's it sounds to me

like not a big win because yeah you have that you know that property for the key load that it's always going to be zero but as soon as you hit your first s load like priority execution is going to serialize again am i missing something there or yeah i just want to understand how much of a value add that is versus just like a marginal one

Moody Salem: um well in the case of this like singleton design like you may not you may have two swaps on different pools that don't touch any of the same slots um but if if they're using these this like

transient storage and they are necessarily touching the same slots because they all use the same slots for accounting um so like up front you can't know whether they can be paralyzed or not even though the starting and ending value of those slots the starting value is always zero and the ending value doesn't matter so they should theoretically be able to be parallelized

okay i can look into it more cool okay

Tim Beiko: so yeah last thing on the agenda

that we had uh is quite the can of worms but basically shanghai planning um so uh andrew had had this comment like there is a lot of stuff already in the uh in the pm repo that's been proposed for shanghai um beyond all the eips that are directly in the repo there um there's also uh vertical tries which uh are kind of in a proto eip state and there's obviously also uh the beacon eth withdrawals post-merge um which which does not are not specified in an eip yet um so i guess yeah andrew you know you had a

comment about like you know we don't necessarily want to go over everything that's their proposed but uh getting your feel of what you know we want to prioritize for shanghai so i guess maybe we can start with you like did you have thoughts about approaching this or priorities or yeah

Andrew Ashikhmin: um well i think from everyone's team we are happy to work on the evm improvements um on this track from eep 3540 and 3670 3690 so so the evm object format that that will be a nice direction

um i also have a general um observation that we have like we have to two strategic directions probably the the vocal tree and limiting uh history availability um but for the and there might be some interesting interplay between the the term because for the vocal tree you probably need to move to the unhatched state as the primary format right so currently um

probably only aragon uses uh state with unhest keys as the primary format but during the given the gas reforms in the vocal tree you you probably need to move to that but it means that um things like snap sync in in gas have probably be relaxed to switch to the unhatched state and um also it but it also means that for say for that transition from uh for say guest nodes that are currently snap sync you need to be able to provide free

images um for from nodes that um have been seen from from genesis so for instance error nodes can help with that but so forth runs in from the hash state to unhealth state you need a population of nodes from genesis on the other hand if we pursue this direction with limited history availability we are actually moving away away from the possibility of genesis sync and we need to

kind of it's okay i think in the long run to to to do uh to limit history availability but probably if we do that uh we need to think carefully about uh how what are the mechanisms of of historical availability and what do we do in terms of the think that uh that the sink is based on on their unhashed state and maybe yeah so it's not uh well well thoughts through through yeah sorry about uh this but i see that this kind of interdependency between

history availability is uh sync from genesis and unhesh state for the local tree

Tim Beiko: right yeah thanks thanks for sharing i i agree it's always kind of the hardest when there's like these these big pieces of of like very applied r d works that that interplay with each other and and making sure we we kind of ship them in the right the right sequence um there's a comment in the chat from martin asking uh that he'd like to hear from vitalik about what he thinks the most important aligned things are

Vitalik Buterin: uh um hold on what's the um what are the most important and

aligned with future plans things um i feel like okay um history expiry is definitely i think a top priority um both um because it's just i mean like it's just so obviously needed for any kind of uh like any of the scalability paths that we're looking at whether it's the ap4488 or some or some version of sharding um and i saw well there is withdrawals i guess that got mentioned in the chat um i personally feel like might feel like withdrawals waiting six months is less harmful than history expiry waiting six

months given how much the scalability hinges on it um but i guess there's the question of like withdrawals are more a consensus layer thing and uh i mean history expiry is more of an execution layer thing so or is there even a trade-off between them given that totally different people will be working on them um other stuff oh um there is there is verkle tree prep um so that verbal tree prep i guess includes some of the gas cost changes and uh and a self-destruct fan those are probably the top that like i

yeah that i think are like important for a few well there's shorting stuff as well but sharding stuff is still kind of under r d and so am in its own track like that stuff seems the most important for future plans um okay yes yes so the withdrawals might may not be that minimal for el um i don't know i i stands by my comments that was sure all's waiting for six months less is less bad than the history expiry waiting another six months though i know what that's

Danny Ryan: right but history expiry we can and probably should be paralyzing right now because that's related to a hard fork

Vitalik Buterin: i agree yeah like i think a lot of this stuff actually like can be paralyzed quite a bit

what are some

Micah Zoltu: i mean so regarding parallelization that is true only if you're all the client teams have different sets of people who would be working on hard fork stuff versus um history

Danny Ryan: right i mean parallel i think they're poor because not a lot of it's also like design and interfacing with community and like setting expectations and stuff there are technical things to do certainly but for sure there are like softer things that should be paralyzed today

Tim Beiko: yeah it's almost like for 444 the the consensus change is like the final thing you actually do right you want the

network to be in a spot where we can operate without history being fetched over the peer-to-peer layer and there are kind of options available and then we just shut it off at the peer-to-peer day or once you know that that's been done but yes most of the work for that one can happen outside of consensus changes and there are people working on it uh so it is already being paralyzed

Vitalik Buterin: um on the vertical stuff um i think um like it's okay to do like it's okay to if virgo trees get delayed more more than like say yeah four four four four and scaling critical

stuff gets delayed but we do need to be proactive and early on it because there are a couple of uh backwards compatibility breaking things in there one of them is the gas cost for reading code and the other is the self-destruct ban um so like i just uh want those things to you know not be a yes uh one of those surprises where everyone suddenly freaks out about the need for half for um half a year of research two months before we were hoping it would get in um um the i there i know there has been some proactive work on it it would just be nice if there is a more proactive

um work on it um oh i see the the question of uh gas cost changes before vertical right right okay so this was a yeah like basically the there was a proposal made to have gas cost changes needed for virgo trees go in before the vertical hard fork i guess it's not strictly important for that um for that to happen like like it's definitely totally fine for everything to happen at the same time as well i'm actually i think it might have been dank red who suggested that multi-step road map so he would be yeah better better to give the

rationale for the forgiving gas cost

Dankrad Feist: well my main reason is like um that's so the reason why i wanted to suggest that is that i think like every day that you don't like you you know what the that what the future of gas schedule should roughly look like and every day that is further away from that um like you get more uh contracts that rely on current assumptions deployed so that's my main reasoning for it but i agree so like also from my viewpoint when i looked at this further i actually think many things are not that far from our desired gas schedule so my preference would actually be to

focus on the self-destruct like that's something that uh i think we should get out of the way earlier

one thing and i

Vitalik Buterin: i do think that like the one big remaining difference between current gas costs and vertical gas costs is the per chunk access of code right and like yes there are like there are some exceptional cases where the ipa would get more than a factor of five increase right

Dankrad Feist: yes yeah yeah i know but that that one is also very hard to just do on its own like if you only do that right none of the things that make it cheaper it will be very hard to get that accepted i think yeah

Vitalik Buterin: right agree that's fair like it would just add a lot of transition complexity and we might as well just like move to the entire to the right event schema um all

at the same time

um and scared you have your hand up i know and there's been a ton of comments in the chats in barrels so yeah so i'll make sure

Ansgar Dietrichs: yeah i was just um briefly i would prefer to ask um in general like do we think like would we prefer a shanghai that is slimmer but comes earlier um or i mean i think we'll agree that history kind of um uh like the 444 uh yeah but um it's important but that again that doesn't need hard forks so so we can just do that whenever um but like for the hard fork or the changes in the hard fork do

we prefer a slimmer hard fork that can arrive sooner or do we we basically want to have a hard fork that has at least as many of the earpieces we can recently fit into a hard fork and maybe takes a couple months longer to to arrive because i think that's really

do i mean

Vitalik Buterin: do we need to do we need to decide now is the other question like might we have more information in three months

Tim Beiko: but i think there's a i think there's probably a trade-off between do we include stuff that's mostly finalized and like you know pretty straightforward um or do we include things that are like more fundamental changes to how the

network operates um because we we do have there was this comment earlier in the chat about like the last feature fork we had was berlin and and we do have a lot of eips that are basically ready um that are you know you could say like standard eips that we kind of know how to do um and then we have things obviously like vertical trees uh historic expiry those are like much bigger overhauls um so i i don't know if it's a question of like how many eips you put in but maybe uh there's an argument for like putting this stuff that's like pretty well specified pretty minor um and for example yes there's bls that's

there um there's a ton of other ones that have been pending for over a year um yeah so i i think there can be an argument and then you know in parallel obviously we have we have people working on on history expiry we have people working on vertical trees but it's like maybe it's it's simplest to just not not consider those efforts for shanghai and and just try to to get stuff that's pretty well specified out and not like a massive uh kind of change um include and i guess yeah i was gonna say sorry the one thing i think might actually be like a a non-trivial change is the mechanism by which we credit beacon chain withdrawals

into the evm there's nothing like this that exists but it's it's not that it's like super complicated but it's it's it's very new and that

alone

Danny Ryan: there is something like it it's the issuance the coinbase is kind of similar

right but the um i i personally if

Danny Ryan: in my intuition is that the value of this fork is one to get withdrawals out and to to as a pressure relief valve on all the on many of the more minor uh evm and user related uh features and i think that in your intuition that

yes you have this thing that kind of does fundamentally change something that's withdrawals and maybe we shouldn't have three other things that fundamentally change something and you know hit that fundamental change and then a bunch of pressure relief things for users

Tim Beiko: yeah i i agree with that uh andrew

Andrew Ashikhmin: uh yes sorry i wasn't clear earlier i just wanted to say that if we do history expiry before before the vocal tree then we actually might hinder the vocal tree transition because for local tree we probably need a population of nodes seen from genesis and if we do history expiry that might be problematic

Vitalik Buterin: can you elaborate why we would need a population of notes from genesis for the

virtual tree switch uh because frogs currently there are many guest notes that are synced during using gether snapsync and there they don't have pre-images so all the keys are hashed and they for them to enhance the keys they need pre-images um oh i see him um so

Vitalik Buterin: so they can have the full

Dankrad Feist: how what's the size of the sticker set like only keys is probably not that huge

is it

Andrew Ashikhmin: it's fine so like uh because arygon knows all aragon knows i think from from genesis we can provide them relatively easy what i'm saying is that if we like pursue this history expiry path then it will be more and more problematic to have a population of notes and from genesis and then this transition will be more problematic but in terms of the volume of the pre-images it shouldn't be a problem at the moment

Dankrad Feist: but i mean just provide that as a

torrent

Andrew Ashikhmin: um yeah but still like if uh well how reliable is that so i'm saying like currently before we do history expiry we can do that relatively easy

later it will be more problematic

Dankrad Feist: wait but i'm not sure but i mean what you're saying is that your suggestion for recompeting those keys is to replay the whole history because only when you play the history you know all the keys right

Andrew Ashikhmin: uh right right but but we already have a a sizable population of aragon nodes that already have our archive knows and have that information

Dankrad Feist: but like i i still i i don't like i'm i mean i would need to look into this

but uh but you're like if the solution to the missing keys is reap like every node replace all that's old history again to retrieve

Andrew Ashikhmin: no no no so snap synced guest notes can say ask either full archive guest notes or aragon nodes to provide those keys the snap sync knows they don't have to replace everything from scratch they only need to acquire the

pre-images

Dankrad Feist: right or even simpler they you just get a torrent file of a few hundred megabytes or something that has the keys

Andrew Ashikhmin: well it's a moving target so like a torrent it's possible and we are

developing something like a torrent-based solution for

aragon pre-images

Martin Holst Swende: can be cryptographically verified when we receive them torrents yeah there's no cryptographic tie to a torrent we don't have a header that says what is the torrent

id

Dankrad Feist: yeah but the torrent only contains the pre-images so you can like cryptographically verify the whole file once you have it yeah once again there's no trust there's no trust enough torrent or anything it's only a way to actually get those keys

Péter Szilágyi: i mean you don't really need to verify anything you can just download the keys from wherever and just patch them and if you don't have that image yet

i mean yeah there's not much to verify although

Dankrad Feist: yes yeah i agree i agree yeah sort of like any source where you can download this seems seems like a solution to that

Péter Szilágyi: yeah but with the torrent it will always be outdated so you will always miss the most recent number of

pre-images

Micah Zoltu: i believe the general strategy idea with um torrance as a solution is you would just do like a torrent every six months and um wait why would there be a new

tolerance

Dankrad Feist: there's no new torrent once you have made the transition this is this is only alt keys that we're talking about right

from the point in time when the worker transition happened there's no more keys added to this and even before like so the problem seems to be that some clients clients currently don't store those keys like we could make an upgrade now that starts storing all those keys right

Péter Szilágyi: so storing keys you can store the keys for the blocks that you process but if you do a fresh sync you will not have those keys because those keys are not part of the network there's no way to repeat those keys currently i cannot sing them

Dankrad Feist: right i agree but i'm the only thing i'm saying is that this

doesn't have to be like a super instant process that right now i need the torrent with all the keys right this can be like a like say two weeks before the before the vocal transition every client starts locally building up all the uh all the keys that they encounter and then the torrent would all only need the all the keys as of two weeks ago and there would never have to be an update to the torrent and

from my perspective this does not seem like a major argument then like in terms of the ordering that we need to do the worker before history i don't i don't see that

Tim Beiko: yeah and i guess this kind of comes back to like for shanghai do we do we want to use it as more like a pressure release mechanism as these things are getting fleshed out and and prototyped in parallel and um yeah there there is another comment about like the timelines uh in in the in the chat i think

we probably don't want to like feel like we have to rush shanghai right after the merge uh given the amount of like rush or like pressure there is around the merge already um we obviously want to ship it you know after but like i i don't think there's like anything in in shanghai that um requires kind of a massive level of urgency um and and so it's kind of hard to say like exactly when it would land given we're not even sure when when the merge will be on main net but um i think we should try to you know obviously have these discussions about clarifying what was the scope of it what do we want

and gradually we will get kind of a better picture for it but um yeah i i wouldn't rush to say like we need to ship these things you know three months after the merger or something like that um and scar you you have your hand up

Ansgar Dietrichs: yeah i just wanted to say that maybe one thing again that we should definitely should decide today of course but that at least i think would be helpful to keep talking about a little bit over the next few calls is whether we might want to just commit on having two future forks the shanghai and one after it and then the next topical fork that i assume would be vertical tree related or whatever maybe else is ready just because i think western line was with london one of the

problems was that it basically really felt like the last feature fork for the next 18 to 24 months and so a lot of eps really wanted to get in and then we decided not to to put some in and say yeah but you can get into the november park and then we of course later on just silently decided to not have a feature for in november and so i just feel like basically managing expectations by just being very upfront about okay this is one chance to get your epa but we are already committing to having another feature for i don't know four to six months later um so so that that it's it's okay to basically only go ahead with shanghai with like a smaller similar set of simple things that are already ready relatively soon enough to merge or something i think that would really

simplify things i'm not saying we should do that necessarily but i think we should at least consider that option and potentially commit to doing that relatively early on in the process

Tim Beiko: and i guess the argument there is if you have two small two small forks you can kind of do them quickly and and like i guess yeah maybe the other way to put this is like if you have two small forks you do delay you know vertical tries for example by an extra three to six months at least um so is there an argument of like instead of just having these two small you just make one kind of medium or large hard fork and and that's it like and then the next one is

is more of a um you know protocol level change rather than like application level change if that makes sense yeah because like i i guess my fear is like if we do something like you commit the two future forks you delay the kind of longer term kind of protocol research but then it's also maybe the stuff that's in the second fork wasn't like actually that important because if it was then it would have been in the first fort um so that's yeah i'm yeah i'm not sure how we how we just make sure that like we're we're not just creating a delay and and have

uh yeah and and delaying the stuff that's really important for the protocol uh because we feel there's just too many things and and it's like an excuse not to just prioritize a bit better um obviously yeah it's not like the last conversation we have about this and and we'll we'll need to have more in in the coming uh the coming calls i think one thing though uh that for shanghai is uh for people listening like if you do have an eip that you want to propose for shanghai

it should probably happen sooner rather than later um even you know like today it's going to have your comments about like it's unlikely or it's not like yeah it's definitely not a certainty that like 1153 makes it in and and i think given the amount of stuff that's already there that's like scoped out and whatnot like we probably don't have a ton of bandwidth for for new proposals to come in and um and if so they'd probably need to be presented soon and and you know kind of show or yeah articulate why they're more uh urgent in a way than than what's already being there so yeah i think if if people have have ideas or proposals for shanghai they should probably bring them in uh quite soon so that we can

have at least like a a rough final list of stuff to consider uh in in the coming months or so

Martin Holst Swende: yeah i'm a bit surprised like half a year ago or a year ago there was a large group of people who really pushed for a 30-74 but i haven't heard about that uh since then i'm curious

of system i think like clients may be too polite to keep bringing it up okay i

Danny Ryan: i think that like i think that the 30-74 crew realized that the merge needed to happen before the 30-74 conversation could uh continue

all right

Ansgar Dietrichs: yeah maybe just briefly on the status of 3074 um so basically just

because it keeps conventional chat and everything i i just think that um we as the team just realized that a lot of people are having concerns and of course no change they should ever get accepted into the protocol while a lot of people still have concerns and so we're just basically waiting for a moment in time that is sufficiently kind of peaceful that that we have some time to try and convince people once more and also of course we are in the background kind of looking into the ap maybe things we can change to make it um to address some of the concerns so it's definitely something with that we still want to try and bring to mainnet at some point if there's an opportunity but um only dependent on us actually being able to convince people of course but

it's not it's not that it's just waiting for for us to calm down and and maybe have have to have an opportunity to to look into

it again

Lightclient: we're also available to discuss any concerns with 3074 with people i know there are still people who don't think 3074 is um is safe or they have other concerns about it and we're available to to discuss it we i've just stopped talking about it incessantly and the calls because there's other important things to discuss cool

we would really like to propose 30 74 for shanghai

Tim Beiko: yes and it is on the list right like and oh by the way i guess if people want to see the list it's not perfect but uh the issues repo of the ethereum slash pm uh yeah the issues linked sorry of the ethereum pm repo has everything i think that's being proposed the only thing that's missing from it is basically beacon eth withdrawals because there's no there's no formal eip yet and also i think the evm object format eip evm 3540 is is in that list and there's a couple companion eips which i think might not be in um

um but yeah if you want to get like a rough feel for like all the stuff that that has been proposed for shanghai that's the place to look um and then in today's agenda uh andrew also recompiled the list there and has uh has the beacon east withdrawals there um yeah oh and verko tries also yeah doesn't have a specific eips they're just portal eips and but that's where people should go nook and if people want to propose something for shanghai uh to just open an issue there um like you can literally copy paste any of the ones that's already open and we'll make sure to add it in one of the the upcoming calls um

anyone had anything else they wanted to cover either about shanghai or um the merge or any other topic

sure

Greg Colvin: yeah i also wanted to support the eof related ones um the evm work has been sort of stalled for a long time and those are are just a fundamental basis for making for making further progress and i just i don't want to see those delayed any more than necessary the the team has been doing really good work on that and they're pretty much ready to go i think

Tim Beiko: yeah i agree there's been a ton of really good work and like iterations on uh the evm eips which led to this this series and it would be really nice to see them see them get deployed

do we so

Lightclient: think simply go ahead matt i just want to say also on eof i think that there are interesting longer term proposals that do rely on having the ability of having different types of um contracts in in the evm and so the sooner that we can get the base version of eof onto mainnet the sooner we can start to really think about you know future things that can be built on top of it

Micah Zoltu: do we have a

so the we talked about having like one or two um hard forks around shanghai is it is there anyone any reason we can't commit to all those little easy things like the uf ones and bls and just like the the stuff that we sounds like everybody kind of agrees is easy non-contentious we just need to get it in the pressure release valve stuff is that going into shanghai no matter whether shanghai is big or small

Tim Beiko: so the reason i don't think we want to commit this because there's probably like 10 of them and i can see a world where like we just do five you know um i i i don't know it's never accurate but like i think and and i also want to let people you know give people time to like digest

this call and and and discuss things async but like assuming we did want to go like the the pressure release route i don't think we can include everything that's like in the backlog and um and so you don't want to tell people like oh yeah if your eep's been pending for two years it's uh it's uh it's gonna be in

Ansgar Dietrichs: um just for the record i think even something like eof which i think everyone uh that is looking to it is excited about i'm certainly quite

excited about it but i think even that has like sufficiently big long-term implications to the evm that i think it would be important that everyone basically is familiar with it and we do spend some time on all codes talking about the implications and if we are comfortable with it and i would hate for this to basically happen so late in the pro process of the hard work that for some reason then maybe concerns can't be addressed in time or something and then it would be kicked out of the the uh the fog so i think that's something that we should also do sufficiently long before the before the heart folks that it yeah doesn't pose a risk

right

Tim Beiko: oh and one last thing uh

um related to hard forks but not shanghai uh the consensus layer folks have found a name for their merge hard forks or the hard fork at which they basically set uh the the ttd and hard code it um if we want uh yeah basically if we want suggestions for that we should definitely not call that thing shanghai given the amount of of attention that there's been already uh but basically the release of uh yeah the release of uh execution clients uh that basically supports the transition um and

marius says the merge is good enough i personally disagree i like the idea that the merge is the whole process um and you know each of the client releases have have upgrades but we can discuss that uh async um but yeah we i the thing i do feel strongly about is we definitely should not call that thing shanghai i think there's enough like consensus around shanghai being the first feature fork after dinner after the merge anything else anybody wanted to bring up okay

well yeah thanks everybody um i will see you all in two weeks and there is the consensus layer call next thursday to discuss merge stuff

thank you have a nice weekend okay thank you to you thanks everyone bye everyone [Music] so [Music] [Music]

[Music] so [Music] [Music]

[Applause] [Music] you [Music]

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