EIP-7825: Tx Gas Limit Cap & EIP-7934: RLP Execution Block Size Limit

Transcript

The bigger the block the bigger can be your biggest transaction and the bigger biggest transaction the higher the worst case and this worst case cannot be paralyzed. So we need a limited consensus layer so that we are sure that builders do not build such a block and this block is not valid. We need to essentially match the constraint on the network level to the consensus level so that it actually doesn't break everything. Paralization is important but it's more important is the security aspect like 90% is security 10% is full side optimizations which may or may not become significant.

[Music] Welcome back to Pepe, a podcast to follow the Ethereum improvement proposals and what's upcoming for the network upgrade. [Music] This is episode 151 brought to you by ECH Institute. I'm your host Puja Rand and today we are diving into two potentially impactful proposals. EIP7825 transaction gas limit cap and EIP7934 RLP execution block size limit. EIP7825

was documented in November 2024. This is a standard track core proposal in draft status and SFI stage for Fusaka upgrade. Whereas EIP7934 is documented in April this year and is also a foraka. This is also in draft status but in CFI stage. Hopefully we will get the decision of for inclusion in Fusaka devet version in the next allcore dev meeting. For people who aren't aware of network upgrade stages like what is CFI, what is SFI, so on and so forth, please check out our conversation with Tim Deco

on EIP 7623 network upgrade inclusion stages. We'll add the link in our show notes. Well, for today to provide an overview of why these EIP matters, why Ethereum devs are considering including these proposals on the mainet, we are joined by the CTO of execution layer client Aragon and one of the authors of these proposal, Julio Reebuff. Welcome Julio. Yeah, thank you for having me. Thank you for joining us here today. Well would love to start this conversation by introducing yourself. Maybe you can talk about your professional background and share what

inspired you to join the Ethereum ecosystem and how come you are into documentation of these proposals. Right. So yeah regarding the education the background is a bit complicated because I joined at the client when I was 17 years old. Yeah. So the background there is basically nothing other than the I mean I worked at another crypto firm when I was 16 but I was kind of an intern and I joined Eric when I was 17 and it was still called Turbogaf so I don't have really a background I kind of just uh like Ethereum is my background right so yeah well what I can say at least what I'm responsible for in argon so I was the principal engineer behind the merge in Aragon I then I kind of led

the development of the new data model and some other features in argon which is called Aragon free now. So I design essentially a good part of our new archive node format. I also have worked with other chains in the past with argon of course such as polygon and and now our bit room and right and yes and other than that I have contributed to AP implementation and now I'm the lead of the project I guess yeah so this is kind of my overall background which is just Ethereum because I it's it's the only job I've ever had. Very interesting.

Very interesting. I'm enjoining at such an early age uh directly into the blockchain development. It's commendable. I mean I'm super excited to learn more about these proposals as well as of you. I know we had conversation with Alexia in the past and for one of the conversation Andrew was also here. So good to see another team member of the Argon client then called Turboat. You are right there. Right. Yeah. super excited to have you here. Um I understand we have two proposals to cover. So without further ado, let's jump into the presentation.

All right. So I'm just going to begin right away. Okay. So today going to talk about two APs AP7825 and EP77934. These are essentially caring APs to essentially increment the gas limit and scale L1 in Fuzaka. Right now we are essentially aiming for 60 million after PCRA. We are testing it on the test net so it's going to go mainet soon. But with this this two this PS enables us to go further than 60 millions. And I'm just going to kind of explain why. So before actually starting I'd like to just go over what actually bottlenecks Ethereum very quickly because I think it's actually pretty important to understand why these APs exist. Also just to give a brief introduction of

