EIP-7907: Meter Contract Code Size and Increase Limit

Transcript

So if we do not put an explicit counter size limit it can easily create a deny of service attack vector. Unis swap developer when they develop this smart contract they already find this problem and then carefully organize their code make sure they do not break this 24 kilobyt limits. I really enjoy to put a lot of different applications enabled by smart contract but unfortunately when compared to my web two developer experience I found there's a lot of this limitations before doing that I think it would be great if we have better grounds to test this in more near production environment I think this is something that I feel we can improve a lot of like save our life kind of that's why I was super exciting

to for this IP eat. [Music] Hello everyone and welcome back to Penney, the series where we unpack Ethereum improvement proposals with the people who are shaping Ethereum's future. [Music] This is episode 152 brought to you by ECH Institute. I'm your host Puja Ranchel and I'm joined by my colleagues whilin and Akash. Today we are diving deep into EIP 7907

meter contract code size and increase limit. This is a proposal that's particularly interesting for smart contract developers and protocol designs. We will explore the background implication and ongoing community conversation around contract size, gas metering ext. And to walk us through it all, I'm excited to welcome one of the co-authors of this proposal, Khou. For those who have recently started following us, Ki is a longtime contributor to Ethereum ecosystem. He has authored multiple impactful EIPs including 4804, 4972, 5018, 5027, and 5478.

You may also remember him from our Penney episode 106 where we discussed ERC 4804 web3 URL to EVM call message translation. I'm truly excited to have him back on the show. Thanks for joining us here, Key. Hi everybody. Uh it's my great pleasure here to share our progress on EIP7907. I would love to kick thing off with a quick introduction. So could you share a bit about yourself, your journey in web 3 and Ethereum ecosystem so the community can get to know you better?

Yeah, of course. I have been in the crypto space about more than seven years. Before that I was a software engineer Facebook, Google working on their large scale infrastructure. So when I come to the crypto space, I found there's a lot of uh missing pieces in terms of infrastructure and one of my favorite one is how to improve the EVM besides other for example scaling solutions like lay one layer 2 DA that's why I put a lot of efforts about four or five years ago wrote a couple of EIP try to improve different pieces of EVM in terms of example the contract code size and also a couple of others like addressing the stack back to deep errors and also how to deploy contract cheaply

use by re using existing contract code hash. So I'm glad that this EIP is reaching to for inclusion for next for custom upgrade. So we love to share the details. I'm also running planning on working on the ISA storage which is uh Ethereum layer 2 scaling solution which aims to provide long-term solutions for Ethereum BL by large object was introduced in EIP 4A44 and also receive a a lot of support from Ethereum ecosystem including ESP grant. Yeah, thank you so much for the introduction.

We really appreciate all your contribution in the ecosystem. I understand there are many more avenue and you are looking into two most of the important avenues EVM and layer 2 solutions. So those are great to have and in the process you are also documenting proposals which can become Ethereum standards. So thank you so much for all the work you are putting in. Well we understand we have a proposal to go over. So without further ado let's peep in. Yeah sure. Um so this is today's outline. So first I will give a brief overview of what is the motivation why we want this EIP and then I will dive into the details of EIP 7907 and then I will discuss some other ones topics uh especially some of the topic

are still this highly debating in the Ethereum research IND channel. So I will pick some of them and then to would like to see if you are interested and definitely would like to see your contribution and lastly I will summarize our work. So first of all what's the motivation? So before EIP170 that is the dependency of the EIP7907 there's no limit of contra size. So uh contra is one of the I think the unique dynamic resources in the AVM. So other resources like for example op code like calculate summation addition or division those can be easily evaluated according to their CPU usage like it's just using

constant resources. However, the contrast size is a dynamic ones. It can be very small, maybe zero for most EOAs and it can be super large and at that time there's no such limits and processing this contract in both in terms of CPU, storage, memory is linear in terms of the contract size. Especially one of the most expensive resources is storage. So reading the contract from storage can be super expensive. So however, Ethereum right now only charges constant gas cost that is 2,600.

Um so if we do not put an explicit counter size limit, it can easily create a deny of service attack vector. So here is my favorite part. So I will give an example. Suppose we deploy a lot of contracts with size 256 kilobytes and then given the current block name is is about guest name is about 30 million right now I think it's about 36 million but right now I will choose this conservative number and then an attacker can potentially create a transaction within the block that you take all the gas that is the 30 million and and read all those 256 contracts in a single

