Gas Repricing Breakout #1

Transcript

Um maybe I can add already. So for the agenda um the idea is we'll start with a quick intro on the whole repricing effort. Um I will show some slides um and then we'll start doing the deep dives for EIP. So I have um pinged the champions of the EIPs and I will ask for them to present um in order to make sure that uh we keep on time and uh we have time for all the EIPs. I'm giving five minutes for each and I will be sorry but I will try to be very strict with time.

Um so if your five minutes are are up I will um warn you and we'll have to move to the other EIP. Um so on that note I think I will start by sharing my screen so we can do the quick intro. Um okay so um let's talk about repricings in um Amsterdam. So first I wanted to have a common view on why it is important to do this um now in Glamsterdam and I think there are two main reasons. So the first one is that Amsterdam is all about um

scaling the L1 and so this is let's say the focus of the fork and um I think that pricing has a direct impact on scaling and this is achieved by harmonizing operations that currently are not harmonized. So for instance the compute operations they don't have the same performance in terms of million gas per second. State creation also doesn't have the same cost depending on um the operations. Um and also for instance data from access lists are free while from call data you have to pay for for the data. there's tons of um

misarmonized um operations across different resources and this leads to single bottlenecks. So by doing these um harmonization we are removing these single bottlenecks and um allowing for the EVM to perform in a more harmonized uh matter. So we are removing these single bottleneck. So this is a diagram that um Ansgard did in a talk um a few months ago and it's essentially showing that you have like all these uh resource or for a single resource you have all these operations and they each have different performances and um like the single

worst operation is sort of limiting the level of throughput we can have with harmonization. So making all the op codes closer together uh we are removing these single points of of of um bottlenecks let's say. So this is reason number one. The reason number two is that actually repricing will unlock some scaling from both headliners. So both EPBS and balls can have a meaningful impact on throughput. So with EPBS we are giving more time for uh execution and also for data propagation.

Um but there's also a caveat here which is we we are giving more time for execution than data. So we are increasing the time on both resources but we are increasing more on execution. Um and for balls we are introducing parallel execution and also state root calculation in parallel. Um but this is actually adding a cost uh a data component cost to state operations because now state operations uh will use um will use block space which is the block level access list itself. So what this means is that actually the relative

costs of different um resources will change and if we don't adapt the pricing to meet those changes then we are introducing bottlenecks not at the resource level but on the whole resources. So for instance, if we um don't repric state growth as a as a as an example, um we cannot really increase throughput because if we were to increase throughput by which would be allowed by both EPBS and block level access lists, then we would increase

state growth and um even though we have more time in the block for execution and for block uh for propagating the the block we don't really have more room for state road. So the the the available budget for state growth we have is not changing and so we really need to change the relative cost of this component for the other and this is the same between the relative cost of data and compute and state access. So because now data will have so data will have to become more expensive in relation to both compute and state. Um and so without repricings

really the level of scaling we can get from the both headliners is limited. Um and on this note then how do we think about repricing in in in Glamsterdam? So at the moment the metaip so the the the final version of the the repricing metaip is not yet merged because there are a few EIPs that are also not merged. Uh but at the moment we have 16 EIPs that are in some way related to repricing which is a lot. So this can be a bit hard to navigate. Um but I I think I I'm starting to think of them as in these three categories which I think

helps um to to to kind of put them in in buckets and think about them. So on first we have broad harmonization. So this is essentially EIP that are changing a broad set of operations that all touch specific uh resources. So for instance we have one for compute state taxes state growth and also for intrinsic costs of transactions. Um then we have uh pricing extension. So this is more a targeted change in the pricing model. It could be just repricing a single op code. It could be changing some component of of of of the gas model. And usually this will either unlock some scalability or fix some

specific mispric. So it's not a broad um repric but is more a targeted thing. And so we have this for instance for data for state access transient storage memory and also gas refunds. And the third one is supporting. So this is not actually repricing EIPs but are EIPs that are somehow supporting the other EIPs. And for these we have two for fixing rounding errors and also the multi-dimensional metering. Um and so now in terms of um prioritization the way I'm thinking of it is first we need to um do the broad harmonization.