each IP. One of them essentially caps the transaction gas limit and the other caps the bite size of the block. So they're essentially security/scaling a essentially dampen worst cases. But I think in order to actually understand this we need to go and just diverge a little bit into what are the bottlenecks of Ethereum and actually what actually uh we need to change in order to prove the gas limit in order to scale that one. So the first thing people usually comes to mind when we talk about can one is actually the state graph right. So right now the state curve actually was kind of a boogeyman has been throughout the years. What we found out is it actually not so bad because it essentially grow the state grows 30 GB a

year and the total state right now is around 150 GB. So here we've got kind of just the growth chart um from an article from paradigm and you can see that it's really and we found out that it's actually not so significant right now. Even if we double this in order to double the state you would need four years at 60 million. So the state growth is actually not the bottleneck right now incredibly. Another thing that come to mind is the bandwidth which yes it's also on everyone's mind but the thing is that the block is actually quite tiny.

It's essentially 200 kilobytes right now and 200 kilobytes is essentially one blob. It's it's one blob and a half. It's around one blob and a half. So really it's not even that it's not a lot actually, right? You can leave as long as you have a controllable worst case there. That's not even a bad thing because 200 kiloby is nothing really. It's more than a half. Another side of bandwidth is actually that the CL actually the majority of the bandwidth is consume is consumed by the CL. The CL does other than gossiping blobs which is the biggest data structure being gossipped. Anyway, they also have attestation aggregation. They they essentially constantly pass out messages to each other. And especially right now

because of the CL in order to stay sync needs to be around to require two megabytes per second worth of bandwidth while the suggested bandwidth is actually 50 megaby per second. But the point is that if you actually look only at the execution block it's not a lot. The most of it is in the CL and if you increase the block size you're not actually going to worsen the CL that much because the CL doesn't know about the block. It doesn't know what to do with it. So essentially on the side it's not even bandwidth really. Then there is history size. Another thing that people throw around history size is actually much more worrisome than state growth right now because and it's going to be fixed soon with EP4 force whether it's through portal or it's through some

other solution but people are actively working on this and it's going to be fixed soon. But anyway just to mention it history size grows I think by 200 gigabyte every year if I'm not mistaken. Yes it's that's per month. So it's 200 GB every year and uh yeah essentially what's going to increase the cost of the hardware actually not really state growth is still growth is actually much more worrisome right now but this is going to be fixed soon. So this is actually not on people's mind too much because this is already kind of a fixed problem. We just need to engineer around it and also it will take a a long time before you actually going to hit that level anyway with or without that wax in the gas limit. So it's not even that brought up that much. Uh lastly there is

computation. Even computation was one of those boogymans but actually it's not that bad. Ethereum goes at 1.2 megabytes per second while execution clients go between 200 megs and 1 and a half gagas. So computation is kind of cheap in this moment. It's not even the bottleneck. So essentially what is really the bottleneck? And in reality, as it turns out, yeah, it's simply that the protocol was not designed around the gas scaling L1 essentially, right? The protocol rules actually are your biggest and bigger. What protocol rules I'm talking about? So, for example, the bigger the block, the bigger can be your biggest transaction. And the bigger biggest transaction, the higher the worst case.

And this worst case cannot be paralyzed because if it's a oneb block transaction, you cannot split it right during the execution. Clients need if you want to uh implement some form of parallel execution you need to essentially somehow know what the bite code does but clients don't know to do it. So you essentially if you increase the gas limit and you don't have a cap on the gas limit you essentially end up with a very bad worst case which might even grow exponentially although we don't really know that but we don't want to find out it's mostly just a security AP and then there is also a bunch of things that and also it's in the way of proving apparently I this is like something I learned today it's in the way of ZKVM and so this is something that kind of limits us so the fact that

the transactions can grow unbounded with higher gas limit. So this comes the first CIP for example. FCIP is actually just puts a cap on the transaction and it dampens this worst case. Then there's another weird rules on the protocol which is on the network layer which is that blocks that are too big don't get uh forwarded. They don't get gossiped. They don't get put out by the client. However, these blocks are still valid at a consensus level. So what that means is that someone is that there can be a valid block that actually cannot get gossiped and this can lead to to kind of bad the DOS vectors. This is actually led by the fact that again we never thought that we might have went to big

