EIP-7623: Increase Calldata Cost

Transcript

in most of the cases you will be refunded the additional gas or they even don't realize that the exchange actually is charged for it through gas the worst case that could happen would be no one looks into the EAP and everyone keeps everything running as is so there are a lot of upcoming changes that might tackle the eel and I'm super happy to chat about those [Music] welcome to Pip this is the podcast where we make ethereum simple by breaking down complex Concepts proposals and research

updates into easy to digest inside for the community you're listening to episode 140 brought to you by ethereum [Music] caters I'm your host rjan and today we are diving into an intriguing proposal EIP 7623 increase call data cost if you are not familiar with it documented in February 2024 EIP 7623 is a standard track core proposal currently in review status The Proposal aims to adjust call data cost on ethereum network addressing efficiency and other issues currently

marked as consider for inclusion EIP 7623 is active on devet and it has been a Hot Topic within ethereum magician and developers community in this episode we'll explore the details of EIP 7623 its application and potential impact on ethereum's upcoming Network upgrade and to guide us through it we are honored to welcome one of the co-author Tony w St welcome Tony and thank you for joining us on Peep and E yeah thanks for having me we are excited to learn about the proposal hear your perspective and insight but before

we get started our community loves getting to know the Mind behind the work could you please share a little bit about yourself the project you are currently involved in and your journey within the ethereum ecosystem yes I'm happy to do so so my name is Tony I'm with the eirm foundation now for over a year and I joined the firm ecosystem in general in early 17 so this was right around the the Ico hype was just around to start and I was still on bitcoin for most of my time and during the block size debate which is very interesting because it relates to today's topic so during this

blocksize debate on bitcoin I'm more more shifted my focus to ethereum because I just thought it's way more interesting there's actually things happening with the icos with the first smart contracts that actually were capable of doing some stuff and this was kind of my etherum moment where I was like yes this is the the ecosystem I really enjoy I really enjoyed Building open source stuff so I started with a lot of privacy work tried to contribute to different privacy protocols and in the end last year I joined the airm foundation to be more specific the applied research Group which is a group that mainly focuses between Bridging the

Gap of between theory and practice and EAP 7623 was then also my first EIP that is great so I'm happy to know that ethereum attracted you more than Bitcoin it is inspiring I am looking forward to have more researchers and developers joining the ethereum ecosystem moving on I understand we have got a presentation today so without further Ado let's peep in great yeah super happy to be here today to present EAP 7623 um with the naming increase called data cost um it's a EAP by vitalic and

me and just to give you a very quick tldr um most of the things we've already covered in in the intro now but EAP 7623 was created almost a year ago um on the 13th of February um 2024 with the goal to reduce the maximum block size in order to reduce the worst case bandwith requirements and the current status is scheduled for inclusion so this means it's very likely to happen in Petra if nothing terrible goes wrong now and it's also already included in Def 5 so if you look at today's definite 5 you should already see the code um of 7623 being

included in there and just as a rough outline of my presentation today I want to first talk a little bit about the block size so what is actually the block size and how do we measure it then focus on 7623 and the mechanism behind it and finally looking into the specs see how 76 tropy was eventually implemented great so let's get get into the topic so what is the block size and this is already a question that is super important to answer when we talk about things like gas limits things like call data things like the maximum potential bandwidth requirements because it's not so clear when CFS talk about the maximum block size what is actually meant so for

example when we talk about the block size you could say Okay a block is 30 million gas large right this is kind of one metric how you could measure the block size another one would be to measure the Block in bytes we could basically say a block is one megabyte large so there are already two different approaches how we can measure the size of a block then the stack of the protocol is super important for example a block size is different when we look at the gossip when you look at the gossip protocol versus the engine API where in the gossip protocol most of the messages are compressed we make them as small as possible to make sure the upload and download

requirements for stakers are as low as possible whereas on the engine API this is not that important right so it's super important to consider where we are in the protocol when we talking about sizes because different stacks of the protocol have different mechanisms to kind of compress data or not compress it and this brings me to the third point on this slide here the compression very commonly blocks or messages data in general is compressed using Snappy so this is today's standard and I think everything that goes through the gossip is Snappy compressed as of today but of course sometimes when we