So this is where uh we will harmonize compute state taxes state growth and data. So these are the four components that are really really important for us to repric and we have to do them together. So we make sure that we are not introducing a single resource as a bottleneck. So we are harmonizing within the resources um or in in another way we are harmonizing each resource. So the operations in each resource but also we are harmonizing across the different resources. So um we are not um leaving any bottlenecks on the table.

And then once this is done, we can think of adding some pricing extensions that either address specific gaps or enhance scaling. And we can think of it like the the removal of refunds from uh from the block limit which um solves uh some worst case blocks the size base s transient storage rounding errors etc. But I would say like this first broad harmonization is really important to do it together so that we don't create new new bottlenecks. We don't leave these bottlenecks on the table.

Um and so on the docket today we have all these EIP. So again um I will give five minutes each. Um and we will start with Ben uh talking about uh reducing treating transaction gas. Um Ben, I will stop sharing and I will give the floor to you. >> Okay. [clears throat] Uh send a request to share.

Okay. Let me bring up things open. Sorry. Okay. Um so the intrinsic gas of a transaction is essentially defines the the lowest um amount that we can do. the lowest amount of gas we can we can use in a transaction and therefore it directly uh determines transactions max transactions per block and also um uh transactions per second. So it's and

it's quite high at 21,000 gas. So this this looks to decompose it into uh parts and then um and also reduce it as that. Also there's a a weird gap in um which might be factored into the 21,000 gas at the moment where you can create an account um as part of that initial transaction and it's no different. you you aren't charged any extra than if you don't create an account in that transaction.

So, this harmonizes that with core. So, the the transaction base cost drops to uh 4,500. Um although that's very decomposed. So, if you do an ETH transfer since you do an update on um the two account and a warm that that's actually uh 6,000. But if you were doing like a contract call with no value transfer, then that would be your base cost and you'd add the execution on um and then it adds uh the gas for a new account if you're creating account as part of that um and it introduces um a cold cost uh for no code. So if you if

you if you warm an account and it doesn't have code attached um then when you're calling it you're not having to load that code start up the VM uh the EVM and then start processing op codes. So that's that's cheaper. Um and then also to bring the call value cost. So at the moment if you transfer a value in a call that's 9,000 gas and instead it brings it down a match uh this which would be 2,000 two two state updates one for transferring from the the sender and um one for receiving it.

So, it introduces a state update uh at 2,00 gas, sorry, 1,000 gas. Um, and so on this is sort of a 367% uplift in the amount of transactions you can do at minimum size. although it only the the equivalent gas based on all transactions is only 20%.

Because um there's less of that that's used for um e uh transfers specifically. Uh if I can show you some graphs in here. Um so like a USDT transfer. um that changes from the the dotted line to this red line here. So it's not it's not a huge um increase in the amount of uh those you could do for like a CD um transfer which is much more gas gas efficient then it's a much bigger uplift and for ETH transfers it's it's like a huge uplift um in the amount you can do.

yeah that's that's essentially it. There's a lot in in the proposal sort of explaining it um motivations that's like you know encourages ETH there's money uh it lowers the friction in transferring ETH and using ETH as part of transactions. So there's lots of good stuff. Um you don't charge it as whole data. Um the the transaction envelope and you count the to and from addresses is warm because they're like in the transaction header. Um so there's no additional additional data.

Uh if I do the breakdown. Yeah. So breakdown is essentially EC recover uh 3,000 gas um state update which is um updating the balance charging the gas. So, it's like a single leaf update counted. Um, and then no code. Oh, sorry. It does. It does a charge for warming. Um, and then no code warm, which is um if you're an EOA initiating the transaction, then you don't have code that you're loading. Um, that's

where the the 450 comes from. Um, and then if you're if you trans if you're Yeah, there we go. Yeah. Yeah. >> Um, okay, Ben, I think your five minutes are up. Uh, but, uh, maybe I can give one more minute for comments. I don't know if there are any um comments also be free to use the chatar.

