Stateless Ethereum Meeting 17

Transcript

okay we are recording uh welcome everyone to this i'm not sure how many numbered stateless ethereum call um we have neville today who's going to present uh the analysis that he and his team have worked on for the impact of gas pricing for code chunks under vertical tries um trent has just shared the link in the chat um yeah neville take it away i guess i guess it probably makes sense for you to just like walk through the report you know kind of give a summary of your findings you know and and and then we'll move more towards like a a q a and open discussion sure okay so i prepared 10 short slides

i'll i'll just go through them it's going to take around 15 minutes and then we can discuss between ourselves all right so um right so okay well i guess everybody knows the context in which uh this study has been carried out um well so vertical trees exploit the polynomial commitment schemes and because of this there's an opportunity to reduce the witness sizes and so you know you can come up with these status clients and the block proposer can then just send the relevant state witnesses together with the rest of the block

now the crucial part is that the contract code is part of the state and so any code which is executed or at least accessed for instance using code copy that needs to be metered too right and the way that has been done proposed is that the code is going to be chunked into 31 byte segments y 31 not 32 is because you need one byte at the beginning in order to see how much push data there is so that in order that you can parse that individual chunk okay and so obviously changes to gas prices

can break contracts and in this case they may also render some smart contracts uneconomical so the summary that uh me and the rest of the team at ddob conducted was over uh some of the recent blocks um so that's 12.9 to 0.95 million so it's a pretty representative sample of current currently executing contracts in terms of net increase in gas cost that's around 26 but it's interesting to see on the right hand side how that 26 percent is represented by

so uh the current proposal decreases the cold gas cost when you've got adjacent storage slots being accessed you see if you are accessing for instance slot number zero typically that's the owner and then another slot after that then you amortize the cost uh of the cold you know the cold access of that those two and so the state access costs are reduced but then of course the code chunking so

for every 31 bytes which needs to be loaded you need to factor that in that that increases the cost significantly i mean as i said we estimate around 26 percent okay uh it is also interesting to see that um the way that the study has been proposed when you load certain information about the contract like balance you are the first 64 locations of storage are also in the same subtree and so you only need to you need to pay fewer gas costs for getting

some of the first few locations and then the rest of the storage instructions are chunked 256 at a time right and so what that means is that if you've got you know flat global variables that's fine they're probably going to fit in the first 64 locations but when you use maps or when you use arrays every one of these will be and in the case of maps every different key value will be in a different subtree okay so adjacent storage locations cost reduced from 1900 to 200.

uh then you've got uh the chunking mechanism every 31 bytes of freshly loaded code that's 200 gas and then you also need to pay a much higher gas cost when going through different subtrees and theoretically you can have in practice you will have multiple subtrees for large smart contracts okay and we'll see how that manifests itself in some pathological cases right so uh in order to conduct this study we did two experiments we did uh we wrote the static analysis client on top of gigahorse two chain which is

an evm binary called lifter right and we wrote the path sensitive analysis which which can find the uh worst case gas cost increase for only for code chunking there's an api available there's there's around 30 000 contracts which were used recently there yeah we found a few fallback functions that will break but that there was nothing too serious exposed by their experiment in fact you know none of the experiments exposed anything which is serious uh but it was more interesting than to

carry out a dynamic analysis where we modified an ergon node to store not only the current gas cost per internal transaction but uh two different things so you've got the storage called gas cost for the post berlin semantics right so we've got those access lists that have been proposed for the eip2929 we re-implemented those so we can track how much is the cold gas cost in that system and you've got the current proposal uh which is slightly more complex we also implemented that so we are tracking both

uh the cold gas cost in both versions and then separately there's also the code chunking cost and you know by adding these or subtracting from each other we can we we came up with some interesting insights okay and all this data was combined with the contract library blockchain explorer database information is per internal transaction and now we could actually uh look to see some extreme cases in some of the most recent transactions okay so here's an extreme case now i'll go through this right so we've got um okay let me find this contract i think it's this one right no it's this one here

yeah all right so this is the decompiled view of a smart contract this is a unislop v2 router 2. okay and this is a very simple getter now i'm viewing the decompiled version of this it's similar in the source just give me a second oops yeah just give me a second yeah all right so this just returns a constant and because it returns a constant you would expect the gas cost to be pretty low but because of some pathological behavior in