transaction or multiple transaction using only 2,600 per core. So that will make a EVM client to read all this contract which will take up to 2.6 GB of data. Right now our commodity PC for example SSD can only allow to offer about hundreds of megabytes of data reading sequentially. So which means that it will take a a couple of seconds or maybe 10 seconds to read all these contract data. Suppose there's a such kind of transaction that allow in the Ethereum network while at the same time we know that our consensus

only have a really really tight timing budget that we have to reach consens of the block within 12 seconds and the time for executing the block is much much even much smaller because we have to deal with other latencies both in terms block propagation voting latency or others. So which means that we can easily create a block that nobody can reach the consensus because it read too much data. So that's why EIP170 which was authored by Vitalik at the time introduced the 24 kilobytes limit of a contract to avoid such DOS attack.

As a result, if we put this number into the previous calculation, then we can get the limit of the storage when the node reading from block will be limited by 270 megabytes and that can be easily process in one or two seconds in a common commodity PC and so this makes a lot of sense and also avoid this DTOS attack significantly. So that's motivation. So that EIP I think was about uh 10 years ago was drafted in 10 years ago. However with a recent rapid growth of the applications especially like DAX unis swap curve landing all kinds of application. So the logic of contract is

becoming more and more complicate. So unlike previously we may have a very simple for example Dow governance or voting contraos right now we have really complicated logic for example for curve it in order to perform the proper rate of swap uh input token to output token it actually perform some new turn iterative algorithm in their contract which will be really complicated and so which will will create a lot of like large contracts. So a complicated contract can now easily exceed 24 kilobytes. I have experienced this for a couple of times even like three or four years ago and not to mention other

popular D applications. So in order to avoid this to circumvent this limits the one solution is uh we can split the contract into multiple smaller contracts so that we are able still perform this contract but delegate part of these logics into smaller ones. Unfortunately, this means that when I first time roll this contract and then if I would like to deploy this contract, it may be different because I have to wrote contract first make sure everything work correctly test all these things and then later when I deploy oh sorry the contract is too large then I have manually to split contract which increase the maintenance cost. Suppose

now I have version one contract and I have version two or three. It's really hard to work on like subcontracts or if I still work on single contract but every time I deploy I have to split again. So it's really really painful for a lot of developers and in addition because of this split process it introduce a lot of complexity in order to deal with this how to we are able to split this different logic into smart contracts so that they are like in one turn we would like to to be to be more modular to better to organize them which means that it introduce a lot of complexity and create a lot of security concern. Suppose if I fix some split

contract unfortunately the contract code is not the latest one and which have some security issue I'm sorry it and the whole contract and whole DI is broken. So and this is uh something that I personally has been experienced for a couple of years and that's why I'm particularly interested in this problem how we able to solve the problem not only for me but also for everybody in the Ethereum ecosystem for all the developers. So here example like how to split a contract. So originally we have multiple functions to behave. For example, I can do swap. I can get gal liquidity. I can add liquidity. I can get estimate of the swap ratio. For example, for given a input token and what's the number of the expected output

token and since this contract is too large, we have to split into multiple subcontracts. And so for example this subcontra put part of the logic into call sub contract zero and in the main contract that's because subcontract one will call another function to another contract actually this should be super subcontract zero function two so that we are able to still perform the logic while at the same time the 24 kilobytes contract name it so the one straightforward questions why not we just remove this limits like this is kind of like a a really really a small number even compared to a lot of I not

say iPhone but a lot of calculators it's actually the processing power is much larger than 24 kilobytes. So in the EIP7907 actually I previous contribute a smaller number of EIP which is has a similar idea that's why I was invited to contribute to this EIP and impose try to remove this one and impose a much larger that's 10 times larger that's 256 kilobytes contract limit the reason we impose this limits rather than unlimit because we found this other conrain in Ethereum protocol for example in the P2P network a send a contract to each another uh node and it just send a whole contract in a single package to another

node according to existing uh P2P protocol design and unfortunately the package size is limited. So if we send suppose we are unlimit this smart contract. However even though we are able to store this contract we are not able to send this contract in the underlying networking protocol. So nobody can receive this contract. We suppose we we have a super super large size for example 1 megabytes or even more. That's why currently we still impose a limits which we believe like 10 times is already significant to relieve a lot of developer burdens in terms of contract limits. So that's why we chose this number and also in order to reach

this goal we also need to carefully to reach some to satisfy some design constraints. So first of all obviously we need to avoid the DOS attack especially with purple gas metering and implementation because I will show later if the li implementation is not correct then we can still easily suffer from the DOS attack and second is that it should be compatible with existing deploy contracts especially during the gas metering. or repricing all existing contracts should still work as before without any like breaking issues. This