blocks in in the past. So we never actually bother to fix this inconsistency at the consensus level. So essentially what the second AP does EP7934 is it essentially caps um it takes this cap on the network layer and it also puts another cap on the consensus layer so that it makes sure that block builders and simply or execution layers do not follow chains where blocks do not match the the networking essentially. So let's not go in detail into each of these changes right. So let's start by 7825 which is the transaction guest limit. So we need to handle the TX work in a reasonable way and also we want to have some degree

of parallel execution. So right now there is a lot of interesting clients to implement parallel execution. Aragon is working on it actively. I know Netherland and Baso. Bezo has something experimental I think and Nethermind also already have it. So essentially what we want to do is kind of make sure that when you increase the gas limit we don't end up in a situation where we assume increase the gas limit assuming a parallel execution but then because you can have one transaction per block. This transaction can completely force the sequential execution which means that it basically nullifies the parallelization of the parallel VM implementation and and completely throw it off the window and make us actually worse than the

normal execution. So we need to find a way to still make this to still force some degree of parallelization on the chain as we increase the gas limit so that these optimizations actually work and can be significant. So yeah, as also I already said before, there are some weird exponential cases with transactions. And the bad thing about this is that and exponential cases actually are really small in terms of impact when the gas limit is small because uh the way exponents work. I mean they work basically by exploding at at a certain point and just uh and then and then becoming unreachable. So it is there is a possibility that if we go past if we go past a certain point we might enable some DDS vector when where

essentially we have a certain op code combination that can send the gas that can send execution to say to minus right we don't want that because that would essentially stall the chain so yes this is also one of the things the thing is this we actually do not even know if these cases exist but we need to account for them anyway because in the future we might add the new opic that might cause this and we cannot and this actually makes us able to sleep well at night knowing that the worst case cannot get too bad right there is still a worst case but at least it's smaller it's tinier it's not as bad as if it just grows linearly with the block with the L1 scaling right so yeah then there is also other good things like for example

there are also other things this AP is probably also the simplest it just implies some basic basic filtering of the transactions and it basically implies a new very simple protocol rule and yeah just a basically a sleep well at night IP the main rational is the security aspect of it yeah and then there is also the parization aspect but it's pretty much it so let's actually move uh to the second one which is EAP7934 which is actually the limit on the execution block size which actually is of the same nature of the one before it is a security AP. Um just to reiterate what the EIP does essentially it establish a limit on the block size that

is at the consensus level. The cool thing is actually that every single other chain does this but we are the only one that don't do this like Bitcoin have this. we just don't for some reason and essentially the reason why this is important I'm just going to reiterate it is that right now we have the limits in this 10 megaby limits in many places except where it actually matters which is the consensus using the consensus rules and the block building and right now you could have a block that although valid cannot be forwarded so you can actually incur in some weirded US with this So here you can see actually by the way directly from the consensus specs I just put it here that both in FP2P and

both in lip in the lip specification of the consensus layer you can see that the max payload size is 10 megabytes you cannot go higher than that and in in both of them actually it's maybe bytes but that's just a detail actually essentially if you go higher than that the network doesn't break but your block doesn't get forwarded although it is valid right so what What does this mean? Essentially, you can have the message large error and what happens is that you can have an attack where a builder creates a block that is crafted to be above 10 megabytes. The block is valid and this build that might be able actually to send it through maybe some other channels to other peers. Maybe you

can do it through DVT through other systems. But the better is that once it is propagated through the FP2P, it doesn't work. So nobody sees it. So you can have essentially some sort of chain split and that's kind of bad. Another bad thing is that these transactions will leave on in the mele which will essentially make the same builder build this kind of blocks which will lead to even which will lead to essentially a quite bad. You can have the chain down for two minutes and in proof of stake you cannot have that because then you have inactivity leaking and that's very bad. And so yeah, this is unfortunately what would happen if we went too high.

