EIP-7706: Separate Gas Type for Calldata

Transcript

once we have 7706 then of course we should just delete I think realistically 7706 could get us potentially 2x gain potentially a little bit more safely ethereum's technical trajectory is actually looking very bright for the next few years people will be surprised by how quickly we can accelerate on actually implementing them for 2025 the priority just has to be [Music] welcome to P peny the podcast where we explore ethereum Improvement Proposal

with their author diving deep into the purpose impact and why they matter for ethereum's future this is episode 142 brought to you by ethereum cat [Music] hurters I'm your host Puja ranan today we are discussing EIP 7706 a proposal that introduces a separate gas type for call data documented in May 2024 The Proposal is currently in the stagnant status meaning there hasn't been any update in the last 6 months however that doesn't mean the proposal isn't valuable sometimes great ideas need more time before they get momentum so what exactly

is EIP 7706 and why should we care to help us unpack this we are joined by none other than the author of The Proposal himself a Visionary whose contribution have reshaped not only blockchain technology but also the way people worldwide think about decentralization open Innovation and financial sovereignty it's an absolute honor to welcome someone whose ideas have driven some of ethereum's most pivotal upgrades ether co-founder and deep thinker vitalic ban vitalic it's a privilege to have you here thank you for all you do and thank you for joining us on Peep

and thank you so much for inviting me bjan pleasure is all mine so generally speaking our format typically includes a brief introduction before we get into the proposal but vitalic need no introduction to our listeners he has graciously joined us on Peep and EP in the past to discuss gas C optional access list and the partial removal of refunds Al upgrade and the block gas limit so he contributing his invaluable insight to the etherum community vitalic before we dive into EIP 7706 may I request you to share a few word about what you are currently working on in ethereum and Beyond protocol

development yeah so within ethereum and one of the things that I've been thinking quite a bit about recently is scaling strategy right that's a topic that's on a lot of people's minds um I think the big success that we've had in 2024 is of course laer twos have uh increased by a lot in the amount of activity that they're supporting um in their security and their maturity two of them have reached stage one and where there's a third one that reached stage one recently so there's a lot of positive momentum but at at the same time there's also a need for ethereum's technicals to continue to rapidly

advance in order to make sure that we're able to actually accommodate a potentially much larger amount of demand that could come in the next few years and uh the both the L1 and l2s are going to be a big part of that and so actually this ties very well into e 7 706 because multi-dimensional gas actually is in some ways a scaling strategy thank you for sharing with alic your contributions have shaped the lives of millions developers Builders and everyday users who rely on ethereum for everything from Finance to governance and Beyond I can't

wait to dive into this so without further Ado let's beep in so I think uh first it would be good to start with the underlying theory behind this concept of multi-dimensional gas pricing right so today ethereum has a single gas limit right and it recently increased from 30 million to 36 million and this gas limit mixes together all kinds of resources so computation reading and writing to ethereum storage data bandwidth the cost of oving the logs uh so all kinds of things end up going into guas and uh the challenge this is um basically the what I have in this diagram over here right

so the way to think about this is that for a lot of the resources that matter uh there's a certain limit that the network can safely handle and then if you go above the that limit then that creates danger for the network but if you go below the limit then you're not actually buying the network anything right so for example if you know you have a 10 MVPs data connection then you know or say 10 megabytes per second to make the meth simpler right then if you have to download five megabytes in one second that's fine if you have to download one megabyte in one second that's like also fine you save four megabytes but you don't really gain much

by saving those five megabytes if you have to download 10 megabytes then that's like fine but if you have to go and download 15 then like suddenly you'll have to take an extra half a second to download that data and this is of course before taking into account some you know peer-to-peer in efficiency and so that already actually starts to contributes to instability in the network right and so there's a lot of these resources where they're better modeled as as limits and uh and so the thing that we're trying to avoid is like usage that goes above those limits right and the interesting thing about this is that a single dimension gas mechanism actually does a pretty suboptimal job of