>> Yeah. And then just to very briefly say because I think it's important enough I also put it in chat. I think I I really like the EIP in for the general hey we should consider also adjusting the base cost if we are repricing everything to be in sync. Just again pointing out for for people for whom that's not fully full fully top of mind yet with repricing in general there's always this question what do we anchor to right because in principle you could re harmonize everything and then everything costs one gas or you could harmonize everything and then like all the like all the operations cost a million gas each or something basically like it like harmonizing just means relative to each other. So you still have to have like some sort of like absolute level at which all the prices are basically. And

so we could also just choose that we rescale everything so that say um at least the the base transaction I think we also now want to separate out transactions that do create new state at the at the recipient or that don't but that the a base transaction that does not create new state comes out at 21,000 again. That that could be a reasonable choice. But basically, I think if we're not choosing to to to rescale everything to exactly that level, then I agree with the intention of the EIP that we should then also adjust the the the transaction based price.

>> Yeah, it's sort of um the the current prices are scaled to um easy recover using the >> great. So I think if you have any more comments um please just uh put them in the chat. We are now moved to the next one which um I'm presenting. Uh so I will just share again my screen. Um so this is a I think it's one of the most recent EIPs. It was done together with with Charles and is about introducing um warm account rights.

Soation is essentially when an account is updated multiple times in the same transaction the state root calculation can be batched and all updates can be done in a single calculation. Um and my understanding is that this is the standard um operation of of all clients. Um however users are paying the full cost of the cost call value or gas storage update if we are updating uh a slot. Um and so this doesn't match the actual um resource utilization because the first account update should be more expensive

than the the the later ones. Um and if we can make this um adjustment making warm account rights cheaper would increase throughput on these uh specific transactions. So the transactions that would update the account multiple times. Um and the proposal is uh is simple. So we will uh replace these um this uh gas call value and this gas storage update with two new parameters. So we have the gas cold account rights and a gas warm account rights. Um and the first uh account update essentially pays the cold cost while any uh following account

updates uh pay the warm cost. and to and we need to check uh whether the account is warm or cold and by that we need to track the whether any of the account fields uh were changed since the transaction um started um and um this uh pricing would impact the create create the call up codes and sar um so this is really short um so I'm giving some time for for comments and I yes if you have any comments just um let me know and we can discuss Ben

>> um for the um call account um account rate I do have that adjusted in the the the EIP I I previously presented >> um >> that [clears throat] sort of factors in that in terms of there is a there is a a warming cost which would would go away. But the um in it I do have the uh the two storage rights charged the same regardless. There's no like so there's an extra s charge if you warm an account. Um but if it's warm it doesn't become dramatically cheaper other than

the fact it starts starts dramatically cheaper but um and that's so that um the there's that stipiten um protection that exists in some contracts for recursion. So, it's still it still comes in about 2,000 >> gas, which means you can't do recursive pulls if people are are having it's like a DOS protection. >> Right. Right. So, I think that's that's a relevant point. So uh we still need to do some so we we still want to benchmark these and and and make sure that these costs make sense but that's um and like a vector that we need to take into

consideration um depending on the final numbers. Um, and >> yeah, just on this point, I personally think that if we are serious at least about making pricing changes to the EVM and maybe also continue to doing them beyond Gumsdam, I personally think we just have to be okay with breaking all the implicit assumptions that contract developers have made about specifics of gas pricing. And so it was never a correct behavior to use gas price assumptions for example for re-entry protection right like you have to have an explicit guard and just is just making some assumptions that certain operations are so inefficient I'm not sure and not I'm

so sure that I understood Ben correctly but basically these types of patterns I know they exist sometimes in the EVM but again this is just improper behavior anyway it's just based on assuming the EVM would always be inefficient enough that these things would be expensive enough that that that that would hold. I personally think we should bite the bullet of >> I think I think it was um suggested as like um a thing. So like the solidity at one point was had a you could call transfer and it had put a gas cap on so you couldn't do the recursion. Um, so I think we'd break a lot of potentially large value holding contracts and they'd