So we need a limited consensus layer so that we are sure that builders do not build such a block and this block is not valid. We need to essentially match the constraint on the network level to the consensus level so that it actually doesn't break everything. Right? So yeah again it's just network layer and a protocol layer inconsistency. It's um and we just need to fix this and once we fix this what you get is that we can actually probably go up to even 150 million was actually the number this was tested for and this was designed for. So this is essentially five times the current L1 scaling just by tweaking protocol rules which is quite funny actually and uh yeah this is it actually. Very well. Thank you so much

for this presentation and first of all let me congratulate you for getting the one of these proposals into scheduled for inclusion. That means it will be tested on DevNet now. The other one is probably going to go into by the way. Yeah. Hopefully we'll get the decision on which DevNet version the other proposal will get in by well 7934 is actually increase the gas limit after 60 million. So a variation of that needs to go in anyway. Yeah, there's been some discussion, but the reason why it was not decline for inclusion is because this change is kind of needed anyway, but people are not sure if the qu design is good, but that's pretty much it essentially, right? So, you should expect something similar at least to go.

That is good to know. At least people are aware of it that something is coming up and we can definitely adjust the limit in upcoming upgrades. So, let's start with EIP 7825. 7825 suggest introducing a cap of 30 million gas on individual transactions to like uh help with the DOS attack as you have explained in block processing. So my first question to you here is how did we arrive at this number the 30 million gas number and what kind of transactions do we think that can be safely accommodated in this 30 million right so the 30 million gas is actually the gas limit of the Ethereum network when I wrote the AAP really uh the

reason why it is 30 million is because unfortunately there are some cases that require 30 million transaction gas for example the Optimis protocol upgrades, they have to make a call to a contract and this contract in this contract interactions cost up to 27 million which is a bit close to to the max and essentially I just decided not to really try to go down. Many people actually want to go lower because you make the parallel EVM case better.

But right now we decided that that since it's a bit uncertain since we agree that this is needed but it's uncertain whether going lower actually is possible and the and the big applications such as optimism contract upgrades it basically made us still stay at 30 million and then reconsidering it for glamsterdam that's essentially our tense right now basically right yes and I was following the allership of Ethereum magician thread for this proposal And I noticed that there was a suggestion of setting the cap a little lower at 2 to the^ of 24 or minus one around 16.7 million. So why is that we are going with 30 million

and then trying to think of like whether increase or decrease the gas limit. Why not begin with the lower limit here? Because the priority I think is to scale that one. We don't want to break application yet. So I think looking just at the numbers here, a 5x improvement from now is something that we need and it's something already pretty significant. If we actually decide to go to 150 million and I think that it's not really worth bringing application. I think most of the benefit it's in the scaling then yes we can decrease it in the future of course but unfortunately for the first iteration I just wouldn't do that. Um I just wouldn't do that because that's not why I wrote the AP really right paralization is important but it's more important is the security

aspect like 90% is security 10% is cool side optimizations which may or may not become significant and the good thing is here is we got rough consensus in the meeting so hopefully we will keep the limit and we'll see what to do like if we have to make changes at all. You mentioned about parallelization. So could you maybe explain it a little bit how it is like nullifying the parallelization effect here? Nullifying it's not nullifying. So the AP doesn't nullify it without the AP it can be nullified if you have a parallel implementation like neither mind does right because if you have a one transaction block right you have only one block with a single transaction you

cannot parallelize that the transaction it's impossible right because it's only one transaction like what do you run in parallel with the transaction nothing else because there is the transaction in the block essentially so this is actually the paralization aspect essentially if you have only one transaction that essentially in a computer you have multiple threads Right? Multiple like mini computers. You can think of that that way. And essentially the way the implementation of the pleium works is that you essentially put on this mini computer one transaction and then you let them execute it. But if you have only one transaction block then essentially you just have one computer doing the work.