reflecting those constraints right and so here in this chart I have know for imagine a system where there's two resources data and computation and there's a limit to how much data Network can safely handle there's a limit to how much computation the network can safely handle then if you try to create a line limiting data plus computation then you get either one of two problems or both where one problem is excluding blocks that are safe but that have a large but still okay amount of data and a large but still okay amount of computation and the other problem is accepting blocks that are dangerous because they have either too much data or too much computation but they're still within the gas limit because even though they have

a lot of one they have like basically none of the other right and so like mathematically you can think of the actual safe region in a two-dimensional graph between data and comput as a square and any kind of region that you can create with a single line representing one gas limit has to be a triangle and a triangle is never going to perfectly overlap with a square and so you end up either inviting some amount of danger or you end up actually having a much lower resource limit than you could be having and so want to try to get around this is by moving from a one-dimensional limit to a multi-dimensional limit right where we

basically say well instead of having one type of gas we actually have two types of gas and then those two types of gas have fees that float separately and you have two limits and for each type of gas and you have two Targets for each type of gas and so basically you're accounting for each type of resource independently of the other so EIP 7706 is an EIP that wrote that actually accomplishes two goals at the same time so the first goal that it accomplishes is it adds a separate gas limit for call data so it actually accomplishes the goal of giving us multi-dimensional gas

and the reason why I picked C data is because C data is what the a dimension that is relatively disconnected from everything else uh so it's uh not part of the evm um and uh at the same time it's a dimension that's like actually very valuable right like one of the big dos issues that we worry about actually is blocks that are very big in terms of data and so if you separate out the gas liit for gold data and the gas limit for execution then that's something that actually is relatively low cost and relatively High benefit right so that's the first thing and then the second thing that this CIP is doing at the same

time is it's like harmonizing the different forms of gas right so today we have execution gas and we have blob gas right and execution gas and blob gas are actually handled by different mechanisms they're handled by different header Fields there's different rules for updating them there's actually different eap1 559 formulas for them so there's a lot of like fairly redundant and separated logic between them and what the EIP does is it basically yeah creates this nice mathematical abstraction where you're basically treating gas as being a vector instead of a scalar and so a gas is now a list of integers one integer for each type

and then we basically take all of the gas related functions uh so get Max fee get priority fee get get the gas a little bit of a transaction get how much gas a transaction is paying getting the gas limits of a block you doing the EAP 559 updating and we basically convert all of those functions into this vectorized form right into this form that just operates over all of the guess limits at the same time and so you have the exact same logic working in parallel for every type of gas and so this actually means that even though we're adding a dimension of gas we're actually reducing total complexity and once this EIP is put into place it becomes extremely easy

to add more dimension gas in the future and so in this block post that I wrote I the question after data are some other dimensions of gas that make sense and one that I talked about is storage reading and writing and I talked about some of the challenges of uh doing this so basically the challenge is like this problem of like sub calls needing to provide multiple gas limits and I think my updated view from this is that like within eof there's actually uh you know you don't have gas observability and we should potentially just get rid of gas observability from the whole evm so the only thing you should be able to do is just make a sub call that provides the

entire guas and the main use case for doing anything other than this is like wraps transaction mechanisms so stuff like account abstraction and I think those things should be just become base features of the protocol but like there is more complexity in going Beyond call data right but the point is that that's complexity that can be approached a bit later and once EAP 7706 is in place it becomes technically very simple to just keep on adding more gas Dimensions potentially that have more parameters right so in the future you could add gas for State accesses you could also add gas for State growth potentially other dimensions in the future as well so that's EIP

7706 perfect thank you so much Al for sharing about this [Music] proposal we have requested our participant to drop the questions in chat I see there is a question already the question mentioned here is should we push for SSD transaction EIP 6493 or at least SSD payload EIP 6404 in beacon block to keep ideas like multi-dimensional gas less convulated to sort of bookkeep in the protocol I would say yes and I think we definitely eventually need to migrate fully to ssz so my personal preference