the function selector logic so the function selector logic the decompiled version which shows you the function selector logic this is how it would look like right because there are certain basic blocks that one would need to jump to which are far away from the initial part of the contract and we can see this in a trace over here all right so this would be for instance this would be the uh instruction number and bytecode okay so the the byte number and

all right so the function selector ends here and then you've got a large jump here okay so the it jumps to an instruction which is quite far away and so you have to pay that extra price of the going from one subtree to another and then the solidity compiler adds that not payable check which is compiled to a another chunk which is further away right so you need to pay the price for that again all right then we're talking you know 1

900 units of gas each time and then you know there's uh other costs and so for this particular for instance getter which should currently be very cheap it's actually quite expensive with with the new vehicle gas class another interesting example is the curve gauge function selector okay so this is a written using viper and let's look at the function selector code okay so it's not the best decompiled representation that is true but

what to keep in mind is that in this viper contract the function selector is implemented using a linear search okay so if you've got a function say for instance which which matches the following signature then the execution needs to compare to all of these different ones and then what tends to happen in viper is that if the condition doesn't match you jump away to an instruction which is further away and so you waste the rest of the code chunk that you have loaded so you get you know an order of

magnitude increase in gas cost because of this on some of these functions especially the getters okay on the other hand there are some projects that are positively impacted for instance this is a smart contract from synthetics which returns a number of different fields within the same struct okay and since those are obviously going to be stored adjacent to each other okay so

since they are stored adjacent to each other the cold gas cost is amortized and so it's much cheaper to execute this getter than it was in the post-berlin semantics okay we also checked to see whether there's some particular compiler version which is causing these issues more than others and really we couldn't come to a conclusion okay so um in summary there's some recommendations that we have okay um so the ethereum foundation could consider lowering the chunking cost initially

for the first few months um so that developers can have time to improve their contracts and compile sorry but by chunking cost you mean the cost of accessing a new chunk and not an adjacent chunk right yeah a new chunk from say from 200 to 100. the branching factor in the vehicle tree now i understand that there's some cryptographic right now and then there's also a case where um where sometimes you get smart contracts like in um for instance it has a a fixed number of contracts

where it calculates the uh yeah it calculates the the position for a particular user and so it calls the same code for the different a tokens but that code is uh deployed to different addresses and so you have to pay the same uh chunking cost every time even though it's exactly the same code and so if the code is then indexed via the code hash it will optimize that particular case for developers of course if you group frequently access storage locations together and so you for instance instead

of having two different maps which are indexed by the same thing you have one map and then the value would be a struct it's obviously going to be much cheaper to do it like that um then the compiler developers they might be able to develop higher level primitives like for instance safe ads and then pack these into the first 128 chunks of a smart contract and reuse them every time because you don't pay a price for you know jumping and then jumping back it's like you know 10 units of gas and 10 years of gas to come back

but accessing a new chunk that's 200 units of gas so it's an order of magnitude more and generally cold within a hot pot so a part which is more likely to be executed in the contract code should be packed closer together um there's an example uh in the next slide so currently the the function selector logic is um right so so there there are no there are no loops it's like uh it's like this right so you've got you've got conditions uh which are you know compiled

into code like this uh which means that for every one of these that you access you are going to pay an associated chunking cost maybe maybe more right for each one of these conditions that you hit whereas if you put these into a loop so for instance right here this is some pseudo code which which i just wrote today before before the meeting so this particular loop will be executed log n number of selectors right and it's a little more expensive compared to

what's currently being generated for instance it uses cold copy and uses a few more instructions but but the code chunking cost is much higher than you know executing eq or john buy or gt then then for instance packing the function selectors so the four bytes um in a in a part of the byte code means that you will probably access half of that part of the bytecode and the rest you will not access so you'll not pay a price for that

um yeah and and the on the black stuff it only gets executed once um so it just adds um you know a fixed cost so you know there's there's some tricks that compile developers will come up with right to to optimize for this new semantics and you know this this red part which is the code chunking cost which is what's adding most of the gas cost that that will be reduced probably so in conclusion the impact is not negligible you've got 26 uh gas cost increase on average however this assumes that