get hacked. However, [clears throat] I was just saying that I I take that into account in the other one and it's not the the price is is dropped very significantly and it shouldn't it should also maintain that um assumed invariant. But I mean that that that's also where the payup code um people want to bring that in is so that yeah to to also do that >> right so I think conscious of time um I think we'll need to move to the other presentation I know Carl you have your hand up so I will ask can you uh maybe uh add your comment in the chat

>> yeah okay >> I'm sorry about that um and I think Now we have Y talking about size based storage pass uh gas pricing. Um so I give you the fork y >> uh thank you. Wait um same thing happens every time I look from my window. Here we go. okay. Can can you see it? >> Yes, we can see it.

>> Okay, cool. Yeah. So that's um that's an IP that is quite simple. Um if you omit the fact that there's a transition involved, but the transition itself is uh is quite simple. Uh it's um it's just trying to target those contracts. I don't know why. [clears throat] Okay. uh I it try it's trying to target those contracts that are effectively spammy meaning they take a lot of space uh but they don't really provide much value and uh we have noted that some contracts were uh so large that updating them was uh causing uh measurable per performance issues uh

so that that goes against scalability and you know if it's a very useful contract it makes sense to to keep it running, but when it's just spam um it's um it's counterproductive. Um and everything um everything relies uh around like goes around the fact that it doesn't matter how much uh data you write to to a given contract, the price is exactly the same. Um and the the result is that the state bloat uh will be uh will increase not only with uh with valuable contracts but also contracts that uh that provide no no value and uh this is this is a

scalability impediment. So we want to to stop that. Um so the solution that has been proposed um is uh about counting the consisting in counting every storage slot inside the inside the contract and past the threshold um we start charging uh more gas per sort to to disincentivize the the filling of of some of some very large contract. So the the threshold could be moved over time. Um so currently would be only targeting a single contract on mainet. Uh but yes, if more spammy contracts come, we could we could change

this this threshold or if useful contracts grow larger, we could also uh move this threshold uh up. Um yeah, so the the the biggest uh takeaway point here is that for for most contracts, in fact, virtually every contract on mainet except one, the gas cost would remain exactly the same. Uh but yeah, one of those contracts would pay um I says it says incrementally more, but it's actually exponentially more uh per slot than uh than we we would uh yeah like the goal is to to keep them from the from doing sorry to to make sure they they stop doing this.

Um so yeah like the the reason for for this and especially doing it now uh it's simply because we do notice an impact of uh this specific contract on scalability and we want to to make sure um it doesn't impede the the progress to in terms of of scalability. Um but uh yeah we also uh there are also other reasons that are more uh about the feasibility of it. It's uh it's uh quite easy to do. It's uh also um having a desired effect like good good uh effects like forcing people to or contract designers to to break their

contracts into smaller pieces which are easier to recomputee, easier to uh expire and uh and ultimately uh easier to to manage. Um, so like I said, there's a transition aspect to it and uh we just have to add a slot counter per account. Uh, there's no other choice than going over every single um contract in the in the state and updating them. Um, but uh for that unlike the the vertical uh transition, we would be using a smart contract. So it it offers um a lot of features um in

namely the reorg awareness that you could be using inside the sorry to to to handle reorg. Um so we in that contract we would store the the pointers uh the the it the pointers of the iterator and uh just one last thing it's uh it's compatible with the the same sweep that has to happen in 2926. So we could do both in one in one uh in one go. Um yeah, just to recap, but I'm also at time. So maybe if there's time for a question or uh yeah, just call it.

>> Yes, I I I think we are right on time, but I I will give a one more minute for comments or questions if there are any. >> All right. So would this not be on the account but be in a smart contract? >> Come again. >> Uh the count would originally was a value on the account. >> So it's it's a value added to the account. Yes.

>> Okay. >> Yeah. Let's go. >> Yeah. And just to say right like the attractive part of this of course would be that if we don't do this then every contract even one that has only like very simple storage would basically have to pay for the worst case basically have to pay for kind of a zen style storage layout which is very unfortunate and would would be extra cost. So this is like a very attractive efficiency improvement. I personally still have some headache or like some some worries about basically just the complex as I said you introduced it with simple complexity but like I still have some headache about like the complexity of the mechanism how easy it would be to like to establish to