is definitely to kind of delay this somewhat and I think one of the reasons why is that for 2025 the priority just has to be um eof and deer D and and increasing the block count and like I think know faka should have block count increase with beardos and eof and nothing else but then once the like resources become available to do this and I think doing 7706 and ssz fig everything in one batch is a totally good idea right it just make so many different things cleaner at the same time maybe a small followup on this do you think in the present spec would we

need to either change or adjust ssz proposals or 7706 in order to be both of them compatible I don't think so I think and when I wrote 7706 I was like thinking about SSC compatibility in my head already so I don't think there's anything particular to worry about there I see there is another question in the chat Nico if you would like to relay that yeah how the framework can separate the standardized fee competents from the L2 logic so you can be separate the standardized fee component from the L2 logic so far we haven't uh really talked about l2s right

but in the context of l2s one of the ways in which this is valuable is that l2s already have to charge for data gas right and for like l2s already get their data gas cost and their execution gas cost from the same from different sources right because at l2's execution gas cost it depends on the l2's execution gas limit and like congestion mechanics and the L2 itself but the data gas cost of an L2 should basically be just directly borrowed from the underlying L1 right and so for like if you're an L2 then like you have to already somehow like manage those two values being draft separately from each

other and so one really nice side benefit of VIP 7706 is that it makes it much easier for El to to manage that because they can just have multi-dimensional prices and they can just inherit the L1 blob gas price as being their call data price so we learned about this new term multi-dimensional fees could you maybe explain a little bit more can multi-dimensional gas allow us to widely increase gas limit this is a question in chat by gajinder Singh and I would like to add a little bit more here how it aligns with ethereum's broader gas model yes so the answer is yes so multi-dimensional gas does make it safer

to increase the ethereum gas limit and the reason why is because the gas limit today is bounded by considerations about safety of like the ethereum blockchain consuming more of certain resources but each of those safety considerations is actually tied to a particular specific resource right so for example it becomes dangerous if blocks become more than like one or two megabytes it becomes dangerous if blocks start take more than a full slot or potentially even more than I like some portion of usot to process it becomes dangerous if the state size grows too much right each of

those limits are limits that are separate right and the problem is that because we want to avoid dos attacks we have to set those limits based on the worst case instead of based on the average case right because there's always the possibility that someone will try to break the network by just filling the entire chain with block transactions that consume only one of a particular resource to try to basically cause the ethereum chain to like shut down and break in exactly one of those ways right and so if we have multi-dimensional guas then that actually lets us have uh like SE separately set limits for each resource and then we can set limits for

each resource to equal exactly what is the theoretical maximum of that particular resource that we can safely handle and so that lets to gas the limit in terms of the average case transaction throughput increased by quite a bit without actually reducing or making any of the worst case balance force right so for people who are watching um I have on this chart right so we have this square and we have the line right and then imagine average case usage as being like a diagonal line so data and computation have about the same amount right and then if you think of that diagonal line then well not quite diagonal right but just basically it goes through the top left and the bottom right or bottom left

and top right corner right then you see how you have the gas limit and even if you said the gas liit that accepts a little bit of danger it still forces the average case usage to be like about 1.5 times lower in this particular example than the safe amount of average case you can have right but with multi-dimensional gas you're basically setting the two limit separately and so your average case usage can go all the way up into that corner thank you and I think there is another followup which is a combination of both L2 topic and multi-dimensional how can multi-dimensional gas tie with the execute proposal so the execute proposal is basically state

evm execution right and there's a version of it where it gets re-executed directly there's a version that gets executed with snarks and so the execute proposal like it basically involves doing extra evm computation and including C data but without accessing the state and like just basically without doing IO right and so in a multi-dimensional guess world like you can BAS basically charge for execute just by charging for calls call data and charging for execution without charging for Io and so if you have a block that contains a bunch of execute calls but