uh that that that it's the the code will remain the same that the compiler developers will not come up with better optimizations and of the engineers they will not change their coal style and in any case the gas cost can be increased a little more gradually of course this impact has to be gauged against other factors all right so that that's that's what i had prepared um you know we we can go through um questions and maybe more things in the report how how does this 26 percent so i mean there are two different costs right

there's the cost for accessing a new chunk but with this last by the same like the same suffix which is cheap and then there's a more expensive one where you access like a completely unaligned one have you quantified what the contribution of each of these is to the 26 so in the extreme cases the the ones that we saw the contribution uh would be significant i i i haven't quantified them separately to be honest but i would think that it's the uh um you know i made a rough calculation and it's the the 200 which is which is the

highest uh which is the one which contributes the most towards that 26 that we saw but in the extreme cases it's the cost of executing the different subtrees right and basically uh so in the examples that you've shown with like the the select linear search and the selector um would most of these jumps that you have there would they be within like the same um sort of uh suffix tree or would they would most of them act as a completely new suffix so most of them they would be with this within the same subtree uh okay so it would still be to the cost of 200 and

not 1 900. yeah however then you jump into a function for instance in in in one of the previous examples the not payable modifier is actually reused across the different functions and it's been compiled in a uh very further away part of the the object code and so that adds an extra 1900 just just that little modifier there not payable of course a thousand nine hundred is nothing if you know you're doing storage changes right

so yeah so that doesn't contribute much to the 26 percent it's the the 200 gas cost i mean that's very interesting because uh we have a new idea for modifying them or like a likely way to modify the worker try construction which where we can probably lower that 200 and maybe i don't know well um i mean the the 200 number was like this is designed entirely around witness data size like it wasn't even taking into account like attempts to figure out how long computation would take yeah i mean i do think that realistically it's possible to reduce it slightly from

200 just because um like it's like i think branches um what like what what's the worst case for a branch um i think it's uh going to be yeah going down like about like what 14 or so times 32 like probably a bit a bit under 500 bytes and that's about 2 000 gas so about four gas per byte um so like if we wants to knock code jump costs down to the four gas per i guess maybe the four four or five gas per byte level that would be yeah like which is 128 as a minimum and then 150

as like a safe number uh just to clarify has it been like is there a difference is there a main contributor between the code because it seems to me like you're focusing on the on the code accesses so you mentioned the data access at the beginning and then not really anymore i was just wondering um is the data completely like the data access uh you know insignificant compared to the code access or uh or resources what do you mean by data access

uh like slot like storage slots oh i see um well i guess well data access storage swat access is being charged for already right like post berlin every new storage slides charges 1900 um so actually yeah this particular gas cost change will make it cheaper to access storage because if you access storage that's uh in the same uh size 256 sub range just something that you accessed already then the cost goes down from 2100 to 200. um so like for example if you look at uniswap uh the usw v3 the contract has a like a whole bunch of storage variables at the beginning that get and that a lot of them get accessed

um and those storage variables would end up mapping the slots like zero one two three four five six seven eight nine um and so like they would end up like basically replacing like 10 000 gas worth of reads with like basically just like one two thousand plus another um like a few hundred so less than three thousand total um so that that's the place where the gas savings uh come from for at least those lucky contracts that you get that you get gas savings from this change right yeah and of course the thing about maps is that each variant will be stored obviously in

a different subtree but there might be some optimizations but they're like uh you know you'd have to restructure the uh the storage scheme of your contract right so uh i don't know i i could share a few more examples if uh if you wanted to are there any ideas anyone's proposed for potential ways we could restructure maps so that they are more conducive to chunking i guess like one simple idea is that if you have a map of a struct actually i forget this has happened in salinity

already like if you have a map where the value in the map is destructs then do the strikes struck still gets stored contiguously i think so if not [Music] okay i mean if not i'm thinking more just like for tokens like like tokens being one of the major things right well the challenge is that for tokens the average access is going to still be pretty random unless like you're talking about things like oh you know the approvals well approvals are also a two-dimensional array so that's a bit different um because this is transaction wide right