to really be certain that a the transition itself and then b also like once it's live that there's no kind of um ways to exploit it too much or no edge cases that we that we didn't cover but basically if we can get to a level of being certain about this then in principle I think it's a very attractive EIP So, regarding the transition, it's a simpler version of the vertical one which has already been tested uh extensively. So, yeah, I don't think I mean, okay, I know there's a lot of people uh who haven't looked into the into the vertical transition that uh that uh are scared about this, but honestly, given how simpler it is, I'm not uh I'm not too worried.

>> Okay. Uh Ben, >> um yeah, on the on transition, it would need to be coordinated in order to all the clients change prices at the same time. Uh but I I just like to say the original one was based on depth. Um, and I much prefer this one based on count because the depth um, it ties it to a certain structure and assumptions with that structure whereas the the count doesn't um doesn't assume an implementation detail if you see me.

>> You can go next. >> Yeah, my question I think Claus already answered my question. I was asking what the what the threshold was um that you had in mind there where only one contract was affected. Is that the same contract? Basically putting the threshold there. >> Um yeah, I'm trying to not name it but yes. >> Okay. Okay. And I was I was interested. Yeah. This this fee is a bit arbitrary. It would be interesting to to uh see how the distribution looks like because I imagine it's like very um right skewed and has like a long tail and then at

some point you stumble across those very big contracts. So maybe we could even be more aggressive, right? But yeah, or have it like dynamically growing somehow. But this is not just thinking out loud. I mean it will be dynamically up to a threshold but if you want to lower the threshold yeah I mean Maria will have some something to say about this doesn't make any difference to me um will make a difference to you the user of course but yes that can uh that can be calculated if you want >> yeah the the next one after zen I think is UST so we'd need to be careful around there >> exactly >> yeah I think once we have the benchmark

data, we can start like putting numbers u on the parameters and then we can discuss u more deeply what what what is the ideal thresholds there um okay conscious of time we'll move to the next one so now it's me again I'll be presenting to EIP um so I'll just share my screen again okay um So uh this one is the state creation um harmonization.

Um so essentially the motivation is um I think I explained this a little bit before but if we don't change anything a higher throughput in the VM will essentially lead to more state growth because uh more transactions come in and more transactions that uh grow state will come and so the we'll have an acceleration in in in in state growth and um looking at uh the uh more recent um data we can see that state growth has a median of um 74 uh gigabytes per year.

Um so we are adding a median of 74 gigabytes of new state per year. If we were to proportionally based on the on the current block limit, if we were to proportionally uh project that to uh the 100 million block limit, this would be 197 gigabytes per year. So this will actually give us less than 2.5 years to reach the 650 gigabytes uh threshold. Uh which is worrisome. Um and so this is the key motivation for why state creation should become more expensive now. But also uh we recognize that state creation is

itself not harmonized. So for instance creating new slots is more expensive than uh deploying new codes and so we need to harmonize this better. So the proposal is uh fairly uh straightforward. So essentially we are setting a unit cost per new state bytes and these um costs targets an average state growth of 60 gigabytes per year at the block gas limit of 300 million gas units. So these values can be discussed and the way the point where you put them will have a big impact on the level of repricing. But these essentially trying to futureproof

um the um scale the scale we'll expect to have in the next year. So we we have enough time to um have a more longer term um solution for state growth. And with these new costs, essentially contract deployments will become 10 times more expensive. Slots are will be around three times more expensive and new accounts uh get an increase of 8.5. Um and there's a caveat here which is because now contract deployments are so much more expensive. uh we are actually the limits on uh a limit on the uh size of the contract you can deploy from the

transaction limit. So Fusaka has this 60 million um units for uh a transaction. You cannot a single transaction cannot use more than that. And that limits and this pricing we would be only able to uh deploy a six um TP contract. So very small uh contract and so for that we are also this proposal is also introducing an independent metering for the code deposit cost. So, it's a a a simple version of multi-dimensional metering essential.

And um yeah, we still have two minutes. So, if you have any questions, comments, I'm happy to take um yeah, I'm just I'm not sure how I feel about this. it mostly from the increase seems uh very large I don't know >> right so I think the point where we can argue is this one right like where do where are you setting your your target um maybe we can discuss that we can have more than 60 gigabytes per year or maybe