then you have other transactions that use IO then those other transactions they're still free to use as much IO as they want because that resource is not look taken up by the rest of the block yet very well I have learned about another proposal basically we were discussing it in the p of EIP 7623 about 7706 and that gave me the idea of having a broader discussion on this so uh 7623 which increases C it a cost in the upcoming Petra upgrade how do you think these two proposals interact and how should developers be thinking about the combined impact in future um yes so I think these two in terms of the like resource bound Ang

goal they actually try to accomplish a very similar goal right so what 7623 does is it leaves costs unchanged for like basically not more than 99.9% of use cases and at the same time it reduces the theoretical maximum called Data size a block from about 2.7 megabytes to I think basically a little bit over 1 Megabyte and so what that means is basically that know you can increase the gas limit safely without having to worry about like extremely large blocks creating worst case situations 7706 solves the same problem in my opinion

7706 is cleaner and it is better and it allows you to get much closer to an optimal solution right because if you think about even the consequences of 7623 right the worst case size of a block is about a megabyte the average case size of a block is is I think still about 100 kilobytes right so we've only managed to decrease the worst case to average case ratio from being like about 30 to being about 10 right with 7623 or sorry we 7706 you'd be able to decrease that ratio all the way down to the E1 559 Max the target ratio so basically all the way down to like you could do two you could do three or four or something like that right and so 7706 is better the reason why we did not do it

is because 7706 is considerably more complex to implement where and it also requires a lot of work on the part of transaction senders application developers and so on whereas 7623 is like basically a 10line change so it's like pragmatic short-term fix versus you know like how do we really optimally deal with this problem with finality so once we have 7706 then of course we should just delete 7623 because we would not need it anymore that make a lot of sense but as I understand it seems like there could be more research pending on 7706 and more uh studies so what are the key milestones and criteria that will

determine whether 7706 is ready for mainnet upgrade so I personally see two roadblocks so one of them is just like the usual technical implementation right and so you know this every EIP takes work this EIP takes some amount of work on the evm side it takes a am of work on the you know wallet and like application side to properly support it and obviously if we decide to bundle it with ssz then like that adds even more work right now for 762 or the other type of challenge is on the research side right and on the research side I think there's still people who are looking for

Assurance that this type of VIP is not going to over complicate the me pool and is not going to over complicate the mechanism for choosing which transactions to include in a block right so the argument here is that if you have one type of guas then the optimal algorithm is always very simple right you just include transactions and if you have enough transactions to fill the guas limit you just take the ones that pay the highest fee in a multi-dimensional world it potentially becomes more challenging now the with if you want five F9 does make this quite a bit easier in most cases right and the reason why is because even today with onedimensional

e559 like something like less than 10% of blocks actually end up hitting the limit right for most blocks the limit doesn't matter and all that matters is basically whether or not you're paying the base fee so for in a multi-dimensional world you should assume the same thing and actually potentially what we could do is we could say well we're going to do this M dimensional thing and then we're going to make each of the limits be three or four times the target instead of two times and if you do that then like maybe even only one or two% of blocks would actually yeah have deliv it right and so you like actually the inefficiencies are kind of relatively small they only apply

in a small portion of situations and there's like decent approximation algorithms but these are all things that are conjectures and you know like more rigorous study of that and even taking a very applied approach using existing ethereum transactions is something that would help a lot as well a lot of sense it's not only just the research work but also the coordination among infrastructure and a protocol would be required in order to maintain everything so that's good to know I see there is a question by gajendra Singh would you like to go ahead yeah hi Pua hi viik and thanks for you know giving

this detailed presentation and the amazing answers to the questions and there is one more question that I have and since seems like blob capacity gets filled pretty quickly and uh since the blob demand is generally in elastic would we still be okay having call data as da backup once we have the call data gas limit right I see it I think realistically there's a good chance that implementing the CIP would basically kill the uh like call data SDA backup concept and the reason why I would say this is because like if you just uh set