and so if you could do a unisoft swap a token or any other app oftentimes the same token will move like three or four times and it would be nice if that you know didn't incur you know three or four uh code junk hits if possible don't you in those cases get saved by the fact that we're allowing the token if a slot goes from zero it starts for transactions to zero at the end of the transaction because the token entered the slot that place and then left it again no no that that saves us that does not save reading costs uh yeah it doesn't help with the code junking part yeah okay like okay i mean one very specific thing that you could do i guess is you could like store

um [Music] authorizations or approvals as being like just an array instead of uh storing them as a m as a map and then you just store them as a struct so they're kind of right beside the uh like you yeah you would store them as a um as a structure right beside the balance and then like some of the time you'd be able to save a bit of gas and that does add a bit of some complexity but but in general it sounds like we don't have any great ideas for getting mappings of things to uh consolidate at all right yeah i know at the moment [Music]

that's unfortunate but understandable yeah i guess um let's see i think like realistically the the the savings for that sort of stuff are probably going to come from like whenever we have any flavor of account abstraction so that approval stick can just be part of the same transaction and that'll probably make up like anything that this whole thing loses at least in aggregate and so the the storage location optimizations that's that's going to be hard to do uh by the compiler uh because of aliasing

that's something that you would let the developer do by the way i'm just like staring at the inside of um some uni swap transactions and like even in there there are like it seems maps of structs inside uniswap and they do get um stored adjacently and like accessors that are adjacent to happen and so i mean admittedly i'm looking right rather than reads here because i'm

just looking at a trait of what's been written but you've got quite a few places where like a slot and then a slot that's like two later has also been written so i suspect there's actually quite a few savings in like more complicated contracts but it's just like the simpler stuff where you don't get these benefits okay that's what v3 i'm assuming yes specifically v3 so this might be a dumb idea but what about implementing the maps as a try instead since contiguous success would be faster

it could get you saving in some cases oh i see like i actually am making a tree inside a tree um i mean that's already what it is with the current model right because the storage tree expands into its own uh sorry the yeah the the storage tree expands out of the air country so it would be going back to the same model really yeah but each map could be its own tree yeah it's kind of hard to visualize uh just like this yeah i mean like i guess you could like

make any map better by just having a like size uh 128 like least uh recently used cash or whatever like basically yeah like split all keys into one into 128 buckets and then for every bucket like you would just also store the most uh res the most recently here um scene value in some particular place and then if you need to agree to write the most that you would just update it there first it's uh oh yeah that worked pretty well i think [Music] when you don't do more let's not forget you know that

currently um like you know like like safe ad and things like that all of those implementations could be reused right they could be compiled someone could come up with a higher level dsl and that each super instruction will fit in 31 bytes and then you would only jump to that and back um so that reduces the size of the code significantly so there's less code to load yeah [Music]

i'm not a regular on the call so i apologize if this has already been asked in the previous call um have we gone over the kind of worst case scenario on mainnet um like for the past year in terms of the how much any given transaction would increase as a percentage in gas cost so that that's been conducted per internal transaction because it's more interesting to do that because so you can identify a specific project but uh sure around 15 x uh higher gas cost but that i mean that doesn't mean much because we're talking about a getter of a constant value for instance or a getter of a single storage slot

like one exam one example of a legit function that would be seriously harmed is um if you make it like um some cryptography libraries that depends on pre-computed uh 32-byte values so like for example take a petterson evaluator um where the yeah i think it was that might have been actually one of the examples right like basically like for the patterson evaluator to be efficient it just stores pre-computed a bunch of multiples of an elliptic or point and then based on the thing that you're multiplying the points by it just picks a random subset or or appropriate points subscribe it requires all these

random accesses but the challenge of course is that a push 32 goes up from being uh three gas to being in the worst case uh oh actually well in the worst worst case 400 guests if you do like yeah if you end up really unlucky with the boundaries but like the more realistic worst case 200 bytes so that like i think in that situation like if once you start optimizing for windows size like the optimal trade-off just kind of goes back down toward a yes a smaller size libraries and there's not that much that can be done about it [Music]

do we have an idea if anything on mainnet today would be broken in the sense that it can no longer execute at all like within the block gas limit that seems intuitively unlikely especially because one's in a double oh london doubled the black the maximum limit and then on top of that there is of course the recent guest sell and then increase and [Music] things that cost 10 like well most people don't build transactions that cost 10 million gas because there's just a bunch of safety reasons not to do that um but they yeah like the the the things that dude tends