talk about the block size we actually talk about the uncompressed block size or we could even talk about uncompressed block sizes put into Json format which again to access the whole size so this is super important to consider here what are we actually talking about when we talk about the max block size that 7623 in the end wants to reduce because there has already been some confusion in the past among client teams when it comes to the maximum block size possible and very typically when we say the max block size we mean the snappy compressed block size measured in bytes so usually someone saying the max block size we should think about Snappy compressed blocks and

those Snappy compressed blocks they get big because of basically three things the first one is the gas limit and the gas limit is how we measure in general um very generally um the resource consumption per block so everything costs gas no matter if it's a storage access some computation or posting data everything is is measured in gas and as of today we have a 30 million gas limit and you can only do as much consume as many resources as the guas limit allows you to do so the second thing is the call data cost because the cheaper the call data the more you can fit into the gas limit which means the cheaper the

call data the bigger blocks you can build and call data we will um come to that later but it's basically the onchain data that we see being posted just as raw data but also data that is posted to interact with contracts and stuff and since EAP 4844 we also have blob transactions which can carry blops and blobs are 128 kilobyte large objects that also contribute to the block size of today so in the end we have those three factors the gas limit the call data cost and the number of blops that all together make up the block size but today I will mainly Focus about the first two the gas limit and the C data cost because they are most relevant when

it comes to EIP 7623 on this slide you can see a chart I created about a year ago when the first demand started coming up about increasing the gas limit and we were thinking about the maximum possible block sizes by the time so on the very left hand side you can see on the Y AIS the gas limit and on the x-axis the cheap call data and this is basically what makes a block big a block here consists of an El and a CL part whereas the CL part is usually very small so the CL part con contains everything that is concerned with the consensus layer whereas the E part which is often referred to as the execution layer

payload can be very big so this is already a very important learning that the cl part of a block is usually very small whereas the El part of the block can really expand and become very big and in addition to the CL and the eel part which can be summarized under a beacon block there are also lops and we as of today we can have up to six blobs per block which also contribute to the block size and then on the right hand side you can already see where we are going this is the proposal of 7623 already which is basically started as okay we want to do a gas limit increase and we want to increase the blob count

at some point so we might want to try to mitigate the negative externalities that come with big El payload sizes so what 7623 tries to do is not actually tackling the big block size but the Big E payload size which of course is part of the block and in the end then also contributes to smaller blocks and this directly brings me to the first topic here that is super important the gas limit what we can see here on this chart is the gas used per day since the launch of etherum we can see all the hard forks with vertical lines here and the important part here is everything basically that happened after the London

hfog so London hfog introduced EAP 1559 with the 50 million gas Target and the 30 million gas limit and since then we didn't actually see many changes when we zoom into this chart and only show the data as of the London heartwork we can see that since this is September October 202 2 we kind of plateaued and this was because of the merge the merge gave us constant slot times of 12 seconds which meant that we on a day-to-day basis we almost consume the same gas every day which is basically where we set the block gas limit so the summary here is

we didn't see a block gas limit increase since the London hardwork while of course the merge led to a few little more gas being consumed it actually didn't really act as a gas limit increase and around a year ago we saw those Community initiatives yeah appearing that proposed to increase the gas limit first to to numbers like 36 million which would already be a 20% gas limit increase and this is the starting point for 7623 it really started from the community initiative that wanted to increase the plock gas limit and withal me yeah evaluating the situation and

making sure that the El payload doesn't grow to sizes where we can't manage it anymore the next factor that is important when we talk about the block size is call data and call data simply speaking is nothing else than the data passed into the input field of a transaction call data is used for interacting with contracts for deploying contracts but also for posting data and especially the Third Point here the posting data point can because it's not directly a danger but it can become a danger for certain low-end stakers and it can in general it is a Dos Vector in the

network so call data hasn't seen many changes for years we are still at the point where we charge for gas per every zero BTE cold data and 16 gas for per every nonzero BTE of cold data and and this gives you a block size of 7.15 mtes or 1.7 mtes using the 30 million gas so this is a very simple calculation 30 Millions divided by four gives you a block of only zero bytes of course this is now the uncompressed size very important to mention at this point but this is roughly the maximum block size we are dealing with or this was at least the common knowledge what the maximum

block size is and in the end call data has impact on the bandwidth because the more call data the more you need to upload and download and also on History because call data in contous to plops for example call data is not pruned so it means you have to store it forever of course there are solutions to that for example EAP or Force but in the end right now call data is just stored forever and there's a great analysis by storm and torches I put the link here at the bottom of the slide that I can very much recommend to everyone who wants to get deeper into um the problems with history and how we can tackle those when we look at call data the