used to happen before when we try to repric some gas prices. We have to evaluate all existing contracts to make sure is there's no breaking issues. So in the current design we make sure that everything is fully compatible so that we do not require for example if some of the existing contract may be broken or ask them to rep deploy contract that is not go to us. So u this is basically two constraints. So what is the basic idea? The basic idea is quite straightforward to introduce a called dynamic gas metering based on the counter size. So if the contract size is smaller than 24

kilobytes then calling a contract of these smaller ones will stay take the same gas cost that is still 2,600 gas for the calling the smaller ones. However, if the code size is greater than 24 kilobytes. So there's a key term how we can detect is greater than. So I will explain this later but idea is that once we detect is greater than 24 kilobytes then we will using excess gas that is additional gas that we are charged in linear in terms of size so that we can use this gas to cover the cost of reading and processing this

large contracts. So this is very straightforward very simple but you may have a question why not we just implement this early and why not we have choose this excess gas formula and so I will explain later u because there's a lot of lot of tricky issues in terms of implementation and also a couple of other tricky issues in terms of the other cost both in terms of for example paging cache and also jump analyszis and so Since a lot of developers they say hey they really like this EIP they would like to have this solve this problem immediately. So the EIP7907 is now chosen as the candidate for

inclusion for the next upgrade and so there are a lot of work still ongoing but we would love to see eventually it will be can be included in this upgrade to solve this long-term paincoin in the Ethereum developing ecosystem. Okay. So first of all, how we address the DOS attack? The general idea in Ethereum to address this issue is to charge gas before consuming resources. For example, I would like to take a taxi. The taxi will charge me a minimum rate no matter where distance it is.

And and then if my distance is too far away, then it will charge more. Suppose I go to airport which is far away, you will charge more. But in Ethereum since an attacker can put a minimum gas that is the minimum money that when I take a taxi. So before I really move forward I really would like to check the transaction or potentially attacker has already paid enough gas. So here is a pseudo code in Ethereum EVM. How to address the this attack for any steps for example for calling a contract before do any resource expensive operations for example reading contract

do jump analyze jump destination analyszis we will charge first the gas first which is 2,600 as I explained before and then after gas is charged if there's no enough gas then we will just reverse the transaction and say hey there's an error out of gas error and Then we will read account according to the contract address that the program provided and then read the corresponding code according to the code hash that is stored in the account which is a expensive operation because account is about 100 bytes data but the code can be super large as I explained it can be for example 24 kilobytes or it can be

unlimited before EIP70. So thanks to AIP70, we can make sure that reading contract is operation is less than 24 kilobytes. So we can safely assume that this is being covered by 2,600 gas price that we previous charges. So we don't have need to concern the DOS attack and then we can make sure the total number of the buy refrron code is just a hundreds of megabytes using this charge gas first before consuming the resource and however if in the EIP 7907 cases is a little bit tricky. So on the right hand side is a wrong implementation that

supposed we implement this 7907 incorrectly. So we first charge 2,600 first which is as before read the account which is the same before and then read the code directly using the code hash and this is something that is can be broken if the code size can be greater than 24 kilobytes because we undercharge the corresponding the expensive resources just like take a wuber I only have $10 but I want to go to the airport and then the driver did not check my balance and I get to the airport. I'm sorry that it costs 50 bucks but I only have $10 to pay. So damn, this is definitely kind of an

attack scenario even though if we charge this gas later but since this expensive operation is happens before we charge this excess gas. So that will easily create a tag that can read gigabytes of data. is supposed to support 256 kilobytes contract limit. Um so the basic idea to try to solve this problem is to have a way to know the contract size or know whether the contract is a large one and its corresponding size. So here is one of the implementation that we are proposing. Actually there are three different types implementation try to address this problem. So the first

here I introduce the per the simp one which is that we have additional index tells what is the code size of the corresponding cohash and then so that we read this data first because the size data is much much smaller in general less than three or four bytes so that we can still use the 2,600 gas to cover this cost and then once we have this information we can calculate the excess gas and according to our formula and then and then charge the actual excess gas before we really read this contract and this is really simple idea to solve this problem quite straightforward but

we'll see that there's a different concerns because actually you can notice that we have doing additional small IO's here that is read this contract uh code size compared to the left hand side implementation And also we need to implement this data structure for existing clients. So this will take extra efforts for existing client to upgrade their database schema to support this indexing even though like this is viable solution but this definitely complicates some of the implementation of existing clients. So this is the basically all of the details of pseudo go how we implement EIP7907