the parameters based on today's usage you could imagine Target a blob like call data or like total block without the blob size being say 128k and you set the limit to 256k and then you increase the blobs and so with Petra we're already going to increase to a target of 768 with beos we increase to a limit of like two megabytes and so the amount of extra space that you get by putting things into cold data is going to become tiny right like today what we have is we have a world where uh the well post or rather post pectra right we'll have a world where blobs are 768 Target and then but then you also have this like

stretch space where you can use the call data all the way up to a megabyte and after post this like that stretch space will decrease and then at the same time with pias the number of blobs will go up and so that whole use case is going to just become much less economically relevant I may have a followup here as we are talking about blob base I wonder would implementing EAP 7706 require updates to blob based fee instruction that was outlined with EIP 7516 no I mean obviously it would have to be repointed points to I you know the what now becomes the second gas Dimension instead of like what was blob

gas but that's like a fairly trivial thing it just points that a variable that does the same thing as what it did before so maybe we would need another smaller EIP in order to just point it to the new I think realistically probably just that adjust this the CIP to clarify that the blob based fop code would points to this variable yeah I'm not so sure because this has already moved to final and has been deployed maybe it will come from process point of view to Al together have a new proposal and mention the new specs changes in that because that's going to be an important change to any proposal very well I have another question with respect to efficiency

would you say say EIP 7706 is a long-term scaling solution or is it just a primarily an efficiency Improvement that we are trying to bring it for existing use cases I think realistically 7 706 could get us potentially 2x gain potentially a little bit more safely so I see it as potentially a valuable improvements but I definitely don't see it as a substitute for other forms of scaling that make a lot of sense here also in the same direction I'm just trying to understand was it always the part of plan or this proposal was conceived because of a growing ethereum

usage I think this idea was uh one that we've been floating around for quite a few years now I actually forget when was the first time that it was brought up I think definitely after we started bringing up EIP 559 because I think without E1 559 the napsack problem issues like probably do end up not over complicating like block building too much like definitely yeah after eap1 559 was like a thing in discussions yeah I don't remember when it actually first appeared like it could have been one or two years it could have been longer sure yeah but we recently found this proposal

documented because 1559 was long ago and the proposal was originally documented but I understand it takes time from E research to come up to EIP GitHub repository we are talking about separating call data gas from execution gas and that represents a major shift what are the key tradeoffs and why do you believe this simplification ultimately benefits ethereum so I think there is a balance here between kind of Effectiveness and complexity right because theoretically you could potentially go all the way right you could literally say like we're going to have a limit for literally every single individual op code and there's actually even an argument for why that might be a

really interesting and good thing to do and the argument is basically that if you discover that there's a bug in the implementation of One op code that is a Dosch then if you have a mechanism where like that every single op code only gets assigned like basically a 50th of the total usage then like if you do attack one of them then like even if you manage to slow it down by 50x then you're only like slowing down the entire execution by 2x right so you get something that's like incredibly resilient and robust the problem with taking that approach is I think like one is it becomes like much more confusing for developers two is

you'll all of the yet issues around like inefficiency and having more volatile fee markets will probably end up multiplying and it'll become plausible that like one single application will just cause a few particular gas limits always get hit then three is just the overhead of having really big vectors so if you have like literally 50 dimensions then the a transaction know for gas price start price Bas fee and so on like you have to have like 600 gas or something like that so I would say those are probably the main reasons right and so to me saying that we're going to have somewhere between three

and six uh Dimensions feels like a pragmatic compromise and so I argue you know like start with the three and basically the most natural one as a foot in the door and then in the long term I absolutely endorse exploring adding a couple of other dimensions as well that's quite an optimistic approach here three to six dimensions are taking too many parameters into consideration so uh with separate gas types there is a question of a potential fee fragmentation do you see any risk in balancing execution gas blob gas call data gas and how that can be managed um yes it is a risk like basically yeah it makes the optimization