evolution of call data over time we see the following chart which actually in my opinion looks very cool because it's not very hard to tell when for8 44 was shipped so we see this dramatic decrease in the call data usage in the 99 percenti so those are the blocks that use the most call data and since 444 we not only reduce the call data throughput but also the volatility and this is already super important because before we had situations where let's say Staker number one gets a block with a lot of cold data the next proposer gets a block with only a little bit of cold data and there was a big volatility between those blocks and this was reduced during for8 for 4

and the interesting thing here is if we actually compare it if we actually add the number of blops to the call data uh to the largest blobs after 4844 and this is done here with another line which shows you that even after we shipped 444 the volatility stayed quite low and this is in Parts because blobs have a constant size of 128 kilobytes whereas the El payload size was very volatile so you could build an El payload that was a few few megabytes large whereas with blobs you always deal with those constant size data objects that cannot really that cannot expand in size or

everything so this is a super interesting chart in my opinion because it shows you that even after Ford 44 where we increased the throughput the yeah we didn't really contribute to much volatility and the volatility compared to before was actually significantly reduced to wrap this section about call data up I would say call data was initially super important for rollups it was initially used to post data so very important to bootstrap the whole rollup ecosystem but now it kind of became a burden because the data is not pruned and stored forever so there are concerns about growing history and as said EAP

for fors is a solution but until we have EAP 44s history is still a concern and call Dat that directly contributes to Growing history and finally the Dos Vector of course I could build a block as a block Builder that uses a lot of call data through MEF boost I would give it to the proposer the proposer would try to propose it but because of the T um the the large amounts of call data I put into the block the proposal might be reared out which means the proposal will get no rewards and this is a clear dos Vector for the network so this brings me back to the question what is actually the max block size of

today and for that I created this table here where you can basically see the different gas limits on the left hand side on the most left column and then different setups of zero bytes nonzero bytes and a mix of 29% of the gas used for zerob bytes and the rest used for nonzero bytes and then see how big the maximum block size can actually be and when we focus here on the first line which is what is the limit right now because we are still at a gas limit of 30 million then we can see that the uncompressed block size only consisting of zero bytes can go up to 7.15 megabytes and the the one with nonzero

bytes is 1.79 and the mix is 3.34 so what is important here is that the zero byte block is way bigger than the mixed block so almost more than twice as big right but on the right hand side we can see that as soon as we start compressing those blocks we get a different picture namely the block that contains only zeros can be compressed very well so we can compress a block from 7.15 megabytes down to 0.34 so this is a great compression for nonzero byes of course there's no compression we cannot really compress

random byes and then the interesting part here the mixed block that is eventually compressed is actually larger than the compressed blocks consisting of nonzero bytes and this was eventually what caused the aoia incident um some of the listeners might remember a aoia incident this was exactly what caused this aoia incident basically a block I created that was on the very right hand side that eventually kind of got over the limits we had in the engine API right and now that we know all about the block size how do we measure the block size and what contributes to the block size we can get into EAP

7623 which as I already started with talking about the block gas limit so in February last year there was I published this post on increasing the block gas limit and the post basically stated that a block gas limit increase would be nice but we should not forget about the E payload and the potential dos vectors that Big Blocks might bring and then there was a lot of focus and many people looked into that topic and this was one of the charts that valalik put into one of his blog posts that I found very nice to explain the actual problem so what we can see here is computation on the x-axis data on the y-axis and we see a

square that tells us what would be a safe block then we see a diagonal line that shows us the block gas limit and then we have those two red areas that say they're that say they're dangerous blocks that are still accepted by the network and what we mean here is that if we looked on the data side to this red triangle on the top left this is actually a block that is still accepted by the network because it's still below the gas limit but it's actually using so much data that it might become a danger for the network and the difficult part here is we actually want to get to the

orange part but on the same side we don't want to kind of introduce even more area below the gas limit that might end up with dangerous blocks and this is a super cool chart by metalic can very much recommend reading his post on multi-dimensional gas pricing that talks exactly about that and now EAP 7623 tries to solve this upper left side red area that is still below the gas limit so everything is still a valid block but we already at an area where we are using so much data that it might become dangerous so the EAP itself to summ