but now I would like to dive into advanced topics uh when we implemented 7907 and also a lot of discussions with core developer to see other problems. So one is the cold warm state for the code itself. So in theor they introduced uh the cold warm state kind of like cache mechanism in EIP 7929 and unfortunately they is missing the corresponding state for code. So we are also going to introduce that in this EIP and another question that I also already mentioned is how we are able to implement efficiently to read the code size. Is there any other approaches? Um

so here I will give another two implementations and also we have done a lot of analysis on other causes that may be impact to the performance of the EVM both in terms destination analysis and also when we have large contract suppose the contract will have the code that to try to invalidate evict the cache page cache or ly2 cache because the contract can be super then what is the performance impact? So there's some topics that we we found and there's also a couple of other topics like how to choose the exact uh gas function or ext.

So EIP 2929 introduce a coarm state which means that for example when the first time I call a contract it will use 2,600. However, when the second time when I call the contract on the right hand side, it will only use 100. The reason is that when I call the contract the second time, the account and it's code is already warm or already in the cache. So when I call it first second time I basically just read the data from memory and there's no expensive storage read and that's why we do not need to charge 2,600 and we just charge a minimum 100 gas in order to cover the corresponding

memory cost. So this is really really helpful for a lot of uh like developing smart contract especially they observe when they call a contract some contract frequently their gas price is significantly reduced because of this cache mechanism. Unfortunately this cache mechanism only applies to two objects in Ethereum like state system. One is the account. So this is the we can see this read account and second is the storage slots. For example, when I read the USDT balance again and then read a second again, then it will only charge 100 gas for the second time uh reading. Unfortunately, the code itself is also a special object and take a

considerable cost in terms of storage. So right now we miss this code one state for the code and so that's why we explicitly add this code one state for code in EIP 7907. So suppose in the same transaction we call a contract maybe this contract can be super large maybe 256 kilobytes. The first time we will fully charge this contract using our formula that's two 2,600 plus the excess cost. But for the second time when we call the contract and if we detect this code is warm then we are able to basically access this 256 kilobytes of the code in just 100 gas cost and this

will be greatly useful for for example calling us large contract frequently in a single transaction and one thing we notice is that in EIP 2930 there's called transaction level access list which allows to pre-warm corresponding objects that is account storage slots before execute this transaction that's just after 2929 so we call transaction level access list so unfortunately since we do not would like to change the EIP or made further improvement on EIP 2930 which will introduce a new transaction type the contract code a warm state will not be able to preform by the previous

EIP 2930. That is some future topic that we can cover in the future uh EIP. So another issues that we uh have been discussed a lot uh recently in the discord channel is to how we are able to read the code size efficiency. So there are a couple of concerns of using an index of code hash to co-size. So first we have to update the current database schema. So for example all the existing suppose I have a node that already running with a lot of old contracts. Now I would like to upgrade the node to support the slash contract. Uh which means that we have to upgrade existing database with existing data. We need

some technology called back filling which basically idea is to have a backup thread that background thread that is scanning all the old contracts and try to write this index and definitely create some additional complexity to implement this feature and also it require extra DB lookup so that we can charge excess gas before we read the code from the database. So this uh create a little bit extra latency compared to previous implementation. So we have two methods to try to read this code efficiently. So first method is to reuse a lot of database features. So

made most of databases actually already knows the value size the value size that is the the code size before we actually reading it. But unfortunately I think this is a really really special case for for our blockchain uh because we want to know how many resources how many data we want to read before actually reading it. But there's a really really few use case for existing database. So most of them or all of them to our knowledge did not have this API public API to tell what is the size of the value of a key. The key is the code hash. So in order to support that you may have to either create a fork of this database to expose this API

or ask them to see hey whether you can expose this API to the public. So this may take extra times or maybe extra maintenance effort. So but we would love to see how the database also can be involved to support the different applications especially blockchain applications. There's another method here is the second method we call large contract detection. It is a little bit complicated but the basic idea is try to reuse existing data schema but when the code is greater than 24 kilobytes then we write the existing code hash to code schema with the first 24 kilobytes plus additional information that is the

number of bytes of the code. So this actually I should probably highlight this part. So this is the when writing this part how how we write a special code so that we we can allow when reading a contract we can detect oh this is a really large contract and this is the size but without introducing additional indexing or additional DB reading but just read two data where first data is the first 24 kilobytes of data plus the metadata of the code size and then read the rest of code and put together to obtain the full code. So this is another solutions and one question of this solution is that