The other one don't don't do anything because it's only one transaction in the block. Yeah, that's it. Yeah, that makes sense. Well, I understand the proposal suggests that if there is a transaction over 30 million gas that will be rejected with an error. So where exactly is that enforced? Is it at the JSON RPC level or the transaction pool validation it's in block validation the rest is kind of an implementation detail in my opinion. So if it's in the validation, it's everywhere else, right? Because the trans if the transaction is invalid in the validation, you don't want it in the transaction pool and also you don't want it even to be considered in any other part of of the of the Ethereum of the

Ethereum protocol. So I think everywhere is the actual answer. You need to put this check kind of everywhere. So do we want to specify this in the proposal? Like if it is at validation level, definitely it's going to be everywhere. If we specify it, maybe it add more clarity to the proposal. Yes, I could add more character proposals. I think I can do that. Yeah, why not? Yes, I can do it. Yeah, sure. But yes, it's validation. It's purely validation. But validation also entails that everything else also needs to change because you don't want invalid transaction in the transaction pool, right? Yep, that makes sense. Very well. We generally understand that gas is a critical part of Ethereum architecture, right? How does it affect users and developers

today from your perspective? So my personal opinion on this is that probably in scaling that one is probably the most important thing we should do right now because it's essentially the one thing that has demand on the network. We have two things that we sell blobs and gas limit. The blobs is kind of blob there are enough blobs but there is definitely not enough gas limit and people have been complaining about it for like years now. So essentially we need to get on par. We find we need to finally get our stuff together and actually fix this because there is a lot of benefit and improvement that come from a gas limit. Just to give an example, 7702 is completely useless without a decent gas limit. Like a transaction from a smart wallet will be too expensive on Ethereum mainet if

there is usage, if the gas limit is too low, right? Or nobody will actually pay transaction for their users if the transaction cost too much money, right? Like most of these UI exchanges all depends on scaling. Without scaling 772 for example, it's in my opinion is completely worthless, right? Yeah, I understand. 7702 is one of the like most important EIPs those shipped with the PETAR upgrade. So it would be helpful to like have additional proposals which can like help this proposal work the way it is expected to. Yeah, I think now it can be only used on L2s. On L1's I don't really think it will get much adoptions until we increase the gas limit. That's

my view on it. All right. Then sooner this is on mainet better for the developers working on contract side. It's better for everyone. Well, I'm curious to hear your thoughts like because this is kind of limiting here the gith here. Do you think it will introduce any kind of barrier for developers who are or maybe planning to deploy large or complex contracts? Contracts are limited by size right now. So there is a worst case already specified and it's much lower than 30 million. So the contract is not the problem. The real problem that was actually I mean there is a a concern that was brought today to ACD is that account abstraction bunders cannot do

one block one transaction per block. But I think there is consensus that one block transactions are not really good for the network. So but that's kind of the only concern I will think of. I think really 30 million 30 million gas is what we had for the past five years, right? So essentially what I will answer the question is that you can still do everything you could do before but you can also do more right it doesn't limit you from before but it just makes things better essentially that's how I would answer the question very well answered dear so just a follow up on that do you think this proposal will impact node operator validator or light client in

any way either positive no it won't it won't imp well other than implementation it won't impact anyone like it's a it's a very small change. Yeah, it won't impact node operators too much like they won't notice it. I mean they will see more gas limit maybe but but that's a second order effect. They won't see any first order effect of this proposal. Very well just out of curiosity like are you aware of any L2s or any other EVM chain those may have implemented sim similar cap or limit on the transaction level? Oh, there. Well, I mean, the only chain that implements a cap that I know of is Solana. The rest doesn't, I think.