arize it I would say it introduces a mechanism for call data pricing that distinguishes between transactions that use a lot of execution gas and those that don't use a lot of execution gas but only use gas for call data so you have those users that use the evm for use cases like swapping tokens doing defi stuff um sending around nfts or ER c20s reaking predict your Market um most of potential use cases that require some computation being done in a smart contracts they use execution gas so they use gas within the evm let it be for operational for op codes like yeah for

all the different op codes for storage and so on and then you can also use gas for call data and we basically look at the ratio between execution G used and cold data G used and if this ratio is below a certain threshold you're transaction will have to pay more for the call data so transactions that are below the execution gas to call data gas threshold pay the current price and all other transactions pay more and this means that transactions that use call data primarily for posting data which was done by rollups before we had 4844 they will pay more gas than today whereas the average user will not even

feel the EAP and should get a way with paying the same prices as of today and just as a rule of fum you can think about it in the following for every six gas units spent on execution gas six gas units on execution gas for every zero bite and 24 for every nonzero BTE so this is the ratio which basically says if you spend enough on execution gas you get away with the same prices if you don't then you get higher prices and this works with the following formula the red part is what we already have today so as of today you basically pay the base cost which is the

21k and then you pay call data times the call data price then everything you spend on execution plus the contract creation this is kind of what you're charge today if you do a transaction with the adjusted formula we add this Max condition and this second part of the max condition which says call data times the higher call data price and you stay kind of you always pay the lower price including the standard call data price as long as it stays below call data times the higher call data price and the rule of f here is if a transaction used at least around 60% of

its gas for execution then the costs will remain exactly the same and to zoom in a little bit how the mechanism Works in detail we first one dimensionalize call data so a zero byte of call data is now one call data token whereas a non-zero BTE of call data is four call data tokens and this is just to make sure that in the formula we can have one unit for all the call data no matter if it's zero or non zero bytes so we keep this 4X between Zer bytes and nonzero bytes currently a zero byte costs four gas and nonzero byte costs 16 gas and now we have a Zer being one call data

token and the non-zero being four call data tokens so this relationship stays the same and then we have the standard token price which is exactly the same price as of today four gas for a nonzero bite and four XD for nonzero BTE and four gas for a Zer BTE and in addition to that we have this floor price that is new in EAP 7623 and the floor price is applied to call data tokens and in the end in the max formula we check is the higher price for the call data more than the standard price that includes execution and contract creation cost and if so we

charge the higher price and if not you will be basically charged what you charged today which is is the standard call data cost plus execution plus the contract creation cost of course I find it oftentimes much easier looking into the specs when it comes to um those formulas so I think it's it's way easier to understand the whole EAP looking into the specs then just going through the AP and when we look into the specs we can see that there is actually only a few lines of codes that had to change with 763 and the first occurrence of a change we can see it in the check transaction functions of the execution specs because

very early in the transaction we already check is that transaction able to pay for the floor cost which means pay for a higher call Dat price just in case right because before executing we don't even know if the transaction has to pay the higher price but at this point we have to at least make make sure that this transaction could in theory pay for the higher call data price because we don't know it yet we have to at least make sure the transaction is able to do so and importantly we don't deduct the floor cost directly from the transactions guess but we only have a check to make sure okay the transaction

would in theory be able to pay for the higher cost so it's fine and this is very important because this means for the user the users might will have to specify a higher transaction gas limit most of the users already have a lot of buffer there and are fine with doing so and the important thing here is I marked it as a spoiler here in most of the cases you will be refunded the additional gas so what do I mean I mean you have to specify a higher gas limit but all of this additional gas you have to use now will be refunded in 99% of the cases the second occurrence of a change regarding to 7623 is in the

process transaction and I would say in the process transaction function we see the main logic of 7623 being implemented this is already within the execution part of executing transactions and what we do here is after executing a transaction we take the gas that is left we substract from the transactions gas limit and thereby derive the execution gas used so at this point we know how much execution gas was used importantly this already includes the intrinsic cost as of the old formula as we do it today with the standard call data cost so we

have the execution gas and then we handle the refunds we substract the refunds as usual and at this point where we calculate the Flor gas cost we do exactly what we proposed in the formula which is we take the tokens in call data multiply them with the floor cost add the transaction base cost and then check what is higher is it the execution gas used or is it the floor gas cost and the user then the transaction then has to pay the higher of the both the execution gas used will be higher if the execu gas used by the transaction is in a certain ratio to the call data gas used so if