you can argue that 300 the 300 million gas units is too aggressive and then that will have a direct impact on the cost. Um but I think this is the points we should be discussing and not the level of increase because the level of increase is in isolation. Um I don't think this is meaningful like we should be discussing the first point. Um yeah I mean we could also factor in like you know what's the improvements in hardware over that over that time as well >> right >> it's it's just the user impact you know would it would it make the would trying to limit state growth

that much with the prices would it cause the chain the user experience of the chain to become like if somebody wants to get a new token that will create a new storage. Yeah, I don't I don't know. I don't know how I feel on that. >> Storage slot is only three times, right? Like the the the worst is actually contract deployments which I think it's sort of more manageable uh because it's something that is not done as much for the new accounts. You could also argue that eight times is too much. Um >> I mean I'm I'm less probably less worried about new accounts. Um and contract deployments then well obviously six kilobytes for contract but um yeah

then the new storage slots as they're a more common thing that regular users would experience. Um but yeah I I I don't know if it's Yeah, I'm not saying it's bad. I'm just saying uh have concerns. >> Yeah, it's yeah, it's something we need to to think about. Um okay, so conscious of time, we'll move to the next one. If you have any comments, please use the chat. And the next one is the state access um harmonization.

Um so here the motivation is essentially we know that the state access operations so reads and rights have been deteriorating due to the increase in the state size and we know that state access is a known bottleneck for higher throughput. Um in addition to these things and we know that uh block level access list and EPSBS will impact the relative costs that state access has to data and compute. And so we need to repric things to be first in line with the current performance of these operations and second in line with these two new new

changes that are um changing the relative costs of of of these operations. And so the proposal is fairly simple. is just we are doing a broad repricing on on all state gas parameters or state access gas uh um parameters and uh we'll use state uh benchmarks to uh the final numbers and this has an impact on sar slo the call up codes balance self-destruct and the x um up codes um and when compared with 8032 which was the proposal that kon talked about uh uh earlier. Um this essentially would

assume a worst case contract size. So we are not fully unlocking state access scaling. So if we were to implement AT32, we would be able to make some operation or some state access or in this case state access to smaller contracts cheaper than just implementing this proposal. But I say this proposal is the the base. So we are doing an full uh a full harmonization and then um 8032 kind of unlocks this um additional scaling by um allowing us not to price on the worst case but um have that um differentiation

um and yeah this is the proposal so I'm happy to take any comments. I think we still have some time. Okay, if there are no comments then I can stop share and we can move to the next presentation which is from Carlos about contract by called um um by duplication discounts.

>> I I made the same presentation uh like on Thursday. I can I'm happy to do it again. But if people was there and we prefer to discuss directly or something like that, I'm also happy to do that. Anyways, if if if you want me to do it, I I can definitely do it. Maybe what we can do is like is anyone on the call that really wants to see the presentation? Uh please raise your hands and if not we can just discuss it. >> Okay. So Angar is asking for a recap.

>> Yeah. So the the recap or the TLDDR is basically uh if we do all of the state uh gas price increases uh what what will essentially happen is that in things like deploying a contract we are charging a outrageously unfair amount of gas to the user when the bite code is duplicated. So nowadays every single client when they have to uh deploy buy code that already exists they charge the user the same price whether the by code is duplicated or not but they actually perform the duplication so they don't store the by code twice which of course makes sense. um does it

doesn't make sense for the user to actually pay for that especially when a 25 uh 24 kilobyte contract uh potentially will be like around a 100 bucks uh with the ETH price at 4,000 uh which is a considerable amount of money. Um this also paired with the fact that uh account creation costs will go up and that we should indeed uh try to encourage uh uh let's say re reuse templates and this kind of stuff and also paired together with the fact that with Hans analysis we clearly saw that um the 97% of the bite code that it's deployed in Ethereum it it's