whether there exist a code before EIP170 that has a contract that with greater than 24 kilobytes otherwise the whole assumption will be broken because we assume all the contract smaller than 24 kilobytes and thanks to the community developers in the discord channel we basically iterate all the contracts existing contract in file all of them is less than 24 kilobytes So which means that we can use this way to have called to detect a whether a contract is a large one or not. And another topic is called jump destination analysis. So what is jump destination analyze? It's basically to find all the valid or invalid jump destination of contract. So

that this is a safe feature of if you're virtual machine which is able to when I jump. So for example I go to another instructions that is to another arbitrary location of of the code. We want to avoid this jump to jump to we call the data section of the code. We want to make sure is called to a really cold section of the code because code consist in the EVM the code is mix of the code section and also the data session. So if we jump to the data session of the code it will become invalid and then it will be automatically reverted because it cannot pass the jump destination analysis. And

so this issue should be addressed by UF which we separate the code and then on the data section so that we can have a more clear uh jump destination analysis. But right now in the Ethereum we have to scan all the code in order to figure out which locations are valid or not. Um so thanks to Charles Cooper he is also the author of the EIP7907 he has done the benchmark to evaluate the performance of the jump analysis for very large contract for example can be right now the example on the right hand side can be up to 15 megabytes. So the result on the right hand side shows that actually you can check the fourth column

which shows the processing rate of kilobytes which we observe that when the contract size is reaching some large number because we can reach some constant number it's a stable number if the size is large enough then we see that actually the size the processing time per per kilobytes is constant which means that the cost is linear in terms of size. So which means that as long as we are able to charge the core in using the linear size equation for example in the current excess equation then we should be able to cover the corresponding jump destination analysis cost uh in our benchmark. So I think

this is really great result and would love to encourage you to deeper look at the how the benchmark is being done and how to obtain these numbers. Um so the last advant topic I would like to discuss is to how the large contract may make impact to the the caching. This include page cache in include L1 L2 cache. Basically the worst case scenario we want to investigate is to see if we have a contract that have a pure long jumps of different locations of code. So that you will try to evict the cash and then create additional cash cost in terms of when when we calling the

contract compared to smaller ones because the small contract we can put in mostly into the cash. So we don't have this concern but when this code is large or super large then the cache effect will uh kicks in uh we kick in and then uh it may hurt the performance. So on the right hand side is a very simple assembly code that I wrote to create a contract with uh just purely random jumps and then we run this contract simulate the execution of the contract on some common PC including my MacBook and also Intel x86 machines and the early result shows there's only 1% difference mainly

because right now commodity PC has very large cache like for example L2 or L3 sometimes have couple of megabytes or tens of megabytes. So it's still able to fit the whole contract code into the uh cache cache like a layered cache and however if you would like to run the contract with smaller caches on some weaker devices um that may create a significant different numbers but unfortunately I don't have these devices so I'm asking uh more community help to figure out the the performance difference there. So that's pretty much all I would like to share in today's talk. There's a lot of references here.

I would love to encourage you to visit live discussion in Ethereum R&D is still actively discussed in the Ethereum RND especially some like topic I just mentioned and there's also other we also have a prototype in gas and execution spec and then so that it basically kind of like uh you can compare with my pseudo code which I uh show before and then you can also take a look at our benchmarking um and then try to play some of them to see what's the difference there. Um so many thanks for inviting me to the uh to the talk and also would like to thanks a lot of people including Charles Coper um and then to make everything happen for

the EIP7907. So yeah love to see how the eventually can be included in the the next upgrade. Yeah, thank you. Thank you so much key uh for explaining all these. This EIP is substantially increasing the hard contract code size limit from 24 KB to like almost 10 times or little over 10 times. For people who aren't aware, this proposal was recently documented. It was documented in March 2025 and this is a standard tracks core proposal. So definitely we need to see this proposal in some kind of upgrade and we are happy to share that it has been selected for consider for inclusion. So many congratulations to

you and the co-authors to getting this proposal so far. Thank you. You have mostly answered questions that I was having on my list but I would like to get clarity on couple of more things if someone may have missed it in the presentation. So my first question to you is with respect to the gas per word. So why was two gas per word selected and is it the same constant that init code word cost from EIP 3860? Yes, that's the idea that's proposed by Charles Cooper and so I think I believe the basic idea is the same as the try to address the in code. So that is the almost the same actually or was also proposed not documented but in the

