Ethereum Core Devs Meeting #125 [10-29-2021]

uh welcome to awkward devs one two five um a couple things on the agenda today uh merge updates uh updates on aero glacier and then ensgar has an eip which would modify the eip1559 mechanism to better account for missed slots after the merge and then finally uh dankrod and guillaume are here to chat about vertical tries and the general stateless roadmap um and we could kind of get through the first three things and then give bankrupt and guillaume uh the rest of the call to go over uh their stuff um yeah so first any client team want to share updates about the merge where things are at any issues they've encountered uh i can start so [Music] we're currently looking into merging all the code from amphora from from the interop until now nothing major came up i've also started setting up a server for merge fuss and um m fuzzing uh gas right now um but i'll add some other other execution layer clients to it for those who don't know merge first is a differential fuzzer that basically just calls the engine api of two different clients and sees if they do exactly the same thing um yeah so that's that's our update did you find anything with the fuzzer so far uh i we found something in the synchronization call in the sync code that was not final yet um uh nothing really major awesome uh merrick i think you were about to start speaking uh yeah we continue cleaning up our merch code or we set up all consensus client in our infrastructure with nethermind as executioner engine of course uh we are in contact with nimbus team because something not working with nimbus and nevermind uh yeah it looks like we are working after uh the mario's test and that is all i think from another mindset thanks for sharing um i see andrew you're here and yet it's from aragon um no not yet okay um i thought it was someone in the discords i don't think they had their real name but they were starting to implement the merge and asking a bunch of questions um yeah um oh danny you're gonna say i can yeah i can give an update on um we are primarily make io myself and some others are quickly closing in on uh the final updates to compensator specs extrusion layer specs and the engine api that came out of amphora um i might do a pre-release later today and point to a commit on each that kind of gives you pretty much what's happening but we likely will finish more on monday there's a little bit more work to patch up between now and then but but very close and then um that would be breaking with respect to pithos and we would start kind of a nude wave of testnet targets in november got it and just for context if you don't have the context mo it's largely similarly structured uh there's probably a few edge cases that are patched up and generally simplifications uh and reductions in the engine api so it's not not throwing a ton of out or anything like that got it um is anyone from basu on the car hey justin yeah awesome nice um yeah we don't really have any updates right now um we're cruising along we're merging in all of the code from uh the interop exercise um that's that's still in progress so uh nothing uh nothing new or major to report okay that's all gary by the way so i don't have any hard details on it no worries um cool so any anything else anyone wanted to discuss about the merge okay um next up is just aero glacier so on the last call we kind of decided for a block number and uh and a delay for the difficulty bomb um i guess i'm curious to see how how far along our clients in implementing this and like how realistic is it to have a release in the next week from client teams with this just so we could announce it about a month in advance um yeah i guess anyone from any client team want to go first so we haven't done it yet but of course we can release it in the next week it should be very very easy so yeah okay so next week is possible um [Music] mario is your first on my screen so guess yeah martin implemented it we've merged into the code and our next release should contain it i'm not sure if we're going to do a release next week but i think so so yeah uh aragon uh yeah we haven't done it yet but we should be able to do it next week and uh should be yeah probably we'll release it next week okay cool and uh base you uh same story here we haven't implemented it but we have a quarterly quarterly release scheduled uh in the next week uh we'll likely have it included there awesome um yeah go ahead yeah i just want to as far as i know um there are new difficult tests uh in the test repo so when you implement it you can check out the new tests as well anything else on aero glacier um and cool so i guess for people listening uh and who are looking to like plan their upgrade uh the fork block is gonna happen uh oh the fork is gonna happen at block 13 million seven seven three zero zero zero um that's expected to hit around december eighth um so a bit more than a month from now um and one thing that would also be useful i i guess only get has it implemented now but if somebody can just share the four cache like the 2124 hash so we can add it to the spec that would be great sorry what has uh the the kind of fork identifier fork id yes yeah it's in my pr uh i can paste it on the vm pm awesome thanks um cool anything else on aero glacier okay uh if not uh then ensgar has been working on an eip which uh would uh basically modify eip1559's mechanism around the merge so that we can better account for missed slots in how we update the base fee uh i think he literally finished a draft yesterday um do you want to take a couple minutes and start to kind of walk us through how this changes things and why this might be important to to do for the merge should i uh shine a screen for that or just talk about it yeah if you have anything to share go for it i mean you can yeah just maybe because they're like two to three graphs and then that might be nice to see uh can you see my screen yes okay awesome yeah so so basically the uh the situation is just that um with 1559 right now the the base view of course looks at the gas used in the parent block to determine whether the place we should grab or go down uh and with um with the merch uh we'll have these usually regular slots every 12 seconds but then if there's a missed slot of course that's that basically means that there's like a 24 second window and just because transactions continue to accumulate right they could basically always expect a 24 um seconds a block basically to have on average twice as many transactions so missed slots would usually result in little base fee spikes and um so the question was just a is this a big problem was it just a small annoyance and then b is there something small we could do to to to mitigate that and so basically this is just one proposal so the question is just basically the actions we could take you would be do this do nothing at all do something else um or just uh wait wait wait for shanghai basically um yes so so the the approach here is relatively simple it's just because like the kind of the core problem here is that we don't really account for block times uh it adds like a a simple block based rule to the to the calculation uh important to note that under proof of stake there's no way for for block purposes to manipulate the block time because it's um like it's always enforced on the beacon chain side that the like every slug only has one valid um timestamp that it could use so there's no there's no wiggle room or anything so it's really like a very simple way similar it's basically and this has the same properties as the slot number but it's easily accessible from the execution side um and so for yeah first why why why could it be kind of like important to do that with the merge so it's um for one of course it's a little bit annoying um with these with the space free spikes i think that's the least of the problems um the second thing that is a little bit more important i think is that uh basically every lost slot is like a permanent lost throughput for the chain so if we if basically the slot dismissed that means that we just have 50 million or whatever guys we have in the blog and just less of overall throughput and one i think i would argue that this is just not desirable because um when we reset these throughput targets to reach them or to have to stay below them but also more importantly this kind of like gives a more clear incentive for a denial service attack against proposals um so just because we don't have yet like these um secret uh selections um there are some concerns that potentially what was this could be anomalized and targeted in our service attacks and in the under the current situations every bulk deposit that you can basically stop from from producing a block means the throughput of the chain goes down by that pokemon um which kind of increases the incentive and if we could mitigate that of course that would kind of like make you know our service attacks less uh useful for attackers which would be really nice and then the last concern um is uh whatever we i'm describing here and they like degradation during consensus issues so um i mean of course hopefully this will never become relevant but if we ever have situations where like a large number of validity goes offline at the same time and approved work right now this is really quickly self-healing where basically you just um they have the difficulty adjustment and so while the uh block times go up for a little while they'll they come back down um quite soon and so the throughput is only like um impacted for a very short time and if we stake uh we still have a self-healing mechanism but it could take much longer right like especially if it's less than a third so the same change still finalizes uh it could take literal months even if we uh like below the finalization threshold and we have difficult and inactivity leaks it could still like be weak so basically like uh and of course we could then start to manually intervene and just increase the gas limit but again also this manual attack intervention would take quite some time so so with much more permanent impacts to the throughput of the chain and that is physically during times where the stress on the chain is already at the highest because like we we have these consensus right so so not only do we have like a period where there will be more more activity because people will want to react to the consensus issue but it's also reduced throughput which is just like not ideal for the stability of the chain and so obviously i think it would be important to do this at the point of the merge already so we don't have a period of proof of stake without without this adjustment um the specification that i proposed was like really motivated to be as minimal as possible so this is kind of taking the erp 1559 uh update rule and just basically it's really if you look at it it's just basically it changes like five lines of code or something it adds like these two constants just block them target and basically a maximum of what we want to allow um so basically this this just means that we basically allow up to 95 of a block to be used as basically like a um as a target so say right now with the elasticity of two basically this would mean that like um we basically allow the the the glass tiger to go up to 1.9 times uh the block um um and then the only changes in here is that we have this extra um sorry it's extra line that that does this adjusted um guest target calculation and then uses it down here but it's yeah so this is basically like four five lines of change so it's really minimal so it shouldn't impact the much work too much it what it does do is though it means that now the basic operation does depend on the grandparent of a block as well not only on parent because we need to access its timestamp so that is one more block that you need to have available to validate the header that is a significant change um right and that's basically uh that's basically that the one important thing is to maybe briefly talk about limitations um so because basically in the account in this minimal change all you can do is really kind of account for more or less for one missed slot but if as soon as you have two or three slot in a row basically you you just can't because we only have a local assistance you have two there's just no way of kind of like recovering all these transactions and so as you can as you can see i put like a little graph in here so basically like with the depending on the percentage of offline poker process the throughput of course does go down um the blue line would be what we have today and then of course um like what up first would be like for the brown line here um so basically like as you can see we have a much more gradual decline initially which is exactly what we need for dust protection right so basically there's almost no decline initially and then even even in situations where like 20 30 40 percent uh of what proposes offline we still have like much less degradation than we would usually have um but of course it's it's not perfect and so like the last thing is where maybe i would want some input is there some extension so you could you could make this much better basically much much less degradation until until you go down way way further but those would require slightly more involved changes so this would add one header element um or alternatively could also do this by accessing not only the parent and the grandparent of the book but like the last 10 15 20 30 and ancestors but that also seems like a more more kind of like substantive change and this year would be um if we were to increase the elasticity of a block from two to two point five or three or something that would also help quite a bit i would argue this might actually be feasible just because under proof of stake we have these 12 second block times as a minimum and so it's already much reduced stress right now we could have block times of three seconds if we basically if the randomness of proof of work turns out against us and so the strain is already much reduced and approved work so i think there might be a case to do this as well but again the objective was to keep the change as minimum as possible so these are optional um um right i think that's basically all and so then just basically for context it's it's really just because as then you were saying we kind of uh the the kind of the specs for the execution side for both execution side and competitive side kind of are supposed to be more this final um very soon so if we really want to consider this uh for the merge which that would be the call we'd have to make very soon um yeah and so feedback would be appreciated that's all i have a question okay uh yeah i had a bit of a hard time understanding what you meant by denial of service um uh yeah how how it improves the situation against denial of service and as i understand it and please correct me if i'm wrong like what if there is um [Music] some transactions that for whatever reason causes a large majority of the nodes to process the blocks very slowly so the block time increases uh i think it i mean it can be seen as if like 50 of the seeders go up line um now if i understood you correctly the the what would happen is that the base b would go down and the actual transactions included in the blocks would go up uh to yeah basically the top miners go down and block times double then you would have double the amount of transactions in the block so it feels like that would make the denial service attack worse now did i misunderstand something um so i think that's right exactly that's it so basically that they're truly service problems one is as you're saying like transactions that take a long time to execute but the other one is to target specific block proposals so you can like there are some worries that you can just basically based on um message relay patterns you can you can de-anonymize the like the appeared addresses behind specific validators and then because it's known in advance when it's their turn to produce a block you could like specifically target them just before that time and make them go offline for a short amount of time so that they are not able to to produce a block um right so the context which you are discussing is the like easter world the post merge um right so in the context of the pre-merge world what i said do does it make sense or did they still misunderstand something right so um well this was more small thing just it would not actually decrease basically it would just stop the basically from increasing um when the block be like if say like basically only only every other um blog proposal um actually uh well okay if you're talking about proof work of course right if basically the block times start going up um then that would basically mean that the the blocks were allowed to be more than half full on average um that does mean indeed that if we have a proof of work attack similar to like this shanghai attacks where we um just have like very slow to process blocks um that that would basically mean that the well it wouldn't actually change much it would just basically mean that like the new equilibrium would be a little bit different instead of basically having say i don't know if if as you were saying your example usually like say the block times would double now they would basically go up 4x but every bug would be twice as full on average it would still like reach a new equilibrium where basically um reach a new equilibrium though i mean if if if the throughput as in you know gas per second while gas per block should be constant and the nodes cannot i mean wouldn't at least like form some kind of cycle where the block gets slower and so we have more transactions go into it and that makes it even slower and more transactional when ended like some kind of self-reinforcing cycle and the nice thing is that we just that that can't ever happen because we have this strict upper bound of the elasticity right so right now we have like a 2x maximum size and we just can't go beyond that so even if we end up with 2x the box size that's that's the limit um so so basically there is no no kind of room for for any of the for the cycle if you were to completely remove the scissors yeah you're right that this all right so so it would do that to a point and then there would be a steep and there's a much more steep drop than at some point right but but again i would i like um basically i would say that that's what we have the gas limit adjustment mechanism for right like i mean similar to what happened during the function high techs that in that scenario you would just basically advise miners to uh reduce the um the gas limit right but i wasn't really sure how your proposal uh interacted with the gas limit if it did um no no it does it does not in any way change the gas limit and i think that it's important because indeed like the test limit is this is irrelevant for security considerations so it just acts within the gas limit it just basically sets the gas target instead of always targeting half full blocks it allows more than half of blocks to be targeted um if bugs basically come in slower than expected so so that it balances out but it never changes the gas limit um yeah right and yeah okay then that i think i'll leave it my concern i think [Music] that was the part i missed them yeah i have a simple question why can't we iterate uh over this is slots treat them as an empty block and just re use already existing formula and with each iteration apply this formula to compute the base video of the block that finally exists so do you mean basically um yeah okay so so if we just basically insert artificial empty blocks um into missed slots the problem is that that kind of um set basically just sends it incorrect signals would be because an empty block would signal that there's um no demand um so so that will basically lower the um the base fee um and but but it would end up resulting more or less in the same situation because you'd lower the base fee before the next block and then in the next block you because it would on average be twice as full you increase it back up but that just basically means that we have the incorrect base fee it would end up in almost the same situation as in my proposal just that these the slot after in the mist slot would just basically have artificially true low base v and so too much extraction by the mine like um p extraction by the miner and but it would honestly it just feels more complex doing it that way because you still need some scheme like what happens if several blocks are missing and so on and just breaking this one into one block correspondence seems wrong right yeah i also would say that these artificial blocks would be more complex um but i mean otherwise i mean the comment was i think it makes sense right because like the the effect would more or less be the same um it just yeah again my concern is just that we changed the logic and it's it's it's from some certain points it's more complex than use already existing logic just apply it like in and specifically but inserting empty blocks is also changing the logic right no we don't need to insert those blocks at all so we just need to apply this formula like 10 times if we if we have 10 slots missed before this block right but the length of the problem there is that basically that means that the base fee goes down in situation where it should not go down that that is the main problem and especially if you do it iteratively if you don't only don't don't know i don't think that's true i think it's equivalent right more or less like i think it's equivalent because i don't think that's right yeah so i don't think that is the argument it's purely about complexity which one we consider more complex i feel like this is the better solution i mean both are similar complexity pretty much if you do the diff and time stamp mod slot time and then run a formula that number of times versus doing a slightly different formula i think it's pretty similar to complexity i'm not arguing for one right here but the execution client doesn't have the slot numbers right no you have that's the time stamp that's why i said mod plot time so so right block time at target is proxy in here for slot time right right okay that makes sense yeah maybe if these two formulas are kind of equivalent down yeah cool i thought that this like a bit uh the mechanism that you have proposed is just a bit different from what i've been thinking about it why is parent why is parent block time why why are we doing that like using a grandparent instead of just the diff between current block and parent um just because like the way we like the basic calculation just happens when we validate the uh the base fee in the block but that just means we have to look at the uh the situation in the parent and then so um within that we need the block time of the parent the block time of the parent is the difference between its grandparent and the parent right because because the base fees never adjusted for the block itself it's always suggested for the next book [Music] what would break if we just make it based on the time delta between the black and the parent instead because like i guess the way that i philosophically think about this is that i think of the beast the update as being two separate updates there's a yeah always uh positive update as a result of guests being consumed and up and always negative uh update as a result of time passage so like in theory it shouldn't matter if the order of the two gets flipped right that's a good point i'd have to think about it um yeah who happened if yeah there is also the like miss slots uh before the parent block like miss loss between the grandparents and the parents like no matter how you do it like every single span of two blocks gets or every single span between two blocks gets counted once right so it should be fine anyway yeah yeah that generally sounds possible um just again i think that yeah just have to have to think about it briefly just to make sure that there's no even no small within a block inconsistencies where like the basically in a block is not the one it should be and then even if it like basically this returns to the correct one in the next clock ideally you you never want to um individual box where the miner um basically uh has it too too low or too high basically does the execution client know the slot time currently no it could i mean it knows the time stamp and the timestamp is ensured to be congruous with slot time by the consensus player but uh it does not know the kind of like beacon genesis time and the slots per second which if it did if that was just baked deeply into the configuration the execution client could calculate plot time based on timestamp i would be a little hesitant to bake that in the configuration of the execution client because one can imagine a point in the future where we want to change that and having change in both yeah it doesn't seem super valuable to be in there although if you look at this pr the vip block time target is essentially a proxy for slots per second and so if it makes it into this eip then it is making its way into the configuration there yeah that that feels well you basically do need this if you ever want to do anything about miss thoughts on the execution side yeah there's no way of telling if you have a mistake yeah i agree that it's necessary it just changes this from oh this is a nice clean simple solution to now we're bleeding consensus layer logic into the execution client and that that's what makes me feel less positive about it that's all i guess it doesn't have to be that way can't we just simply say the gas target is per second rather than per per block and then this content constant would disappear right yeah yeah that means it wouldn't need an update if the slot time change in the future i mean we could argue it right now it doesn't need that update anyway it's just that we would still be written as a quotient right yeah i guess like one one nice uh benefit of making it entirely timestamp based is that if we do change this a lot time in the future we don't need to do anything else to uh ensure that capacity stays the same across the change but if we do it per second it's just basically we still it's still baked in it's just hidden a little bit more because then it's in the elasticity multiplier because right now it would be 2 and then would be 24 and the 24 would just come from but the point is fundamentally fundamentally the constant should be per second right i mean it's a like if we for some reason decided that like um poor pos has to be two times slower for some reason then we would increase it by a factor of two so i would argue that the fundamental dimension of the constant is gas per second but the it's the elasticity that you want on a per second basis or right now i don't see what it has to do with the elasticity because the the blocks are in the past and then the you still have future blocks coming right like so imagine you missed three blocks and you have like you know a three times bigger block than because your elasticity gives it to you you still need to be able to process that three times bigger blocks before the next block which you assume won't be missed arrives so it's like you can't accumulate all the past misses that you've had so it i think that if we ignore what we have implemented today and we just think like conceptually what what do we want what we want is we want the chain to have a certain number of amount of gas per second how many blocks per second are unrelated to that like fundamentally we want gas per second and the execution client does know you know when was the last block and how much gas did that last block use and how much time has passed since that last block and so i think we should again purely theoretically ignoring currently implementation we should have enough information to do gas per second without knowing the future slot time without knowing what the intention intended slot time is we should have enough data to answer that question i don't know how we convert it in that scenario it would just replace the elasticity multiplier because we don't right now we don't actually explicitly set the gas target we set only the gas limit and instead there's a decision multiplier to calculate the guess target and if we would set the guess target on the per second basis and we would set the block gas limit which we still need in order to know what the maximum block size is then we would just no longer need elasticity which would just be implied then yeah so i guess i guess my argument here is weekly that i would rather see us come up with a larger change that makes it so we don't need to have the execution client know what the block intended block time is um when for the merge like with the merge i would rather not have to leak information about block time into the execution client if we can avoid it if that means making a larger change i think i would prefer that personally um like a larger change to this formula i would prefer that over a simpler change that does result in a leak of information from the case so yeah like i mean it feels like you that purity is uh no i know anytime you like information you type you more tightly couple specifications and upgrades right but i think i think they are that tightly coupled simply like i mean it happens to be like easy because the current slot times are very close to each other with 12 and 14 seconds but if we had very different slot times we would have to make other changes like i i would just say like they sorry they are coupled uh lucas you have your hand up yeah i will probably throw a wrench into the works but um it feels like we are thinking about fixing a consensus problem in execution engine in general so the question from me would be why the consensus [Music] potentially cannot handle this like more like click does that you can produce out of order blocks if someone misses their slot or something like that you can't um you can but i mean the the way that the way that a proposer is selected is just fundamentally different than proof of work improvement and so you could do some sort of backup model where it's bought in if somebody doesn't show up in a second you could have somebody do a backup but that's uh still even if you did that you could have mislaws and result in reduced capacity which it seems natural for the eu to be aware oh and scar yeah i just wanted to briefly say with the guts the to the conversation about leaking information about the block time slot time and to the execution client i don't actually think that this is avoidable just because uh even if we set the gas throughput per second and the block gas limit separately we still want them to go up and down in lockstep right so like because otherwise we don't have a mechanism and so we would still need to hard code the elasticity and if we had got the elasticity of 24 between the two then we are already hard coding again that the slot time just in a hidden way so um why do we want them to go up how would you how else would you ever was um over the yeah the gas limit and the car started up and down separately i'm sorry i thought you were saying the guest on the the block time when that increases you would want the gas limit to go up at the same time i misunderstood i know i mean i mean actually like with the signal like with just like just s right now and i don't think we want to have the eap that would remove the control by the vocal poser from at the part of the merge so right now block composers can slightly nudge the gas limit up and down right and um if they continue to be able to do so we would hope that also the guest target per second would go up or down by the same uh like fraction um um we could we could make it so so so this is this is where it gets into the a bigger change to avoid the data the information leak but one can imagine a change where the way that they increase is now you increase the gas per second rate instead of the gas for block rate and so the limit that would go up is the per second rate and so every proposer can do 1 10 24 increase or decrease in the gas or in the gas per second rate how would the limit go up so just like the rates like if we want you know 10 gas per second or 1000 gas per second or whatever and that's our target then each proposer can say i would like to increase or decrease that by up to 1 10 24 which would be functionally the same as them currently increasing the block limit by 1 10 24th but but what would be the block limit in that world like would the block limit be set separately or would that just be automatically part of that or would you get it the block when it would be the block would automatically be character uh seriously but if it's automatically calculated this by 24 times that number there is your block yeah yeah if the rate goes up um then our if the rate goes or if the slot time goes up then it means that the block limit would also go up and that isn't necessarily what we want like we may want um blocks to come every i don't know i'm just going to stop talking for a minute while i think right and just to briefly put maybe out here um i i think it's probably not not ideal to just talk about these details too much yeah i definitely think that like this is just a specific proposal that just came out of me talking to a couple of people so i think they're definitely other flavors of this that would maybe even be better to reach the same goal the question is really more do we think a this is just necessary for the merge itself or could we just wait for shanghai to come up with like a really solid and well worked out solution and if we think we should want to do it as part of the merge um maybe just talk briefly about how we go from here and then do the actual discussion offline i think yeah that seems reasonable um i guess does anyone think yeah we should not do this at the merge like is anyone strongly opposed and there's kind of the weak objection around like the information leak that micah just posted in the chat but like assuming we yeah i guess that aside does anyone feel like it's not something we should do like i said before i'm not convinced this this is a execution client problem right right right so but it could be on the consensus center side sure but it's it's and i guess the trade-off there is obviously you know if we do it and it's non-trivial it does add some work related to the merge um but it does seem important um and verdi's kind of seem worth exploring more um just to speak to that there's always additional things you could probably do in the consensus layer to try to avoid missed slots but there is just a stronger notion of time and there is a notion of something not happening during the time even if you do shore it up in some ways and so there is this notion of like you can have mis-slots and i don't think that's going to go away and thus the evm can either react to that or not with respect to its capacity right so there are certainly concerns like this compensator and you probably want to make sure that try to make sure that slots aren't missed or there's recovery in the case of slots being missed but the thoughts will always be able to be missed right um does it make sense to maybe just schedule like a breakout room for this sometime next week or the week after something like that it does feel like we probably want to think through the like design space and like come with some proposal that at least you know yeah we we all agree makes like the right tri-duffs um i'd definitely suggest this coming week um i do think that this if we do anything to the evm that this is uh the thing to do with the merge i do think that 10 of block proposals going offline because of some reason or other is like totally something that could happen and having uh reducing the incentive for that to be happened from from an attacker and uh reducing the impact that has on the execution layer and on capacity i think it's very nice to have and if it's going to happen then we need to really make a decision but would it really decrease the incentive like if i if i have a validator and i know that the validator right before me i know the ip of the validator i can just toss the validator right before me and then create a block that's double as big so there's two types of i guess attack and sounds one is validated and validator and the other would be external and it reduces the external incentive to attack and it might actually increase as you noted the uh some of the intravalidator attack incentives so yeah we should think about that okay so yeah maybe as a next step and scar can you uh maybe propose a couple times that work for you and awkward ads for next week and uh we can we can have like a round table there awesome yeah thank you for for working on this and presenting it today um okay last thing on the agenda uh i suppose probably take up the bulk of the call is uh dankrod and guillaume have been working on stateless and vertical trial implementations to facilitate that and they wanted to share uh just kind of the a the general road map around stateless and why it's important and kind of the solution space they're in and then why specifically vertical tries are an important step uh in that direction um yeah solid two of you uh go with it they cried yum hey uh i just shared my screen can you see that yes we can yep okay so i i wanted to give a quick um overview um over the vertical drive work for evernote on this call so that um you know where we are and like why we are proposing these changes and that are quite fundamental um and so i'll start by quickly like just um giving a very rough um uh idea on on on on the whole thing so so what's a vocal tri vocal stands for vector commitment uh and merkel and so it's basically a tree um that works similar to merkle trees but the commitments um are vector commitments instead of hashes and tri stands for tree and retrieval so like um it just means a tree where each node represents a prefix of keys which is already the case in the current merkel partition trees um and so what does that mean so when we look at a marker proof i made an illustration here um if we want to prove this um this green leaf then when we go up the um the tree we need to compute all the yellow nodes all the hashes at the yellow nodes right and for that we need to provide all the siblings of either the green or yellow nodes so that we can always compute the parent hash okay if we change this um here i i showed like um what what happens if we go to with uh four instead of uh the binary tree that i've shown just now um for a merkle tree then what happens is we've reduced the depth but now we need to give three siblings at each layer instead of the one we had previously and so actually by increasing the width we increased the size of the proofs which is like currently one of the big problems um with ethereum state and that mercury partition trees are actually with 16 so the proofs are huge and so how do worker trees change this so here is an illustration of what happens in a vocal tree for the same situation we again have the green uh leaf that we want to open um and um instead of having to provide all the witnesses um in a in a good vector commitment in quotation mark um so like in one of the the ones that we are going to propose um instead of having to give all the siblings which is happens when you use a hash as a vector commitment which is what merkle trees do you only need one opening for each of these layers and and that opening is constant sized so that's why suddenly it becomes efficient to increase the width because the the proof size doesn't suddenly increase but instead it decreases and so um if we have this very tiny example then um then we have to just provide this inner zero one node as part of the proof and these two openings as part of the vector commitment openings and even better typically we're going to use additive commitments so all these openings will collapse into one um so that's basically like a short summary like here basically what happens is you have to give this one in a node and one opening that gives a proof that leaf zero one one zero was part of inner zero one and in a zero one it was part of of the root um so there you can see uh where vertical trees gain the efficiency it's from this this property that you don't need to give all the siblings anymore but only like a small proof that everything is a part of the parent okay so um i made a short illustration here like on how how good they are um so basically like we are we're going to suggest that um the proposed gas cost per state access um will be 1 900 gas and at the current gas limit that would mean about 15 000 state accesses if you use a hexa merkle tree then currently the witness sizes are about 3 kilobytes per witness and that's 47 megabytes so that's absolutely huge if we change this to a binary merkle tree uh we would have about half a kilobyte per witness and then we would bet eight megabytes that's still pretty big now if we use a width 256 vocal tree instead with a 32 byte group um so like each commitment has 32 bytes as it has now um but it's going to be a different type of commitments um then it would only be about 100 bytes per witness and so that reduces it to 1.5 megabytes and now we're finally in a range that we can consider is is reasonable and lets us do statelessness some summaries on the course so um i made some estimates here if we want to do uh 5000 proof so each each of the 25 000 openings that you would have to compute um would need 256 times for field operations each of them costs about 30 nanoseconds so that's 750 milliseconds for such a proof so that seems pretty reasonable in terms of prover time so that's the one that a block producer would have to do and the verifier would have to do a multiscalar multiplication and the size of it is determined by the number of commitments that are opened so it's an msm of size 15 000 for these 5000 truths and that we estimated can be done in about 50 to 150 milliseconds these are all estimates based on like the raw speed of the space operations so benchmarks are still coming in and we need more optimizations to actually get there okay so um i'm going to come to the tree structure that we're going to suggest and because that's important for the road map and why we are suggesting doing these changes in a certain order and the design goals that we had in mind when we when we came up with a structure is that uh we want to make um access to neighboring code chunks and storage so that's cheap um but at the same time distributes everything as evenly possible as possible in the tree so that state sunk becomes easy these two goals might seem contradictory but the way we do it is that we we aggregate this neighboring code and storage slots into chunks of 256 and and only within these it's cheap and then these can be fairly evenly distributed and then we want this whole thing to be fast in plain text which means fast in the direct applications as we're suggesting it now but we also want it to be fast and snacks so we envisioned that within a few years um it will become very feasible to to compress all these witnesses using snarks and and for that we optimized everything so that it can be done very efficiently in snacks and that would also help anyone who designs roll-ups with us or anyone who wants to create state proofs and feed them into a snack finally the whole thing should be forward compatible so we're basically designing a pure key value interface um with 32 bytes per key and per value so keys um are basically derived from the contract address and the storage location um and what we're going to do is like the uh the two will be used to derive a stem and a suffix and the stem um is simply pay doesn't cp doesn't as a type of hash but when that's um also efficient to compute in a snark um of the contract address and the storage location except for the last byte right so we're extruding the last points on this and then us there we put the last byte of the storage location directly into the suffix and so um for any storage location that only differs in the last byte the nice thing about this is that and the stem will be the same and only this last bite will differ and then we're going to put them into a tree that looks like this we basically have this um vertical try at the start that locates the stem and that works very similar to like the currents the current account try and then at each stem there will be an extension node that commits to all the data in that extension and so that means that um like opening several points of data in the same extension which we um yeah or like the same suffix tree which you also call it um is very cheap because like the whole stem tree is already opened at that point there's nothing new to do and you just have to open another point in these polynomials c1 or c2 and so that is that is a very fast operation and very cheap um yeah so as a as a rough summary basically we have a huge reduction in witness size sizes it's about uh five times smaller compared to binary mic mercuries and um more than 30 times uh smaller than the current tax retreats so that's pretty huge um and verification times are pretty reasonable like similar to a binary merkle tree um the prover overhead isn't huge so like even in the worst case it's um i estimate it can be done in a few seconds um our solution doesn't need any kind of trusted setup so it's all um basic elliptic curve arithmetic which we're already using in ethereum just the discrete logarithm assumption and i think it's currently the only known solution for ethereum state that doesn't come with like huge trade-offs in terms of how big the witnesses are and everything right um so yeah this was my quick introduction um i can't see are there any questions about it at the moment i don't think there were any well there were a couple like technical questions in this chat but i think they all got answered um okay yeah great yeah um i mean anything one's not answered oh go ahead yeah so please feel free like if anyone has any questions about this like reach out to me i'm very happy to explain anything i also wrote a few blog posts about it um yeah it's obviously like uh some something to get into and uh it has a big change but i think it it also comes with huge advantages so um i also gave a peep and peep and eep talk if anyone wants to i think it has some more details so identity i did have a question from the chat um you showed the max witness like worst case witness size uh do you have data on what the witness sizes would be with you know current average main size domain network so that's not so that's not technically the max witness size that is uh i mean they're different different definitions of max like that is the the max if you don't spam the tree so what i shared here was a rough estimate if you have like a block that does only state accesses for the whole block um but that's the slide right but it's not about so if you spam the tree there are some worse things that you can do um in all of the cases obviously i think the the average cases occur should be a couple hundred kilobytes yeah i do have actually and i wanted to share that as well i actually made a little calculator um which i can share where you can play with these things sorry um so it's this one and basically um how you can use this one this one uses all our suggested parameters and you can adjust how many elements are in the tree it will compute what the average depth is this is all the input forces suggested gas changes and then you can enter numbers on what you think like so this is an example where we access one thousand different branches or one thousand stems essentially uh four thousand chunks then we have like um 400 update different branches update and 1200 chunks updated then it gives a number here that would be the gas cost for that so this this this example would uh spend more than 6 million in gas dust on the state axis so that seems maybe like a roughly reasonable average case i don't know maybe even high average case i don't know if people are gonna spend that much i don't know how to estimate right now because people are obviously also going to adapt so in this case the total data so this is any any scheme has to provide the data right so that that's an absolute must um unless you snuck the whole execution you have to provide the data um the data size here would be about 200 kilobytes and the total proof size so that's all the commitments and the opening that you have to give in addition would be 110 kilobytes so the total witness size would be um 308 kilobytes so that this is like a roughly average case and i put this on there on the acd uh call as a link as well so please like feel free to make a copy of the sheet and play with it and yeah here are numbers on like what the prover time would be like 250 milliseconds and the total verification time and 64 milliseconds obviously all of these are estimates at the moment cool so basically yeah sorry those benchmark those benchmark estimates are they on um just like what kind of very rough class of hardware is that estimating that that's that's a recent like intel cpu basically like like a laptop or like a server um it's not parallelized so it shouldn't really make any difference like it's single thread okay yeah so one thread on a modern intel cpu-ish yeah that's my estimate like as i said so these are basically based on what's the dominant operation for each of these things and like estimating how many of these are of these you need i think these two things are like fairly um uh i can estimate fairly well um however this does depend on eliminating all the other bottlenecks so just to be clear here the prover time this would only be the time to actually generate the proof and i would say like it's very likely that most of your time will actually be spent like getting the stuff from the database like that's you still need to do that that's separate cool and um so uh the reason uh why we brought this to the um call now is that um what we want to suggest is that um we we basically have created an idea for a roadmap how we how we make ethereum stateless and um the idea is this um the idea is to spread the changes um over three different heart forks and um and at the end of it um well actually like if ethereum would not be stateless in itself but but it would would gains optional statelessness and i will explain in a minute what that means and the changes um would be for the first hard fork which i suggest to be shanghai would be to make the gas cost changes um in order to like enable enable all this and the reason for making the gas cost changes first is well one is they are relatively um a bit easier to implement than the whole database structure or well actually we need to make some changes to the data structure but the whole commitment structure um and two the most important thing is i think to give signals um to like developers as early as possible um on like how they how they should handle state taxes in the future basically each month where like state access remains cheap and everything remains as it is is another month where like new contracts will get deployed and they will all depend on the current gas schemes and they will all be upset when later everything changes and some stuff becomes super expensive or they could have developed in the more efficient way so that's really annoying so it would be um just so much better if like as early as possible we could get them to the right numbers and i think realistically let's be honest the only way to do that is to actually change the gas costs um and so that is why uh i i suggest in the first hard fork to make these gas cost changes um in the subsequent hard fork and i call it like shanghai plus one here cancun or whatever that is um what we do is we just freeze the current market partition tree root as it as it is exactly at that point and we add a vertical try commitment um and that is initially going to be an empty commitment and we'll just track all the changes from then on and at shanghai plus two we replace the frozen mercury tree root um with a vocal tri route and the reason for that is that with this roadmap they're at no point does there need to be an online recomputation of the state like all the recomputations on database and commitments can be done in the background and that don't have to be done online okay and so the gas cost changes um i sold and well i mean it's based on work by vitalik um but yum has separated them here into a separate um eip draft and the idea is basically uh this so i i desi i like keep in mind this design for the vocal tree so we have this these different parts we have the stem tree um where you basically uh try to group things together that that are in similar storage locations and then extension nodes which is like a a node representing like 256 storage locations that are close together and so basically we have typically two different kinds of costs we have like a cost if you access any of these stem trees and a separate course when you access um chunks that are within a stem tree that you've already accessed and so the sorry within the suffix that sorry within a stem that you've already accessed in the same stuff extreme so okay um and so the nice thing about that is that um some things will actually get cheaper um so and i mean that that's i guess like one good news for smart contract developers not everything was every state access would suddenly become crazy expensive if they designed things well then then they can actually save some gas and so we have here suggest that basically there's five different costs that depend on what you do so basically if you access any stem for each stem that you access during transaction you pay 1900 gas um if for each chunk that you access you pay 200. so if you access say 10 chunks within the same stem then you would get a cost of 2 000 gas from that plus 1 900 for the stem so a total of 3 900. um and then in addition like writing so for each stem that you write to you pay a fixed cost of three thousand again for each chunk within that stem you pay 500.