problem for developer more uncertain because they might end up optimizing for one regime but then you have like some long-term secular change and what what other people do and then as a result they have like a long-term shift where maybe before execution was expensive and call data was cheap and then now execution becomes cheap call data becomes expensive and then if you introduce more dimensions then like maybe you have changes in relative prices between execution and IO and then of course if you have like 50 Dimensions that problem becomes completely crazy and so for a developer the optimization problem definitely becomes more Dynamic and I think it is still doable right like if I was a developer the thing that

I would do is I would just look at average base fees of all of the resources over the last year and then like that's what I would use to figure out like what is the total objective function that I'm optimizing over right so I think know that's fine but like that definitely is one of the like extra complexities that adding more Dimensions introduces and I'm sure there would be related research in upcoming days we would be in a position to overcome this concern and talking about concern there is a common concern with increasing gas limits or reducing called it a cost in ethereum theoretically maximum block size how does EIP 7706 strikes a balance between

efficiency and affordability there okay so today the average ethereum block size I I can actually just quickly look it up I think it's definitely going to be a good number for people to know so if you go to Ether skin charts then you basically just like scroll down you go to average block size and you scroll down a bit more then you see recently it's been at like basically about 75 or 80 kilobytes right so like very small so before the pectra fork the theoretical Max size of a block this is still

assuming the 30 million gas limit we don't even really have significant data for the new higher limit now was 2.7 megabytes right so 2.7 megabytes divided by 75k so actually about a 40x ratio of like worst case to average case and then post 7623 I think if you look up 7623 then the token cost full or basically right so we still have the zero BTE mechanism I still doing that thing but it reduces everything by 2.5 and so realistically like gets something like 1.1 megabytes right and so with EIP 7706 what we would do is we would

probably just like set the target to be either somewhere close to current usage or potentially a little bit above current usage right so like I suggested 128k is like a a decent plausible number probably reflects what we would get to if the gas limit was increased to like 45 like 50 million or so and then you would be able to set the limit to be either like 2X or 4X that right and so the worst case becomes lower and what that means is that it becomes safer to stake with lower levels of bandwidth and generally we would see lower Network instability from unexpectedly large blocks taking a long time to but and that in terms of cost for users

like if we set the target to be above what the current usage is then the cost experienced by users would actually decrease that sounds good thank you so much for sharing I see there is another question gajender Singh please go ahead yeah with regard to the resources since you mentioned size and bandwidth is one of the resource and then the multi-dimensional gas limit is sort of placing different limits based upon different resources but in the end we have to sort of Define these particular benchmarks with regard to a standard hardware and as the standard Hardware keeps on improving year on year because of the mor law and other laws like there is a bandwidth law as well so how do we

basically keep pushing those limits as the improvements happen on the hardware space yeah so the nice thing is that if we have multi-dimensional gas limits then we should be able to reverse engineer the correct limit for each resource directly from like what the hardware spec is and like how long it takes the hardware to like run a certain amount of evm gas or like how efficient the peer-to-peer network is and and what we know about those kinds of variables and so we would be able to adjust the limits separately if the trajectories of improvements in bandwidth and up being separate so I think it actually opens

the door for a more principled approach to doing that and then for how the gas limit can be changed I think this is something that this CIP does not yet change right so the CIP actually tries to keep the the way the gas limits are decided like about the same but I think what we could do is like I'm personally in favor of just making all three limits separately votable by takers thank you let's talk a little bit about economic and scalability impact uh we briefly discussed about layer two so one of the ethereum's greatest strength is the ability to adapt and scale over time with more application relying on

rollup and call data heavy transaction how do you think EIP 7706 will affect transaction cost for both users and developers yeah so for users I think think transaction costs will decrease as a consequence of the scaling improvements that 7706 can enable and another thing is that I think it's uh it's possible that for certain kinds of applications is would even be less volatile because if you have one application that dominates one particular resource then the other resources would not be affected and then for developers in terms of like actual