basically like duplicated. So the contracts are just complete copies bite code wise. Uh I don't think it makes any sense to charge uh users uh that that amount but yeah that that's the deal they are basically >> and maybe a question then from my side on this um again one of those optimizations that I think makes a lot of sense. One unfortunate aspect here is that right with EUF what we were thinking about doing was having like a nice separate code section within contract code and then the code section really could be identical anytime you have the same contract deployed. Um without this uh obviously the problem is that like solidity usually in like

basically puts constants that are defi that are defined at at at deploy time uh into the the bite code itself. um not not every contract uses that but but many many do. So I don't know tokens or something have the token name and the number of of of um of digits in in in in the in the code and so they are all slightly different from each other these kind of things. Um, so so basically I'm wondering right now do we have a good feeling of like what classes of contracts this is basically useful usable for because of this limitation versus kind of what classes of contracts cannot make use of that?

Have we like do do does does the solidity team have a take on this? Would they for example then at least stop using constants in in the code to to more make the use of this? like do we yeah do we basically have a feeling for the kind of the practicalities around this limitation? >> Um it would certainly like all unis swap v2 and v3 uh liquidity pools for instance they're all duplicated contracts and they use the in code to set the value. It would encourage people maybe to use more standard contracts also. Um, and then pass cuz you could initialize

like token name and echer and so forth in the in it code rather than in the contract itself. >> I completely agree with what B said. Uh, I I don't think there's really any heavy push back or or or any like issues. I I think the only issue or discussion is more like the UX problem but besides that uh most of the contracts or yeah contract accounts share the same exact bite code. Anyways uh if Han was looking at that if I remember correctly the number was 97%. So I think most of the people that deployed these contracts

will definitely benefit from that. And if we can move towards safer and more common standards, I also think it's a it's a victory. Uh anyone is free to of course keep deploying whatever they want. Uh but if we can coers to having more standardized things, uh it makes analysis of the state and a lot of stuff significantly easier to do. Do we have any client side feedback on any if is are there any complexities around this? Because obviously as you said right like in practice everyone already dduplicates locally anyway. Is there any complexity around basically like making this now enshrined in consensus about like what is and is not duplicated or is this kind of straightforward?

>> Well the exact point of this EIP is to make it such that the implementation for clients is trivial. uh meaning the it's the user who has the let's say UX burden to put it on some way to actually figure out which account holds the same bite code or code hash as the bite code that the user wants to deploy in this transaction right so this was chosen don't via access lists purely because on that way we don't actually need to make any crazy changes on clients of course clients uh in my opinion at least could uh optionally provide this reverse uh map that goes from bite code to addresses. This is something that a lot

of third party um providers uh actually give you uh to name one ether scan basically. Uh but basically that's the smoothest thing for clients at least in my perspective like they need to do very few stuff. Oh, are you saying you you'd additionally like to provide an option where you could just say copy this contract rather than having to put it all in cold data? >> Uh I mean I wasn't going that far. We can certainly explore that. Uh I mean you you need to I think you need to run the init code anyways. So I'm not sure

to which extent it will matter because after running the init code you already have the bite code. So I I don't think it's an optimization to load it from somewhere although you can of course do it if you want. Uh what I'm trying to say is I had to choose between forcing clients to implement a reverse mapping no matter what to actually make them check if every single deployment is deploying bite code that it already exists. um or instead we have the access list approach which moves the burden to the user and makes things significantly easier for clients. So I chose this route uh of course debatable but uh yeah this this is to go forward at the >> okay so conscious of time I'll have to

wrap this discussion and we'll move to the last presentation. So Gom is talking about chunk based code uh meralization. you can go. >> Uh yeah [clears throat] sorry I was just trying to answer uh Carl about the transaction type as well. Uh so while I load my uh my presentation I will just say that uh we yeah the the converse uh sorry the the transaction type means if you enhance uh further transaction types you will not be able to inherit all of that with the new transaction type. So I think it's uh it's better to do it this way. Okay. So as I said that it's just uh done

loading. Uh I hope you can see it. Um yeah so there's this uh old EIP uh 2926 that was revived uh it's about uh chunk based codealization and the idea is that uh the vertical tree EIP had many advantages but one of them was uh that it would uh introduce code code chunking and uh it came to like we we realized in Berlin uh that we could actually do that in the MPT and already addressed some of the problems. Um okay.