so if you added 10 of these then you pay like five thousand but you only pay this one once if it if they're all within the same stem and finally when you um when you fill a new uh chunk so when you when you add another um note here that has never been written to before then you pay 6200 so like adding your state is still somewhat expensive uh and finally this might be one of the most conversions of all the changes but i think it's overall just important and um we should do it and figure out a way to do it basically deactivating the self-destruct so the way we deactivate this we name rename it to send all and it moves all if in the account to the target but it doesn't do anything else so it doesn't destroy code it doesn't destroy any storage um and it doesn't refund anything for this for destroying those because they aren't destroyed um yeah uh so that's that's basically that would be the suggested changes for the shanghai hard fork so i mean it's mainly gas cost changes however unfortunately they do require um and that's one of the things why we're trying to introduce this whole thing early and get feedback on it and it will require changes to the database because um we are basically reducing the costs for this chunk accessors and that means if in practice they have they have the same cost still like as they have now um then that's a dos vector and that would be annoying so it would require that clients already make some of the adaptations to their database so that um accessing uh this the chunks within the same stem tree with the same stem would be cheap and i think the reasonable way to do that is if um people would just store this whole thing this whole extension um in one location a database so that's the easy way like it's um even if if the suffix tree is full that's about eight kilobytes of data um and so that's not a huge amount and and basically every time you read that you just read the whole thing from this and um and then basically because like whether you read 32 bytes or like 10 kilobytes from this like makes almost no difference it's always the number of io operations that um actually matters um that that should alleviate that concern yeah so that would be the suggestion for the um shanghai hard fork um the next hard fork um we would freeze the merchant practitioner route and add a worker try commitment so we would say like the current state route is frozen exactly as it is and no changes are made to it and then we add this empty vertical tri route that contains nothing but whenever anything from the state is uh written to or even read from we just transfer it into the vocal trial rule um but that doesn't mean we remove it from the worker participate we leave that as it is and then in the background at any point um between this and shanghai plus two um you can make this background computation where you where you can recompute this mpt root as a vertical root and we would then replace the mpt root with a vertical tri-root and so that's yes so basically you can do that either you can do that locally but it can be done in the background because all the data is cons is constant so even if you have to access the same database um like you can do that in some in another process or anything people can run that at any point and so that's nice you have several months to do this um it could also be even a simpler solution for some clients to simply say like provide the converted database as a torrent i guess there should be still a way to like verify it but maybe not everyone has to absolutely do that um it's i mean the trust model if you just don't know that as a torrent is not really different from doing a snap sync so like as long as we have reasonable number of people doing this i i don't see like that there's a security concern there and if we actually do already have states um expiry ready at that point then um we don't actually need to do a database conversion for most clients because we can simply use state expiry for the last step we can simply say from now on this first database has expired and then you only need to literally replace the root and you normal clients normal nodes that don't keep all this old state don't even need to convert it anymore they can just forget about it and what's the result of this basically we get optional statelessness so at this point anyone can add block witnesses to a block and we have made sure that they are reasonably small and quick to verify and everything and also reasonably easy to produce and so what it means is we can create separate networks where we have status blocks for example one obvious one would be to simply use the what is now the consensus network the lib p2p network on which all these two clients run and simply distribute uh status blocks on it um but there could also be more experimental other networks that's um that do things with these status blocks and and then um i guess like as an optional future thing or very likely future thing is like um we can for example one way how we come to full statelessness um is we just deprecate the old devp2p network say like consensus is now 100 percent just on lib p2p and the fp2p remains as a state certain network so anyone who wants to have full state goes on there and that's like a network that's mainly used um in order to get full state and um p2p is used by all the consensus nodes like clients and so on whoever one wants to get um blocks with witnesses yeah cool yeah that's uh that's my that's my introduction of the whole thing maybe and do we have any questions at the moment because my guys had to sit up for a while uh so first question so the the change in shanghai it feels feels like maybe i'm missing something here it feels like that's a pretty significant change like changing the database structure in a way that so that current execution clients can correctly calculate the future gas costs i'm concerned that that may be something that's they can't even do so right um [Music] so to be precise you don't need so you you can easily compute the gas cost so that's that's not the difficult part like all these costs can be we can add that to a client right now to compute these correctly um so without without database changes you mean right yeah yeah without data changes so you can compute all that um you you need to compute the new keys and you need to have like some some array where you where you store like everything that has been accessed but that's that's all tiny that's that's not a problem so the problem is that we are making some things cheaper with these gas changes and that um realistically requires some database changes in order to yeah i mean i i agree it was a concern um but i yeah that's also like one of the things i want to bring here for feedback um we could do it marius i think is suggesting which is um to calculate the new gas cost and use the higher of the two so calculate what the gas cost is using the old database layout and also calculate what the gas cost will be and then just use rights of those two for each operation um yes the downside of that is of course we're giving nothing when giving nothing to smart contracts developers right you might making everything strictly more strictly worse yeah um i'm okay with that i'm sure some people aren't here so the second question on the shanghai plus one fork if i understand correctly every database lookup will require two reads one to read the vertical tree to see if it's present and then a second one to check the the old mpt tree and then potentially then migrate it as well are we accounting for that in the gas cost the cost of the double read and migration or are we just going to say that hopefully this is uncommon enough that there's not attached by like triggering a huge number of migrations as a precision you don't actually need to go through the tree right you're just you're just going to keep because the tree is frozen you can just store the the data that was in the mpt as a key value store so it's still costing something but it's not as expensive as going through a tree right so i mean i guess the point is also um maybe to be clear here uh i don't think there should be two databases right so at least the data only has to be in one database like the the actual keys and values um like there should be maybe currently that's not the way it's implemented but the right way to think about it is i think that uh data and commitment scheme are two independent things and so basically there there are two different commitment schemes at that point but they aren't necessarily two different databases that makes sense i see so the actual key values you're imagining are in a third air quotes database and then these other two databases are just like um basically yes and that database simply has like a little marker that says is this already in the vocal um part or is this still in mpg gotcha out of curiosity for the client devs does that align with your guys's current database layout particularly interested in ergon since i know their database is very different uh well in aragon we have um so-called plane state which is separate from the hashed state required for the miracle patricia to try so we already have that in aragon and for us it will be relatively easy to implement this additional local try commitment is that also true for the other four clients three now um for basi that's kind of hard to say um i'm not sure about you know the um the treeing but we do have the ability to kind of swap things out as far as the underlying data structure itself so it's a real tough question for me to answer right now but we'll keep an eye on it is one of the things we're tending to modularize the same way aragon does uh so related to that the question will we need to um have gas accounting for the migration step since i'm guessing that's a non-free operation like if something is the first time the first time you read something from the mpt tree and you need to write it to the verbal tree do we need to have that cost more gas than any subsequent reads because there is you know database work disc work and i was worried that someone could you know manufacture a a block that just does a huge number of migrations in one block and potentially blow things up right that's an interesting question um maybe i misunderstood but um since the migration is happening offline uh first you can do you can get someone to do it for everybody else and share it uh yeah i'm not quite sure why um no i i don't think i don't think the question is actually about um about like the the third step where you say like it's good yeah i think exactly so basically like now we are in the state where you can access things that are in the merkle partition tree you can access them um you can access them cheaply because they already like like for example you can write to it without it carrying the 6200 gas i guess um [Music] yeah it's a good question and i haven't thought about i thought it through i don't know if vitalik has because he created this the gas the ideas and gas costs um one way to potentially think about it is to apply um the costs from the perspective of the vocal tree so if we say this guy um yeah i mean i think just naively it seems like we can say like if you access something that isn't in the vocal tree yet then it's a right basically yeah basically you charge rate costs or maybe write plus read costs whatever it is yeah that could be one way of doing it yeah vitalik have you thought about it i don't know she's still here i think he left okay um and i thought andrew you had a comment about the target costs uh do you want to kind of bring that up um yeah just uh i think [Music] because the new target costs are already on average higher than the status quo so then if we defensively make them even higher in the transition that might uh potentially be to prohibit too expensive for smart contracts so i'm thinking maybe if uh like moving if having the new target costs requires some kind of database refactoring perhaps it's still worth doing that and delay the the gas cost not not to shanghai but to a later fork but probably to my mind is this some kind of database layout refactoring is a pretty much a prerequisite that's my impression yeah i agree yeah um we're about that time um what's the best place to continue this conversation bankrupt um there's i think we have a channel for this on the r d this chord do we yeah we have a state expiry channel um right i think that's a separate so basically maybe we have vertical migrations yeah yeah if you look at so basically i intentionally we intentionally designed everything so this is that it's independent from state expiry and address extension so that all of these can be worked on independently and they aren't blockers for each other um yeah uh so i think next steps yes so i mean i'm very happy like if anyone wants to understand more and if they want to ask any question like please reach out um and also um i guess maybe the big uh yeah the big questions here like if i would be discussing about these database changes that would be required for um for the shanghai gas cost changes that we're suggesting if we can discuss that see where each client is on that and how uh how big those are yeah that would be great to understand okay great yeah i think we can use just the vertical trash channel here so um oh yeah i'll just type the name in the chat here in case people are not on it um yeah yeah thanks a lot i thank rad and guillaume for sharing and obviously working on all this uh any kind of final questions anyone has any ideas on how we can do address state extension and that would allow us to prioritize uh state expertise and i think this proc transition process is actually significantly easier if state expiry can be done simultaneously or first great um and there is also an address space extension channel on the discord uh one thing i'll note before we head off uh at least in north america daylight savings time is changing before the next call i'm not sure about europe i think so as well uh but please double check the time uh so the call stays at 14 utc two weeks from now but uh at least in north america that's one hour earlier in your local time and i think that might also be true in europe um yeah so please just double check that uh before we meet again in two weeks yeah thanks everybody thanks thank you thank you bye bye