to what tends to be more contract creations and don't tend to be like big cryptography things because they like basically anything that needs to be done more than once if it's big enough to be uh to fill up a block um then it's too expensive to expect users to do more than very occasionally right and we don't believe those types of actions are the ones that we'll see the 10x or 15x increase on right well contracts yeah creations are definitely not going to see the 10 to 15x um i get what what else is there there's um like i guess the the current version of the optimism fraud proofer but that's

also like i don't think it uses any pre-com like pre-computation tables stored in code uh hmm and as a rollout strategy i do like the

idea of like just whenever the the hard fork happens that just having a built-in kind of increase over time schedule for the code junk costs doesn't that make us susceptible to dos attacks during that time like no idea should reflect the us cost right well during that time it basically means that that like running a stateless node safely will have higher system requirements um so yes but so yes during that time like running like that that will make sure this notes but yeah but it does i guess the like one counter argument would just be that like well during that time people are

going to be twiddling around and figuring out stateless notes in the first place and so it's not going to be that mature anyway yeah so so if understanding correctly you're basically saying like people running full nodes um can run without introducing dns vector at the lower um code code lower browse costs and it would only be the stateless people that are perhaps at risk and we won't have any of them at launch and so we don't have to worry about that at launch yeah it might make sense i mean i guess we don't even like we might we might even have like two separate stages of this like the first stage just introduce

uh vocal trees and then at some point later we enable like because that also needs all kinds of networking work like we enable stateless uh nodes and in between like right well enabling stateless nodes would not require any consensus changes beyond the passenger point right exactly right realistically i expect a high chance that like nether minds people are going to get uh excited and just like build a an awesome prototype and like somebody will use it uh that would be very cool yeah that somebody can buy a big machine [Music] oh another thing is that if it's

specifically code chunking costs that start off being at say 50 and then ramp up to 150 then the stateless node implementations could start off as being partially stateless nodes that still sync all the code or at least that like that store the code that any code that they see so they're like they do the equivalent of like beam sync for code and then stateless for everything else another thing to consider is like um in the initial phase there's also not much like incentive to toss the light climb the stateless notes so i guess if the average as long as the

average costs are okay maybe it is okay to only get dust protection a year later also [Music] is there a risk that like just no one is that we're going to introduce it at the lower rate and it will be like fine it's not going to affect anything so no one will do anything for like six months and then we put it up and everything breaks and people start getting around to actually fixing things like basically like will people uh just not bother fixing until the gas cost goes all the way up to like 150 or whatever the final level is

that was the question yeah right um i guess that's always a risk um but i guess the the idea is that like this like the step up function is uh already the like close to the best mitigation that we can do because like you would already get users complaining about gas cost increases so yeah you could do it probabilistically one in a hundred transaction has to pay it in the beginning and then no fun 100 blocks yeah right i think we also have the benefit of um people like the solidity team we have communicate open lines of

communication with and they have like they can participate pretty heavily and helping with getting people moving forward and getting more uh vertical tree optimized contracts um so i think that i think that'll play a big role like if lydia starts getting updates out that being said people do run very old versions of slow today they do file other stuff so this is not like a full solution but it does help um just get people upgrading without even realizing like they don't even know if they're writing better code they just are because the compiler's improving hmm yeah in fact uh during the period of the study most of the contracts were not actually solidity 0.8 uh so so the question is when

could minor versions of the solid compiler optimize you know the the function selector code for instance um or is this like a major change i think you could it would be from a semver standpoint i think it can be a minor change assuming a minor or a patch because there's no api changes that being said i don't think solidity has a history a slave team has a history of doing patch versions to old versions so it'd probably be like you know eight point zero point two or whatever is next um it's unlike i feel like it's unlikely they're gonna release like four point twelve point seven or something

right because during the period of the study there were almost as many contracts that have been compiled with 0.6 deployed as 0.8 and that doesn't surprise me sadly i mean it's a it's an ongoing discussions to have uh long-term support versions of solidity but unfortunately not happening yet i don't think they even backport bug fixes so on that topic i suppose one of the the bigger conflicts is that some um