discussion to use a more conservative number which is uh so the gas SAS gas will be the number of the 24 kilobytes of data that read so round out number of the data that is per 24 kilobytes and times 2,600 that's another number that was uh proposed in the in the old standard. The basic idea is try to see hey suppose I read a contract with for example 40k kilobytes then I will charge the twice of previous 2,600 and that's another another excess gas parameter that I would like to probably better compatible with the

existing contract course. So I have suppose I have three 24 kilobytes in a big contract then I just charge three times of 2,600. So that's the number that we choose. Still this is not finalized here. So we still there's a lot of discussion how to validate this the this equation and whether we needed more benchmark but I think this the basic idea is how we are a able to make the size made the cost in is linear in terms of size. I understand when a proposal is CFI then it means it would be selected for one of the devets that is proposed for the network upgrade. So do you think the devet testing could help you get finalization on the number that is selected here? So I think devnet

definitely we can help uh but before that I think we would like to investigate all the worst case scenarios because even for devnet nobody like there's a very few people try to attack that net these days right so so it will be really to see whether it works properly with other components for example dev p2p or those components that we haven't be covered in our design but a lot of worst case scenarios for example jump destination analysis and also So caching all these things will be easier to discover by our benchmarks. So yeah we would love to see that net may discover more problems than our expectations. So yeah the early the problem discovered and the last cause we

would like to put make it happen in the in the main net. Yeah and I noticed in your list of thank you was Marius. Marius is one of those people who love to like spam and go for more and more testing on DevNet. So we hope that this will be tested and we could get the final number over there. Yeah, sure. Well, I noticed at present the reference implementation in the EIP is pretty empty. However, I have also noticed that in your presentation where there pseudo codes. I'm just wondering is there any consideration of adding these pseudo codes as reference implementation in the EIP? Oh, that's a good question. So the thing is like we haven't add this

reference implementation is that the exact implementation of how to read the code size should not be like restrained by our reference like implementation EIP. So EIP is more instruction say hey this how we can do we can maybe can list different types of implementation to read the code size but we shouldn't say hey this is the only way you you implement a client any client can choose the way they would like to prefer to read the code size so that's why I think if you check the I think I list the the execution spec this one here I think this is really really excellent pseudo code written in Python much better than my I would say my pseudo code my pursuit code is probably the minimum positive code but it's not able to functional. So

this is Peps most functional execution spec which give you very simple elegant way how we are able to put into execution spec and almost runable in a Python language and also we have a goer implementation and other client implementation should become quickly but it should not be that difficult so that for other clients they can take a look and see how it works and then and then yeah definitely if people asking say hey we need more information in this in the standard then we and include it. But yeah, that's the current say we don't want to like say hey this is the actual implementation. So we also discussed questions this concerns with Charles Cooper and then we our conclusion is we do not change the standard at the

moment. That sounds good. I pointed it out because we have noticed sometimes like it still remains in todos while we do some kind of like testing and reference implementation is documented somewhere else but not in the proposal. So just a reminder maybe before moving the proposal into review status if you would like to add the execution specs link over here that can help other clients implement it would be nice to have. Yeah that's great. Yeah very well in the presentation discussed about some of the tradeoffs like trade-offs with respect to 2930 is already explained some limitations concerns using index are also there. I'm trying to understand if there are any more tradeoffs that you would like to share with the community

or the smart contract developers should be aware of. So another trade-off that actually I al also working with the Charles Cooper is regarding the memory size uh limits of the FDM. So for example in Ethereum when we deploy a large contract we first have to prepare all the code in the memory and then return this data to the EBM to tell what is the actual contract we want to deploy. So suppose the contract right now is 256 kilobytes which is our limit. It also take considerable memory cost because the ethereum memory cost is a quadractic which is the memory cost is quadratic in terms of the memory size.

So when we deploy large contract the developer may found even though the cost we break this limit cost is expected in terms of deployment cost but the actual cost may be higher because it consume more memory which is also out of the original design of Ethereum. So that's why we are proposing another EIP try to solve this memory limited problem. Actually we also noticed this problem and try to replace this quadratic terms we also using just pure linear terms but definitely there's also a lot of things that need to investigate in both in terms of performance for example as I explained suppose we have super large

memory which can be a couple megabytes or maybe tens of megabytes which we can allocate and then this caching mechanism and all those things also create additional concern in the full analyszis. So yeah, we also have been done a lot of benchmark but I'm not sure that EIP will be included in the Fukasa maybe in the future because we don't want to take the full plate at the first time just like make sure we address the most painful problem one by one. I really hope keeping my fingers crossed it should get included whatever issues or challenges we may have should be under control and if it is found indefinite that would be nice to have.