Yep. Uh and the problems being that uh first um there's currently a limit on the code size. You can only load uh you can you can only write code that is up to 24 kilobytes. And removing this limit is a is a bit of a problem because it takes more space in the database that you don't necessarily pay for. I mean, you pay at deployment, but you still need to pay for the loading. If you only need one bite out of that bite code, you need to download, sorry, you need to load everything in into memory. Um, there's the there's a mismatch between what it costs to execute code and the size of the code, which could be 24 kilobytes or hopefully more. Um so the CIP and the code

chunking in general is trying to to address this issue that you uh only read one chunk at a time. Um there are other problems including provers. Um it has been demonstrated that just doing Xcode size just getting the size of of the code means you need to load the entire code and and get the get the size of that uh of that bite code. So that's a good way to to kill every prover and in fact it has been done. Um and yeah in general we want uh I mean we uh in several ACDs people have come in favor of removing the the code size.

So doing chunking can can offer this uh um like offers a solution to this. Oh I forgot of course um the code has to be attached in the witness. So if there's no limit in the code, your witness will will also explode inside in size. Um so yeah, I already more or less explained what it does. It breaks the code into chunks and you only load one chunk at a time. So if you don't need to execute everything, you only load what you need to to execute. Uh you can do pre-loading and things like this of course, but yeah, ultimately you can better manage resources, especially if you remove the the code size. So what it does it adds two new fields uh the code size itself so that you can uh uh

perform the Xcode size operation without loading the code and uh it adds a code root uh that contains every chunk inside the Miracle tree so that you you can commit to this um and then like I said you only load codes that you sorry code chunks that you need uh and you pay for only the accesses you make so it's more uh granular is better in terms of resource usage uh in terms of uh of witness size and uh and also in terms of price because once again you only pay for what you use.

Um yeah, so already covered most of that. Better developer experience. Uh better scalability. You don't have to load a lot more code uh in inside memory. Um it's got potential smaller bandwidth because of witness witnesses uh being smaller as well. And it removes the the need for okay, it removes an attack vector. Um there's still the concept of transition. uh in fact it's exactly the same as the one in AT32.

They can be both done at the same time with exactly the same complexity and uh yeah it's just about uh calculating the code size and the the code route uh and then of course and every new contract uh will already upon creation activate this and and lift the max code size. Um that's also pretty much it. Ben, you have a question? >> Uh, yeah. If if this was used as the actual internal representation for the clients, would it be significantly slower to load contract code? Because like 20 if it was in 31 by chunks then for

a 24,000 by contract if you used it all would be like 800,000 reads. Is that correct? >> Yeah, >> I mean that's an internal implementation detail. Um, clearly it [snorts] would make sense to uh organize them by pages. Um, so you could uh you could pull several several uh code chunks together uh inside a single database key. So there's a there's a sweet spot that will depend on the database system and the database model um where you can uh you can have several chunks pulled together and try to not load everything at the same time. Um yeah, sorry I kind of forgot the initial

question, but overall the the idea is that uh it's it's an implementation detail and the the goal is precisely to reduce this the the performance impact of loading big code. >> Okay, thank you Bom. And we are on time. So I will just uh remind everyone that next week we have another uh call where we go through the remaining EIPs. Um if there are any more discussions or questions or comments um there's a discord channel called EVM pricing. Uh I will uh ask you to go there and and and

discuss. And are there any last comments or thoughts before we wrap up? >> Okay. So, if Oh, >> yeah. Just one thing that confuses confused me. The 8058 that Carlos presented, I don't see it on the PFI list. Is that still going to to be on there? Um because as as of now it looks like to me at least that it's not proposed for Glam Sadam.

>> The PR was approved by Stokes but I maybe it's not merged yet. >> Okay. Yeah. So I just wanted to check if if it's in progress of being proposed then that's fine. I just I just was confused that it couldn't find it. Awesome. Awesome. Thanks. >> Um thank you so much for joining and yeah we'll see you next week. Thanks, Marius. See you next week. I have one. >> Byebye.