transaction fees that you have to pay it's like pretty similar although I know that people have been making you know like things like gas derivative markets like basically ways to let people pre- purchase gas and so those platforms would have to adapt themselves to handle the multi-dimensional gas world that is great and I would also like to understand a little bit about uh security consideration with respect to implementation so ethereum security and decentralization has always been the top priority so are there any security consideration or challenges that were carefully accounted while documenting this proposal or maybe something which hasn't been accounted but still under

consideration yeah so I think one of them is this issue of like Optimal block like building mechanisms right basically if you're a builder and then one or multiple of the gas limits actually gets full then like how do you prioritize when the individual things are multi-dimensional right and like there are algorithms that can get a pretty close to Optimal algorithm but like this is one of those things that needs to be explicitly thought through and then the other thing is the mol right because with the mol there's currently some rules that have to do with allowing for example a transaction to re override another transaction if it's like in the

meol if it's gas limit is higher by a certain amount there's rules about like how gas transactions get prioritized if there's too many transactions in the pool and all of those rules would have to be adjusted for the multi-dimensional context glad to know that we are already about of these concerns and possibly it will be addressed in future when we are getting into more finalized version of this PC with that the one question that comes to everybody's mind and I think it is also shared in the chat itself when can we expect this proposal for ethereum main net maybe you can answer in terms of number of upgrades from now yeah I think realistically either one or two

after faka would be a good time to Target that is good and a follow-up question on this how do you think teams should best coordinate and come to consensus to ethereum developer product road map in terms of the CIP M yeah and so I think like the first step here obviously is that we should be continue to do all of the research that I talked about then separately at some point you know cor developers will have to start coming up with priorities for the fork after faka and so I think this will become one of the discussions and I

think as an input going into discussions like wants to know what are the ACT priorities for 2026 right because for 2025 it's obvious on the execution side it's uh it's eof and for the consent side it's blobs blobs and more blobs and then 2026 will be inundated by blobs and then on the execution side if a priority ends up being like scaling but through further gas limit increases then we would want to look into this as a way of making the gas limit increases safer yeah and in the chat it was mentioned in general as well I think you probably touched a little bit on that but if you would like to add anything on top of it

so we are just trying to understand here like if you have any suggestion on the coordination part when we can both come up with a joint road map right right I see yeah I mean I think like in general my view on this is that I think Step One is agreeing on underlying goals right and step two was then agreeing like actually seeing which IP is do a good job of contributing to some underlying goals right so for example if the underlying goal for 2026 ends up not being L1 scaling which is plausible right so like for example if we end up taking a very sort of purely L2 focused approach increasing the gas then it's very possible that L1 effort

would go toward other things but if we decide that scaling is a priority then we're going to have to say for example how would veral trees affect scalability or alternatives to veral trees how would 7706 affect scalability how would just like gas repricings that are simple and more direct affect scalability and so we would end up like judging and prioritizing based on the answer to that question thank you for sharing and before we move out of this topic one final question on this we in ethereum have always been working on community

collaboration so how do you think developers researchers and ecosystem contributors may get involved with EIP 7706 are there any areas where client team need additional Insight or implementation support yeah I I think if you're a researcher then the the natural research problem here is basically the one that I talked about right it's like a very specialized application of multi-dimensional napsack problems which is something that is like fairly well studied in computer science though here there's obviously know like a few Unique Mechanics right like there's the E1 559 mechanism and then on top of that there's just the empirical question of

like how transactions actually like look and work in ethereum so like giving an answer to the question like basically here is a specific proposed algorithm for either a doing block building or for managing the meol and then say yeah come up with actual math like that that shows that given the a sample of transactions from the average ethereum chain like it actually gets you to like 90% of optimal or 99% of optimal that's uh something that would be very valuable for this whole effort also eth research continues to be a good forum for talking about this yeah I think it's know combination of those