the transaction is what I call Pure call data transaction transaction posting data on chain without doing anything else with smart contracts then the transaction will pay the floor gas cost but if the transaction is actually a Unis swap trade or someone sending an erc20 to a friend then this transaction will pay the execution gas cost because the floor gas cost will be significantly lower in this case right and then looking into the table after pectra which assumes 7623 is shipped we can already see this quite significant reduction in Block sizes we remember earlier we had a a 30 million

gas block with only Z bytes of 7.15 meytes and now we are below three and the same applies on the very right hand inside for the compressed mixed gas used where we Ed 29% of the gas used for zero bytes and the rest for nonzero bytes where we had um around 2.6 megabytes before and now we are down to 1.07 megabytes so this was also the goal of course of 7623 to reduce the worst case block size and then the small add-on here is that we do so without impacting regular users and this was very important as I said users might

have to specify a higher gas limit but this gas limit will be refunded in the end because users will in the end or users should in the end pay the standard price because there execution gas will always be in a ratio to the call data gas where they will still enjoy the lower call data price so what we eventually managed to do is we lowered the maximum possible block size quite significantly without making making the life of everyday user more expensive so this of course brings the question who will be affected by this change and this is very simple to answer everyone who is using call data

basically to only post data so if you use call data without interacting with any contract or if you use a lot of call data and you only do a few operations in the evm then what what this means is you might have to pay more for call data and your transactions will become more expensive right and this already brings me here to the final part of my slide deck um there are a bunch of analyzers we did that yeah accompanied 7623 being included in pactra we did some analysis pre4 844 and some analysis post for it for four then I can very much recommend this block post by ethereum

2077 very good explanation of what 7623 tries to achieve and its impact on the network I did a Decon talk last year which was called I Like Big Blocks and I cannot lie you can find the YouTube link also here and finally this is something I found today so big shout out to let's get on chain I just saw on Twitter um that this user made a very nice summary of 7623 and even dived into ref implementation of the evm and showed how yeah 7623 was implemented in ref and also gave some high level info about the EAP in general right and this basically brings me to the end I'm very happy to answer

any questions if there are any and also for listeners if you have any questions if you need help for implementation if you're concerned you might be affected you might have a more difficult life after this EAP please reach out we did a bunch of analyzers there are tables where you can look up are you affected or not there will be more information yeah I plan to do provide more information um prra so in the upcoming weeks but for now I would say um a lot of analysis has been done and the EAP is in a in a quite good position for pactra as of now thank you for concluding with this Consulting statement because I know this

is one of the important question that comes up quite often when we are talking about changing something significantly and especially when is related to price gas cost and things like that so yeah I look forward to have all those research work that is ongoing and we' be happy to add them as an additional resources for people to follow overall it was a great presentation and I must say that I really love getting developers on pen because I feel like it is a good way to get the visuals of consensus and transaction mechanism on slides which is outside of the research paper generally they are just confined towards the research paper only so yeah great talk about that thank you thank you very much

we really appreciate you sharing this high level overview not actually high level because you also went into the spec which was good helpful for client developers I see some of the client developers on the call itself I hope this will at least provide Community to set an expectation of what is being shipped here I have a few follow-up questions [Music] so starting with my first question here you were explaining about the the floor cost this is something new that has been introduced I'm curious to understand what that be there for all kind of transaction or will there be a group of uh users who would be most affected with

this floor cost that would be added to their transaction right yeah so the floor cost cost is determined for every single transaction so every single transaction will have a floor cost the question is just will that floor cost be applied when it comes to determining the final gas usage of a transaction and initial analyzis show that around 99% of the users will not be affected by the floor cost which means they will have to be able to pay for it in theory so they will have to have a transaction gas limit high enough for the floor cost but in the end they will not be charged the higher cold data cost because for most users their evm gas consumption is

high enough to satisfy the lower call data cost and those users that are still affected are mainly users that either don't use blops for data availability so you you can still think about a rollup for example that is not using lops for data availability which which means they are still posting their data through call data those are users that are potentially affected and then the largest chunk of users are actually that are affected are actually those that we all know it if you withdraw from an exchange right oftentimes those exchanges allow you to write some data into the transaction which I don't know

if it ever made sense to do so but exchanges offer it and this is the largest chunk of people being affected those that have Hello World in their transaction data because the exchange allows them to do so for free or they even don't realize that the exchange actually is charged for it through gas but in the end it's data avability users that are still using call data and those more or less negligible users that are using yeah that are posting comments or messages into their call data and for them it's not that bad because if you have only a few bites of call data and you charge the floor cost this is still a negligible amount compared to the 21k