Yeah, I don't think there's any chain that does it that has a cap right now, at least that I know of. Very well, we can maybe now switch gears for the next proposal 7934. So for that my first question is why do you think it is necessary to cap the RLP encoded block size at 10 MIP like how did you reach to this number here because it's the number in the networking specification that's why the whole point of the AP is to match this constraint with the core protocol right so we have to use the same constant which use in network which right now it's 10 megabyte that's it right and this proposal it actually separates

creates the block size limit from gas usage. Why do you think it is important like uh we already have the other proposal 7825 which is for gas limit here. Do you think both together can help against the task risk or can independent proposal also would have worked? No, I don't think no these acts on on different levels. So I don't think one proposal would have cut it because the thing about this proposal is that if we go past 100 million gas limit we essentially get the point where this attack is possible right but there are two different attacks right you can imagine one is a security AP that dampens and potentially exponential cases and this one you're essentially

just fixing the protocol like this just fixes the protocol like the fact that this check doesn't exist is a bug in the protocol ultimately it shouldn't happen Yeah. So they have to be separate unfortunately. Sure. I have seen many proposals which are kind of a bug in the protocol or something that we ignored at the time because that was not of high importance but we have those proposals to kind of fix it and people are generally supportive of such proposals because no that is trivial and it should be fixed now. Yes. So this is one of them.

Good to know that. Well, when we are talking about gas limit and block size limit and everything, one question that comes to mind of mostly developer is about security consideration. So, what would you say that any implementer or developer should keep in mind while implementing these proposals? I think the only proposal that needs to have some serious thought behind is actually 7934 which is actually why it hasn't been as scheduled for inclusion like immediately. It's because essentially it's not complicated but it needs some thought behind it right because the block builders now need to essentially count the size of the block they're building right it's probably trivial and there is already a side implementation from nethermind that shows it is kind of

trivial actually to do and yeah so the only thing that you need to be keep in mind is that if you want to implement to put the cap on the block building you need to choose a uristic that makes sense and that is in the constraint of the new consensus rule That's all I could say to an implement really about 7934. 7825 is it's so simple that I I don't even know what I would say like just to put the if statement. Honestly, that's what I would say to implement. Sometimes the documentation uh can be misleading. If I'm looking into these two proposals, I see the bunch of security consideration for 7825 but only one for 7935. So well well security

consideration I well okay maybe these are like I don't write EIPs usually so I don't I just thought that the security considerations was something for the protocol like in general like for example if you increase the gas limit in a proposal the security considerations would be home stickers might be in danger for example so I really didn't have in my mind implementers when I wrote the security considerations yeah but these proposals are coming from client developers because you know they also have the perspective of get into the client and some idea of implementation already right yeah very well that kinds of conclude for the questions which are specific to these proposals uh anyone on the call if you have any question please feel free to

drop it in the chat and we will invite you to take the questions but in the meantime we can have some easy relax and fun time so we are moving to our next section which is called rapid fire round. [Music] So Julio in this round we generally try to collect answers from you to know you better. How do you feel about the environment, the Ethereum and things like that? So it could be one word and we can provide you some options you can select from that. Sounds good, right?

Yes, sounds good. My first question is what inspired you to get into Ethereum? open source economic decision or decentralization the permissionless aspect of it before client I actually was studying solidity the cool thing about deploying contracts on on the on Ethereum was actually that you could essentially manage I wouldn't say people's mind but you could manage something that has value in a programmatic way and you can do it in a permissionless manner and that's I think one why I came into Ethereum it's because it is permissionless that's the most important part for me of Ethereum.

Everyone can join it. Awesome. And I think you have partially answered my second question is still I'm going to ask this question from you. If not client development, what would you build? If not client development, so well this is actually funny because before actually when I was 14 years old, I was working in a robotics lab in Italy. I wasn't working, I was kind of all being there like I was just present, right? So I think that if blockchain didn't exist, I would have unironically become an AI developer. Unironically, I would have ended up like that if blockchain exist. If blockchain did not exist, but I ended up becoming a blockchain developer, unfortunately or fortunately, fortunately for us, yeah, thank you. Well, my next question is