Yeah. Well, if you have to suggest what kind of applications do you think that will stand to benefit the most with this proposal? I feel a lot of smart contracts especially company ones will be benefit from this EIP. I can name a few. Example, when I try to deploy unis swap three and try to add some features by myself and then and then I can easily hit the contract coas is great exist limits because I I think I believe when the unis swap developer when they develop this smart contract they already found this problem and then carefully organize their code to make sure they do not break this 24 kilobyt limits. For example, they separate part of the

mathematics library out of the contract and do the similar trick as explained split contracts into smaller pieces. So with this upgrades I think all the developers when they try to for example deploy or reuse existing contract try to improve on top of that can be easily done without carefully reorganize the code and maintains this code. So in general as long as that your contract is a little bit complicated I believe then you can see that how the difference before and after this EIP. Very well. My next question is with respect to one of the most popular EIPs that was included in the Pectra upgrade EIP7702.

Would you say that this EIP in any way relate with EIP702 delegate execution model? like if it does will it benefit user or implementer of this proposal? Yeah. So we carefully examine all the how the code being implemented in 7702. uh one thing is notice that for 7702 is able to upgrade EF to smart contract based UA and then so but the actually the code that write to the contract right to the EOA is very small that is I believe the prefix that is I think four

bytes or eight bytes and then plus the address 20 bytes so in general it does not break any assumption 24 kilobytes greater than 24 kilobytes assumption in our line. But there's a couple of things. For example, when a contract started and then it will try to authorize a list of the code to delegate to another code and we found there's a couple of attacking vectors because this authorization and then they may authorize delegate to reference to large contract and if without proper guess metering it can be easily be attacked.

Basically any pieces of the code that try to read the contract code in the client we have to carefully investigate to see uh whether it's properly charged before we really really read the code. So there's couple of the details implementation actually all of them has been addressed in the prototype and so at this moment we have exam all the reference of reading code contract and then make sure they're properly charged and then put in the prototype. So yeah, we are pretty in high confident that uh we there's no such concern introduced by EIP7702.

Yeah, that sounds quite comforting. And my next and perhaps the last question with respect to this EIP is about the other contracts which are already existing. Is this proposal backward compatible or how do you think it is going to affect already existing contracts? Yeah, it's fully backward compatible. So all the existing contract will be at the same using the same gas cost and using the same for example reduce the gas cost using the the warm up cold state and so everything we do not break any existing contract. So yeah everything will be work as usual. That's very good to know and perhaps this could be one of the reasons that despite being an EVM proposal it is being considered for inclusion in the upcoming network

upgrade. Well, thank you so much key for sharing a lot of information about EIP7907. I would like to quickly take a few moment to talk to you about some related but interesting aspects of you as a person that would help our community to know you better. [Music] This is called as rapid fire round. We try to collect information or response in one word, one sentence or very few sentences you can use just to respond to some of the questions. Would you be open to that? Yeah, of course. Very well. My first question is one EIP you are most excited about it right now. So I think

this EIP 7907 defin is most exciting about. Actually this is not the first EIP I try to address problem. I actually have draft a previous EIP. uh I forgot the number but it's starting from four or five you can imagine according to the number that's a couple years ago uh to address this problem because also a contract developer I have to roll a couple of contracts I really love the idea of the contract and I love it I really enjoy to put a lot of different applications enabled by smart contract but unfortunately when compared to my web two developer experience I found there's a lot of this limitations uh both in terms of contract size also memory science. So, uh I think this is something that I feel we can improve a

lot of like save our life kind of that's why I was super exciting to for this EIP and definitely I have another more precisely it's not EIP ERC that's for 49 4804 and I try to converted Ethereum into a decentralized unstoppable uh HTTP server and that's really interesting idea that I'm still exploring for and so we would love to see how we especially enable a lot of new applications on top of Ethereum. You have authored multiple EIPs and in general it happens in the ecosystem that not all drafts reaches to the final status. So if there is an EIP for which you would have wished that it

got adopted but it didn't what that EIP would be? I think a couple of the IPS but one of the like eof I think this is a really interesting idea how to make the the code format and better organized for example I just mentioned the jump at destination analysis it can be completely eliminated by the UF but since it has rather radical changes of underlying format so I imagine that still take a lot of time to to make it to mature so before doing that I think it would be great if you have better ground to to test this in more near production environment. So yeah, but that's something that I would love to see how we are able to to speed up this EIP process. Yeah, very well. EF is