base cost so kind of paying for your 20 bytes paying 4X it's not 4X this was just a random number but paying more for your 20 bytes is nothing compared to the 21k base cost you pay anyway so those users I think they would not even realize if they would be charged more for the few bites of C data that is again very very much comforting generally speaking if there is a proposal which is not affecting to the major users is like accepted by the community quite easily so it's good to know that it is not being affected and moreover it also suggests that if you are being charged if you are adding higher gas cost it could be refunded

that's another point to be comfortable about this proposal I noticed a decent number of conversation on a fellowship of ethereum magician page which is like generally a signal of community's interest in this kind of proposal and it also sometimes invites Improvement suggestion I'm curious with respect to Specs how has the community discussion contributed in like finalizing the specs assuming whatever is there is finalized were there any significant changes to the initial draft and uh did uh you the authors of the proposal uh decide to make some changes based on the comments that were received from the community yeah that's a good question because we

actually did so the EAP if you go to the very beginning of the EAP it was basically a very naive call data so we just took the call data price of 416 and 4x both of it and this was the initial idea for the EAP but then of course we saw okay this is actually a bigger change than then we might want to do because it affects not only every user but also the tooling and everything so so at the very beginning it was already the goal okay how could we achieve the same without affecting everyone and then we very early on settled it for this specific formula for this conditional

formula with this Max condition that is now applied in 7623 and one of the initial points was if I remember correctly from E magicians was a point about the access lists that we don't want to create a situation where suddenly posting data into the access list would be cheaper than posting data as call data or something and this was then also fixed by just lowering the call data costs again so we had them much higher we lowered them again to make sure that it's still not cheaper to post in into an access list H it's still better to post into call data then the access list this was one of the comments we got on if magicians who

super helpful and another one was about gas Sheltering so this is a mechanism that works in the following you have two transactions one of them is consuming a lot of evbm resources and the other one is consuming a lot of call data today there is not really an incentive for those two transactions to be bundled together because both transactions are priced individually it doesn't matter how much EV v m computation compared to call data gas you use so this doesn't matter today but in a word after 763 it does matter and there could be an incentive for people

that have those big call data transactions to look for someone who has a big execution transaction and ask this person like hey could you please include my call data in your transaction posted on chain because you will get the low lower call data price because you have some execution involved whereas I would have to pay the higher price and this was one of the comments we got of course in theory this is a valid concern I would say and we also took that concern serious but in the end I don't think it's really a blocker for the EAP itself that that had the goal of reducing the maximum possible block size right and

this is very important to stress here that even if you play those games even if you create those markets where call data users can look for execution users and then bundle those transactions together which requires coordination which requires trust and you know it's not so simple to get that even then 7623 still achieves its goal of reducing the maximum block size so even if no one is affected by the higher fla cost we still achieve the goal of reducing the maximum block size and in the end we of course considered those concerns about about this gas Sheltering but it was not really um a concern that could yeah

block the EAP in any way that is good generally our expectation is like we get a lot more comments there comments not only just signal that people are listening to The Proposal but it many of the times like have given ideas to water as in this case so I'm happy to learn about the changes that has been added to this spec with respect to comments from the community so for listeners if you are an author please try to encourage Community to get involved on the discussion on Fellowship of ethereum magician pages and as Tony also mentioned in his presentation at the end that if you have concern please show up people are there and they would be happy to respond to

your question and we'll do our best to address the concerns moving on uh my next question is on the compatibility so I was looking into the proposal and it suggests that this is a backward incompatible gas repricing that requires a network upgrade of course it is getting into Vectra so it is going to be there soon it also contains some instruction for wallet developers and node operators that uh they must update gas estimation handling to accommodate the changes of the new call data cost rule so how as an author do you foresee the EIP implicating these existing smart contract infrastructure do you see any

specific challenge in adoption as per your anticipation yes so regarding adoption I would say the worst case that could happen would be no one looks into the EAP and everyone keeps everything running as is and then we could see some more fail transactions because they would be underpriced so as shown earlier in the check transactions we would check is the transactions gas limit actually able to pay the floor cost so even though you know I'm doing an erc20 account I did the math I use that amount of execution gas and I use that amount of cold data