what excites you most in Ethereum now? You can talk about any feature or any priorities in the client. So, I haven't been excited and don't take this answer too badly, but I haven't been excited since the merge because that was such a huge feature and uh that nothing comes close to it. But I would say that uh right now I kind of look forward for Fuzaka and for the L1 scaling. I'm not super stoked for Pieras, not because I don't like it, but because kind of I don't think it is as important as L1 scaling right now in this exact moment.

But anyway, yeah, that's what I would say right now. Very well. There are so many proposals, so many features. So, I'm sure that there would be something much more exciting coming up in the future. I don't know if it can be matched with merch, but definitely good features are on the way. Yeah. Yeah. Well, my next question is where do you learn the most? Is it magician thread? Is it developers call, the code calls, or crypto Twitter? I learned the most in the past. It was a mix. Right now I learn the most through Chip PT research.

So yeah. Yeah. Help these days. Yes. That's how I learn the most now. I basically talk to it every day now just to learn the new technical stuff just for fun. Good. Well, how does a EIP idea come to your mind? Like is it by looking into the real pain point coming up from technical debates or just random thoughts? Oh shower thoughts like I think I came up with both of them when I was on a train in vacation and I was just casually chatting in the gas limit testing group chat and that's it. That's how I came up with both of them. Relax minds give you better ideas. Yes, relax mind then.

Right. What's one thing in Ethereum that developers need more? Better tooling, clearer specs or better coordination? I think right now if you're talking about DP develop, I think a better tooling. I think with 772 that part will be sped up because now there's actually decent UX on which we can build tool from. There is a new framework on which people can build wallets. If if you talk about in implement, I think probably specs is the best things really for us. As far as I can tell right now, I think unironically this is kind of probably a polar opinion, but I think that implementing art forks in a of Ethereum is not actually that difficult because the difficult part is actually figuring

them out and specking them. So, I'd say specifications. Cool. Uh you have started pretty early. So, if you have to see Ethereum after 10 years, how would you like Ethereum to be known for? like would that be a best coordination layer project, an application platform or anything else? I'd say uh it's a hard question to pinpoint, but I'd say maybe I would still throw around the word internet of finance because that's essentially what I think is the overarching goal of of the blob road map and the L1 scaling road map. These two road maps kind of all achieve this kind of having this economy of the internet. You have a base

a robust based layer. Then you've got kind of these other app chains. We can call them app chains or just L2s that serve the users in the same way a bank would to some extent right not exactly like a bank would but with the same interface and with the same feel rightly better. Right. Well um you have worked since merge so you have seen so many proposals. What would you say your favorite EIP which is not documented by you? Oh my favorite EIP I think right now it's the block level access list because it's it's a new EIP. It's actually very recent but I think it's kind of brilliant because it fixes the protocol. It allows for very cool

things. It allows for partial stateances with a very elegant in a very elegant way. It's very simple and essentially it's yeah it's just very simple AP very elegant and it might even enable replacement for the statelessness effort which is very complicated and it yeah that's basically it I think it enables a lot of cool things like better block processing some form of partial statelessness and and that's it yeah sure we will look forward to that proposal well as per your uh development style what would you say it is do you just plan everything? You build and refactor, you hack it and then clean it up later.

I just do things like I I don't even act it. I I think when I have an idea, I just I just implement it, see if it works, and then maybe refactor it, but usually it comes well at the first try. Uh in terms of code quality, I'd say I just uh I'm very proactive when I call like I am I just implement it. It's basically the we implement it and we test it and that's it. We need a mix of all sort of brains. So it's good. Yeah. Also depends on the things right. This depends on things.