auditors recommend the old versions and especially if the problem comes out when somebody is building on an existing project which usually happens if they in d5 if they build on like other um emms or anything like that um and yeah i guess and the the the other big one is uh building on aragon um because those um the way you want to to extend it code base you have to keep using the same version of the contract and i think aragon itself is like zero six no it's zero four something actually and the other like emms are zero six

zero seven so even if you want to build on zero eight in many cases you cannot yeah that's a good point i wrote some code that like interacts with unit swap v3 and i was just like i have to use all these v3 libraries so i looked at what uni swap v3 compiled with and i picked that compiler because i didn't want to have to work out whether the new compiler was going to break the libraries i was lying on so the new compiler in most cases wouldn't actually break and it would work with the old one

with like the older sources but each of the source files start with a version setting and that version setting is flexible it could just specify the minimum supported version but actually the recommendation by auditors is to use a fixed version number not even a range um and in that case if the library you import has like a fixed version there's just no way to to do anything but either you change that line and they imported fine or you just keep using the same version in your cubs the thing that was concerning me in my particular case was that um the uh you had code that probably relied on overflows overflowing rather than

erroring and that got changed to 0.8 and it was just i just don't want to deal with this yeah that that's actually what the uniform team said when we when i suggested they upgrade to 0.8 before release they're like uh we'd have to rewrite a bunch of stuff okay so no free wins from solidity updates unfortunately it sounds like nonetheless i mean for me personally not nothing matters and the current plan seems reasonable to me start with low cost rent them up over time slowly

um as much fun as probabilistic ramp up would be i think it makes a little more sense to just iteratively do it and that can be over you know a year or something yeah we can uh we can check how much it would cost with uh with 100 and give you an answer so that 26 percent for instance goes down to 15 for instance i'm not terribly worried about the

percentage gas cost like at this point i hope that everybody understands gas costs change and you need to be prepared for that and you need to code against it and need to design your economic systems against that and if it's not an order of magnitude on average i don't worry too much i worry a little bit about like the worst case scenario so if you've got some contract that can no longer execute or some contract you know it's it's reasonable to expect your contract cost 15 or 20 more it's perhaps unreasonable to expect your contract to suddenly cost seven times as much like that's not cool um if if most contracts are kind of close to that average i don't know if we have like any other distributions besides

average but if most contracts fall kind of close to that for me that seems reasonable and acceptable even if we don't you know drop the cost down especially since people can write new contracts that are more efficient if it's really critical so i had another question i was

wondering if uh like if you looked into how the the cost would be um like would be affected if instead of charging the the access cost the chunk uh the chunk cost once per transaction uh they were only charged once per block this was uh definitely brought up uh but well i think yeah in the con back when we were starting to do these uh like non-repeating uh access costs uh for uh um in uh in berlin um and uh the am arguments in favor of making them be per transaction was basically just simplicity like logic to do things at the per transaction level

is something that exists for us like these data structures that um at per block level that that still can get reverted is something that we don't have before and so there's just more possibility of uh there being bugs if between like weird interactions between reversions and whatever um i mean could also mean that your transaction suddenly becomes a lot more expensive it says if it's included early in a block and stuff like that right right it it definitely breaks independence um assumptions but then like yes i guess the character argument is like well you know we have him ev and everything and uh we're we've basically surrendered to

the facts that optimizing rev uh transaction inclusion is an incredibly hard problem so and uh well payments for your transaction have been pretty random for a while now well i guess in the sense that they're predictable but the the fee level is uh is random regardless and if it's a uniswap trade then your slippage is uh unpredictable and all of those things so it's not clear that you'd be losing anything that like or it's not clear that the loss of invariance actually sacrifices anything that wasn't already lost the fairer solution to that is simply to

offer a refund to the to the block producer that allows them to include extra transactions because there were some gas savings by repeated access well in an eip 1559 context like being able to include extra 10 transactions like would mean what like uh like that would only apply during the congestion case right like during the normal case like would you refund them to base fee as well i mean and if so then that just like that just means that they get a refund which uh i think is uh hmm could be a refund on the gas limit not a