definitely out of Fusaka, but we can consider it for Glamsterdam. So we'll see how it turns out to be. And talking about EIP process, what would you say is your favorite part of the EIP process? Yeah, I think the EIP process so it's really everything is open. Everybody really love to especially discuss the how to make sure the EIP from different aspect especially I through this process I know a lot of friends I also learn a lot of things that previously probably oversimplified how to make a EIP to become a mainet especially for example previously I haven't done too much benchmark in terms of caching and also jump destination analysis and especially

how this work for the existing code how other people has been done to support this because when we just read a go ethereum code or when we read spec there's a huge it's like iceberg so there are the eyes on the top which everybody can take a look how it works but there's a lot of underlying why we do this what are the concerns what are the other considerations because designing EIP is a systematic work it's not just a smaller pieces that like in web3 system that we can fast iterate a version every day and deploy and if something's wrong then we can roll back.

No, this is not the case in web 3. We have to make sure everything is correct. So there's a lot of tooling benchmark all those discussion information they're flying around. Um so especially from outsider perspective I have met a lot of different people that not familiar with EIP when they discuss oh if you should do this you do that I say hey do you know that there's a lot of considerations when you implement EIP do you know that you have to use these tools to test benchmark all those things. So I think it would be great we have a way to more have more tell people the underlying the iceberg how it looks like and then so that people can better understand how they are able to contribute to the ecosystem because like

the simple wording is effortless right but you know there's a lot of things that happening under the hood so yeah right and if you have to say like one of the hardest challenge in moving the EIP forward what that would be I I think is still the how to make sure like everybody has different concerns. So how to make sure everybody is be able to align on the same page. So they have concerns of the memory, they have concern of caching, they have a concern of the storage, they have concern of the upgrading database schema. So addressing all these concern and different client may have different concerns because they had implemented ways in differently.

They may have different databases. They may have different database schema. So aligning all all people to get it on the same page I think is most difficult part but the good thing is like so everybody is really willing to contribute this we're really everybody admit that this is problem we have to solve it no matter it's 256 kilobytes or maybe smaller maybe 64 kilobytes we definitely we have to should to should to should to should to should to should to should to should to should to should to should solve this problem so I think as long as people have the same goal and people gradually discuss all the thing in a logical way by filling the information that everybody is missing. I especially love the discuss channel in the R&D. People at the beginning have a lot of you can clearly notice that people may have

different pieces of information but jointly together people gradually align with the is how we can achieve this goal and people agree with each other. So that you can imagine this is a really good joint work with all these people uh which I name in acknowledgement and not just my single like contribution. So I really enjoy this process with the uh joint efforts from everybody here. Harding the developers can be challenging sometimes. Yeah. Yeah. Very well. A founder or a builder in web3 space that you admire the most. Oh yeah.

I think definitely Vitali is the person actually I work with her him like some small grants and like for example to bridge and then also discuss with him some different topics the storage or memory all these things so I think I really mind that he's really openminded so you can really to talk with him no matter online or offline and then sometimes I also feel he's overwhelmed by a lot of uh different signals or Sometimes maybe a lot of noises but I have still he would like to listen to what the community the voice from the communities and sometimes I feel like if I change for me into that position it will be a lot of pressure because have

to deal with a lot of this uh informations and sometimes I feel like oh that's that's too much uh burden for if for like from my understanding. So my VC is doing pretty well and definitely I think Ethereum will it should not be ecosystem should not be a single point failure then we should have more people that work together. So for example in this EIP I don't think there's a lot too much contribution the Avitali is aware of this but I personally like talk with him about this direction he's like yeah this something that really should make it happens uh for for example made 128 kiloby size or something like that. So he is aware of everything but not

necessarily joining all the details trusting everybody in this experts can address all this problem. Yeah that's great. Yes he is a great inspiration in the ecosystem and he's definitely open to talk. He has been kind enough to show himself on penip and explain the proposal that he wants to share for the ecosystem betterment. So we are so grateful to his work here. Yeah. Well, key that was incredible, insightful. Thank you so much for walking us through the motivation, mechanics, and the trade-offs of this proposal. We hope that this proposal goes into the Fusaka upgrade. It's already in CFI, but we hope to see it getting promoted and

getting into schedule for inclusion soon. Thank you for joining us here today. It's my great pleasure. Dear listeners, if you would like to dive deeper into this proposal, you'll find the links in the show notes to the full EIP community discussion thread and other supporting resources. As usual, if you care about Ethereum's governance protocol evolution, consider sharing this episode. You can also support the public good works that is being done with Ethereum caturders by donating them at eatcatthurders.com/donate.

Until next time, keep reading these EIPs, keep building good products, and stay curious.