well thank you I mean you already mentioned that this is a robust proposal but perhaps it's complex to implement so any and all kind of support are welcome on this proposal I see one other question or I don't know if it is a question or a comment Nico if you would want to take it no I was just saying that indirectly having a standardized multi-dimensional gas on L1 helps L2 to have a standardized way to to do multidimensional gas so in a way we can say that it also helps L2 so yeah I agree and one thing I would add is even if we say pre- agree to have 7706 in

glamsterdam then potentially L2 could adopt it ahead of L1 because ultimately yeah like L2 is getting value from this doesn't technically depend on having L1 have it already on Main net that's true well that brings us to the end of all the questions on EIP but definitely not all for the day we have something more interesting coming up before we get there I wanted to share a couple of fun facts with you so as per eaps inside.com vitalic ban has contributed to over 20 plus eips on ethereum network upgrade so far and so many more are

there in line so thank you so much for all the job you have done so far and and we look forward to have more and also on a related note I was looking into our past episodes I mentioned in the beginning of this conversation that he has graciously taken out time to talk about so many proposals our last discussion on block gas limit was episode 42 and this is such a coincidence 100 episodes later we have you here on episode 142 to talk about EIP 7706 thank you so much Vali for making our time to share about upcoming proposals thank you very well that brings us to

the rapid fire [Music] round so we are going to share a few questions with you we'll try to get answer either in one word or one sentence in one minute are we ready okay ethereum in 2030 lots of scale um lots of applications using it much better privacy much better user experience Global platform for building the open decentralized world most exciting EIP ever the merge the biggest misconception about ethereum I think 10 years ago the answer was that like a lot of people thought of ethereum as being

just a coin I think today I don't know like I think today there's just like so many groups of people that have so many different opinions opinions that's correct all right uh what would be the one word to describe Dow interesting what's missing in web3 today public goods funding if ethereum had a spirit animal what would it be okay I'll say phoenix the future of defi exciting or chaotic some of both I think we'll see a portion of defi continue to be more safe more reliable and just more useful in more and more boring and mainstream ways and then there's going to be a portion that just continues being totally crazy

one word to describe the ethereum community special the most overhyped blockchain Trend Ripple one word to describe the role of social layer in ethereum important the key to sustaining public good funding better mechanisms most underrated factor in blockchain adoption I think okay within the technical group I think on ramps and off ramps the most important value ethereum should never compromise on openness decentralization censorship resistance if you could rename ethereum what would it be I would not rename ethereum but I would revive the EIP from way back then

to rename Gast to Mana okay uh this was not the part of the original plan but I have added it from my own end the first word that comes to mind when you hear Peep and EP there thank you vitalic it was very interesting to hear your thoughts I have always found them inspirational so thank you for sharing them before we wrap up I want to take this moment to acknowledge and say that not just technology but you have affected the lives of people here you have enabled the entire generation of Builders to create innovate and redefine financial and governance system this is not just about code it's about empowerment as we look ahead do you have any final message to be shared from this

platform for ethereum Community developers validator researchers I think ethereum's technical trajectory is actually looking very bright for the next few years we know what the most important goal is the most important goal is you know to scale scale and scale more while maintaining the special status of ethereum as a decentralized platform and a decentralized community and ecosystem and there's a lot of different strategies that approaches to that that have all become much more mature in parallel and I think people will be surprised by how quickly we can accelerate and actually implementing them we always appreciate

vitalik you taking out time and sharing all this information it's invaluable not just for helping Community stay informed about what's ahead but also for your dedication to knowledge sharing and open collaboration I'm I'm grateful that Peep and EP can play a smaller role in supporting ethereum education and having you here is a kind of Testament to the fact that education matters and we truly are trying to support the ethum ecosystem so thank you vitalic it's been an absolute honor having you on PN thank you so much for having me Bri to everyone listening if you would like to learn more about EIP 7706 contact contribute to its development be sure to

check out the proposals discussion and related research work check out links in description and related proposal that's all for today but we'll be back soon with another intriguing proposal to explore until then keep learning keep building and keep perfecting the ethereum locked in this is pujaan signing off