gas I will not hit the floor even then you must be able to at least be able to pay for the floor with the transaction gas limit you specified so this is a very simple thing to do for developers to change that to make sure that that transaction is able to at least in theory pay for the floor cost but then as of this point everything should be fine so there are no surprises after making sure you are theoretically able to pay for the higher floor cost the other thing that could happen if you're um surprised by the EIP suddenly which shouldn't happen because there is a lot of work to inform everyone like this this um episode here but if you're surprised suddenly that

you pay a little bit more gas for your transactions then it could be because of p76 to free and your transaction is hitting the floor for every user that is using Unis swap that is using Ava makad da and all those daps sending around ear c20s sending around nfts and so on so almost all the use cases you could mention here they will very likely not even feel any difference because maybe they will see the difference that their transaction gas limit is actually set a little higher but then they can see okay after the transaction the gas consumed was actually exactly the same so in this case I don't see any surprises here that

is good and having specific instruction is also helpful that if changes are done on wallet level that would be like most user won't even feel differences over here uh very well I remember this article of block native in 2024 where they were talking about how Le to overpaid for the time when gas was like very very high and elto could have switched at that time so I'm wondering with respect to rollups heavily relying on this call data for ofin competition what would you say is the impact of EIP 7623 on their economics and visibility yeah usually rollups shouldn't be affected at all so the let's say the standard rollup of today

no matter if it's an optimistic rollup or a CK rollup they would already use blops there are some use cases and it's worth to mention them for example Starks if you use Starks instead of snarks then you still need some evm computation over your data which means you cannot really escape to blobs and you will still have to rely on call data which means that for rollups that cannot use blops for certain reasons for example because they want to maintain the postquantum seeress and don't want to snark their Starks for those rollups it will mean the operation

will become more expensive so there is really nothing we can do about that of course one can argue that of course the burden on the whole network is very high because posting a lot of call data is a lot of work for the whole network and therefore it's just fair to price it higher but it's definitely worth to mention that there is this use case that not every europ not using blops is doing something wrong so there are especially thinking of star this use case where you need the computation where you cannot really Escape DM very interesting I hope that would be worked out and we don't see any challenges over there as well well we

are getting closer to the time so I think that's mostly done on the questions which are like uh long answers [Music] questions we have recently started this new section called rapid fire question and here we try to get answers from you in either one word or one sentence but that has to be done in less than 1 minute so are you up for it okay yeah let's let's go all right ethereum in one word I would say freedom most underrated feature of ethereum I would say self custody one thing ethereum can improve

on there's currently a lot of ideas floating around let's say streamlining one word to describe def magic nft in one word interesting most impactful layer to Solutions I like based rollups very much just because of their alignment with the L1 let's not focus on a specific company but just say based rollups future of onchain governance in one word to secret to balance governance and decentralization value alignment so kind of having the right values what excites you the most about ethereum in

2025 very excited about Petra of course apart from that also very excited about the EAP 7702 and all the ux changes I hope that also my life as a as an infer mus will become significantly more comfortable through that and apart from that the conferences def connect right and this is the final question it's my added question that is one word that comes to mind for PE education perfect thank you so much you did great definitely not in one minute but I'm happy that you have answered so much question honestly and whatever time it

take it all good well we are hitting to the end is there any final message or comment or anything that you would like to share with our community just to repeat myself if there are any questions by the listeners I'm I'm sure also I'm speaking for me and vitalic we're happy to answer any upcoming questions if you have any questions if you want to chat about the implementation or also if you're interested in the topic itself there are many ongoing efforts like multi-dimensional gas pricing there is this password being thrown around the making the E great again or stuff like that so there are a lot of upcoming changes that might tackle the eel and

I'm super happy to chat about those very well thank you Tony wter for taking our time to share about EIP 7623 I'm excited to see this proposal is plan to be on the main net with the Petra upgrade that brings us to the end of today's episode of Peep and and I hope this discussion on EIP 7623 provided valuable insight to the community about this proposal and its potential impact on the ethereum ecosystem thank you for joining us here today thank you very much all right uh Dear Community we would love to hear your thoughts questions or feedback reach out to us on Twitter and join the discussion on ship of ethereum magician

don't forget to subscribe this podcast so you never miss anything new upcoming in ethereum's latest development thank you for listening we'll be back with another fascinating proposal to explore until next time keep learning keep building and keep perfecting the ethereum locked in this is Puja ranjan signing off