refund on the gas fee and it would impact 1559 because it could it will influence whether the base fee increases or decreases [Music] functional standpoint how much it costs to execute a block is lower if every single transaction that block accesses the exact same state but currently we charge as though they all access different states and so we could increase the throughput of the blockchain by amortizing that out and saying hey you guys all access the same state so we're not going to um raise the gasoline for wax block yeah i mean realistic like theoretically you could even just uh refunds the base feeds of the produce to

the um like proportionally to people who access the same state like you have three transactions access that then you refund each of them two thirds but that's like more complicated consensus electric already yeah i think i think the main argument against all these is exactly what you said it's the way the execution engines are written right now um adding block level state that can revert on a per transaction basis would add a lot of complexity that none of the execution engines currently have the kind of architecture to deal with and so it takes a change that would otherwise be small and makes it now a very large change just because it touches so much code

and this is just a side effect of the way things architect right now if this is a brand new blockchain then i think that um this would be a perhaps much better idea right yeah um well i mean if this was the new blockchain there were not like a block would just contain one transaction and user transactions would just be called some way to figure out how to do abstraction properly but um i still have the dream and i think we're closer than ever yeah one other thing that i forgot to mention um is that the study didn't consider other things like for instance there are some contracts which are very tied to the current patricia tri implementation um such as skidonyx

oracles where they use the block hash and then they accept the proof to see what the storage location was at some point in time you know all those contracts will be broken but it's you know there are two ties to the current implementation right i think for those cases like we do we just have to accept that anything built off of current trees can't be helped but one idea that i had for forward compatibility is that we would also look this would be a separate eip but we can introduce some um op codes that do a history proof verification and uh those op codes like when um when verbal trees are introduced they

would take in vertical proofs um and then the nice and they would just take as input like basically like some historical block number um a proof and then it will just be um or historical block number key value proof and it would just return whether or not the group is correct and the real and the nice property of this is that if we later upgrade from a verbal tree to um something else like we upgrade to like some starks binary tree then the yeah pre-compile could just be seamlessly updated and uh based on what the block number um or the slot is it would just automatically either expects the proof to be a verbal group or expect the proof to be a stark binary proof it'd be great great if we can get

something like that before we do the first tree migration so that way people can have time to my grade to this new pre-compile off of whatever old systems you're using and that being said there are relatively few actual people using things like the chaonix oracle or transaction process of the other one um it's like the scope of i mean it's never fun but like the number of people actually impacted by that i think is low by volume it's just unfortunate like most people nowadays still use admin keys right so like it would only be a problem for those contracts which aren't

like upgradable for some reason right it's just unfortunate the people were the people were hurting are the people who are doing things right [Laughter] like doing proof verification and non-upgradable contracts like oh sorry we're gonna screw you um yeah yes um well the question is like i guess like at some point we need to be more systematic about like conveying what things like of the protocol you can rely on and what is subject to change and maybe we haven't done that in the past but like um yeah and i think i think just getting a with enough time people can upgrade from pretty much anything even non-upgradable

contracts you can still do like you know swap you know you swap data v1 and v2 and d3 so if you give people enough time they can migrate and so i think if you just provide the tools enough in advance like this uh proof verifier recompile then people will be able to migrate whatever they've got like i don't think there are many contracts out there that are non-upgradable and have lasted a very long time also people who write non-upgradable

contracts tend not to do like complicated risky things like screwing around with proof of things about the merkle tree like i can think about contracts we absolutely cannot change like say the ev2 deposit contract but like no one's doing anything weird or complicated and that that like would be broken by changing how ethereum works yeah one interesting thing will be um so i've

definitely had some people contact me who are worried about their bridges and whatever i don't know that um how many bridges currently do like storage proof verification and stuff like that but yeah they'll have to upgrade but i think at the moment uh that's not so much of a problem for ethereum like everyone would just upgrade their bridge and do whatever hard work they need to stay compatible with the ethereum chain that might become a problem for for other trains when ethereum say troy won't hard fork

to stay compatible with another chains upgrade so that seems to be all the questions or comments

anything else anyone wants to add before we wrap up keep up the good work everybody yeah thanks a lot for joining um yeah and we will continue conversations on this in the execution dev channel on discord sounds good okay have a good one thank you thank you or whatever it is