Usually it's implementation and then testing and then it's it's in if I usually don't act anything. I usually always try to write decent code at the first try because it's not that difficult anyway to write decent code. So good. I just do that. Very well. Well, in Ethereum, what would you say is the most underrated part as of now? Like is it JSON RPC spec test nets or anything else? I think nothing is particularly underrated. No, I don't think anything is actually underrated. Maybe something very underrated is um something I mean if you ask me this question six months ago, I would say the L1, but now everyone changed their mind all of a sudden. So that's bad. And I'd

say that um I actually don't have an answer. I I think I think maybe test nets are underrated actually because people don't think about them but actually they saved us from having a bad factor upgrade. I mean they those test I mean and had incidents and Oleski died for us kind of so we need to appreciate in some sense right and there are now some community debate also coming up for having test nets for support of like ongoing applications which depends upon these test nets. So y definitely those have been helpful. Well, what would you say is the overrated topic? Is it tokconomics, me drama or anything else?

I think right now is kind of the tokconomics probably. I'd say it's the tokconomics. There is a lot of talk about how to on how to price things, but I think that people kind of miss the point that uh the main value of Ethereum is its use and unless you improve the UX and now you use Ethereum, Ethereum doesn't like the tokconomics don't get better. If you just charge more for transactions, you're not going to get better tokconomics. I also kind of think the same about blobs to some extent but yeah I think we need to improve the usability of the chain tokconom tweaking tokconomics is looking at the problem with the in the wrong direction from the

wrong side of things right yes I'm also in agreement like from Ethereum's point of view we should focus more on the L1 improvement at this point of time and then we can look into other aspects which are related well my final question for today is like I understand you have been a client developer, you have started with directly coding and things like that. But since you have documented a proposal, my last question for you here today is what is the hardest part of writing an EIP? Was it just naming it? Was it documenting getting consensus or the other aspects like writing motivation, abstract and rationale of the proposal? No, it's literally just

document, you know, it's actually just shielding to other people. it's pushing for it. There is always someone that disagrees with you. So, but even if you I mean the API you actually wrote I don't think actually I think they need some tweakings because actually I don't think they are that great in terms of how they're written. But in general that doesn't really matter because people still want them. But I think the biggest problem is that some people kind of complain about them as always. there is always people that are always grumpy and they don't want to implement anything or implement or they won't implement only the things they think are important. So pushing them in ECD is actually the hardest part of of the process I think.

I think even if you get the other things wrong as long as you can shield it and it's useful for people that's what matters really. Yeah. Well I think it is also the timing of the proposal because we've seen 3074 for quite some time. They had done everything tried to convince people but yes u all of these things together helps a proposal get selected for the network upgrade. You you should ask this question to to the UF team. Of course question to the UF team. I think they will answer similarly to me. I'm sorry about this part that I have seen some of the EVM proposals not getting included.

I remember one of the proposals which was like out of the upgrade just a few days before it went on the mainet. So it's sad to see so many efforts getting I I don't I actually was not present when that when that happened. I I heard of it but I actually wasn't born I think into Ethereum before. Yeah it was proposal 23152315 that was like is it Greg Calvin proposal? That's correct. Okay. Okay. Yeah that's correct. So I must congratulate you for having these two proposals selected for the upgrade and we look forward to have these proposal deployed on the mainet after successfully deployed on multiple versions of deaf

nets and the public test nets that we have got over here right. Yeah I hope they get included. Well thank you so much Julio for taking out time and sharing about EIP7825 and 7934. We are so looking forward to see these proposals on mainnet. Okay, good. That's that that's I'm happy to hear that. Well, I would also like to extend my thanks to my colleague Akash and Vain who helps us support these proposals get to the public. These episodes come out in the form of recording so people can learn and share it with people who are interested in learning more about Ethereum. For our listeners, we will include the links to

this proposal, their discussion threads, as well as the presentation link in our show notes. So, please check them out. Until next time, keep following Ethereum, keep reviewing proposals, keep building, and stay curious. Thank you all for joining us here