All Core Devs - Execution #242

Transcript

Ansgar Dietrichs: Hello, everyone, can you hear me?

Pooja Ranjan: Very well.

Ansgar Dietrichs: Perfect. Sorry for the uninformed question, how are we doing live streaming today?

Pooja Ranjan: Yes, we are live streaming. Akash is here to help us.

Ansgar Dietrichs: Sounds good. Would we be ready to go live? I want to wait a minute, but just already to check.

Pooja Ranjan: Yes, we are ready to go live, whenever you are ready.

Ansgar Dietrichs: Okay, then let's wait a second for a few more people, and then we can go live in a second. Okay, then, let's go live.

Akash | ECH: Yeah, VRI.

Ansgar Dietrichs: Perfect. Hello everyone, welcome to All Core Devs Call 242. On a special day, today is the 11th birthday of Ethereum. So, happy birthday, I don't know, squarely in the second decade, and yeah, looking forward to year 12. And with that, let's go into the agenda. The first part of the call will be about Glamsterdam, and then about Hegota the second half. So, on Glamsterdam, first, just briefly, DevNet 7 has been running for a while. Last I heard is that everything was stable, but wanted to briefly check on this. Barnabas, could you give a quick summary?

Barnabas Busa: Yeah, the development has been running quite stable. There was a few books that we found along the way. One of the major ones is, right now, Teku. Teku still seems to be mainly self-building blocks and not using any public bids. And also, when you use Teku as a builder, then, The bids are not coming in. So it would be nice if Teku, Teku guys could take a look. Mmm… there was a few other bugs from Besu, where they pushed a comment that broke the stateless calculation. And, and I think Geth had a builder-path, bug as well. But that was fixed as well, and I think the Besu Bug has been fixed as well, too.

Ansgar Dietrichs: Okay, sounds good. Any… Other comments? Any… anything either regarding those bugs, or any other topic regarding FNT7?

Barnabas Busa: No, not right now. We have 100% participation. We have a few payloads missing here and there. Those will be investigated further. And you're still actively trying to break the network.

Ansgar Dietrichs: Sounds good. Mmm… Yeah, then I think we can immediately move on to discussion of Glamsterdam DevNet 8. And there is a proposal to potentially turn that into a short-lived testnet, but first I wanted to briefly talk about the scope and the status of the network there, the preparations. There's a scope doc. By Panda Ops… Yep, linked in the chat. The two topics to touch on would be, one, status of repricings, and then two, dis5, let's start with repricings. Maria, on the call, could give a quick summary of where we are at there?

Maria Silva: So, on repricings, We are currently… so there's two things that are happening, let's say. So the first one was, we are doing the repricing analysis on Glamsterdam and DevNet 7. And, that includes, both the changes to the Epps, but also includes, two new things on the benchmarking side. So, first is we expanded some of the pricing scenarios for ETH transfers and, access to accounts. And the second one was we started to use a new Tool to generate the state that the benchmarks run on. And, while we were testing this new way of generating the state, we realized that the snapshot we were using before, which was the Johamnet snapshot, had the potential to be a bit, optimistic, in regards to some, DB designs, and the state actor results would be much more accurate.

And so this is, one… one process, so we… we do have early results, from these, but, clients are still merging some of their optimizations still in, DevNet 7, and, we are also trying to understand, like. the numbers we are seeing right now, that got a bit worse. Is it due to the optimization not being merged yet, or is it really, the… the expansion of the tests that, created those? So… This means that we cannot, very confidently say that the numbers are final yet until we figure these things. And the second, step is, So the repricing analysis is, is like, A subset of all the benchmarks we have. And we are… Starting to also run the full benchmark suite.

for, Glamsterdam DevNet 7, and we do expect to have results on that, next week. So, these are the two things that need to be finished before we can more confidently say that the numbers are final, so we need to figure out all the things with the new results on the repricings, and also, gather the results on the full benchmarking suite, which we expect next week.

Ansgar Dietrichs: Sounds good. And, are you actively… like, basically, are we tracking towards that being ready in time for, devnet 8 launch?

Maria Silva: I… I'm not sure, it really depends on the results we see next week, so it's… it's hard to say.

Ansgar Dietrichs: Okay, sounds good, so something to, keep monitoring. Anything else on repricings from anyone?

Barnabas Busa: Should we wait to demonstrate till this is done?

Ansgar Dietrichs: It seems like that might be desirable if we really want DevNet 8 to be the last DevNet. Obviously, depends a little bit on the timing. If it takes a long time to wait, and chances that we would need to change anything based on the results are very small, maybe it's worth taking the risk, but seems like we should at least try to wait.

Barnabas Busa: Commenteers do we need?

Maria Silva: I'd say maybe if we can wait until next week, and then we reassess, like, if we are sure that the results are unlikely to change, then we can more confidently go with DevNet 8, and if not, we can discuss again, and see if it makes sense to do another DevNet after 8.

Barnabas Busa: So, we want to propose that the notate would be the lost and a public testnet, basically. So… That would… it would make sense to… To use the final numbers. Especially because it's gonna be, Like, public-facing, so if we change, yet again, some repricing numbers, then… It can be quite confusing.

Maria Silva: Right, then I guess we need to wait, wait, like, I… I mean, at this point, I cannot confidently say that the numbers won't change, so… Yeah.

Barnabas Busa: Right, then let's just try to get this, let's just try to get the numbers ASAP, and then, once we have the numbers, then we launch, the network.

Maria Silva: Right, as I explained on that, the two things is we need to have all EL clients now do a final push on assessing the optimizations and making sure that the numbers are as we need them to be, and if there's any optimizations that were missed, and then start seeing the numbers on the full benchmark suite, which, we expect to do next…

Parithosh Jayanthi: Could we maybe then get an update from EL Devs as to if they're still waiting on pushing some optimizations, or is everyone done?

Barnabas Busa: Maybe we should call each EL team out.

Ameziane Hamlat: I can start, on the Aesha's side. So, there is, one thing that, I erased last time, which is… The configuration that, that state actor generates for the database, doesn't seem to be the same as the one that we use on mainnet, on Besu site. So… I shared the mainnet configuration. I think Johann and Carlos are looking into it. So this is one point. So we need to get that, Like, that configuration up to date, to run the test again, and see If we need to… to optimize more, but from our side, we pushed everything on, on Glam DevNet 7, and, yeah, and we had a few regressions because, actually, of the last merge we did, but we fixed,

or the regressions.

Ansgar Dietrichs: Any other plans? So we can quickly go through. Geth, are there any in-flight optimizations still? Anyone from Geth? On the call that could answer that. Yeah, maybe no one from that context, so I would assume no. Anyone from Nethermind?

Alexey Osipov: Might be just good to have an option to compare with different clients. If someone will reach better performance by some unique optimization, we will try to apply similar stuff. So, some initial numbers would help to determine if we… Yeah, can improve further. But no, nothing is planned. In this direction.

Ansgar Dietrichs: Okay, makes sense. Mmm… ethrex says they have all optimizations, Then, from Erigon, anything in flight still?

Andrew Ashikhmin: So, recently. Oh yeah, please go on.

Milen Filatov: Yeah, going on here?

Andrew Ashikhmin: Okay, I just wanted to say that recently we've been focusing more on the correctness. And hopefully, we'll be soon done with that, and we can switch back to optimizations.

Ansgar Dietrichs: Sounds good. And from Reth, anything?

Andrew Ashikhmin: Sorry, but maybe, mileni, do you want to add something?

Milen Filatov: No, yeah, I mean, I just wanted to mention that I think the branch that currently… the consens branch did work currently. has been currently running these, benchmarks is quite old. I'm in the process of refreshing it. And I did notice that there are some unexpected… performance regressions, which we fixed previously, so I need to see why. But I hope that it should be… easy, because, it's things that we've already stumbled upon. But yeah, I think because we… we jumped from… I think there's, like, two things happening at the same time. First, we jumped from… about DevNet 7 spec, which is months ago, to grumps from DevNet 7 spec changes, There might be some regressions, but also, we just got given a new benchmarking tool to run these benchmarks, so…

That will take a bit of time to review. So there's, like, two big things that need a bit of time to go through. Is what I wanted to say.

Ansgar Dietrichs: Yep, sounds good that that's good context. Then, just quickly checking in on Reth, I think that was the only client we didn't hear from yet? Anything… But…

Dragan Rakita: Nothing, parroting is a merge domain. So, yeah, we don't have anything pending.

Ansgar Dietrichs: Okay. Did I miss any kind? I think that was all. Yeah, I mean, it sounds like, in general, one, then, for clients, quick prompt to maybe prioritize this over the next few days, just because it seems like it might be the bottleneck for launching the DevNet. And that would be good to do ASAP, so if you have some time, please look into this. And then the other thing, Maria, quick check, it sounds like maybe we are just getting to a place where we're confident enough that even if there are some regressions or some last-minute worse performances than we expected to see, that it sounds like We could just… At that point, then just trust that clients will, like, whatever the affected client is will just have the ability to look into it and fix that afterwards, so that we could maybe just leave the numbers as is.

Even if we find regressions?

Maria Silva: To be honest, I'm not sure. I remember, for instance, Forget, they saying that they don't really have any more optimizations that they can think of to do. And, after the results with the new state actor tool and the new test cases, it could be that actually the numbers like, require some changes. So I don't think we can really… say that, yeah. Yeah, I'm sorry, I would like… It's to be different, and, to be able to… to… give you, better numbers. I think if we want to I don't know, I think another option is, like, we just say that the numbers are what they are, if you really want to speed this up, and then what will happen is that we'll maybe get a lower gas limit.

but I don't know.

Ansgar Dietrichs: Makes sense.

Maria Silva: That's also, like, something we want to do instead of just waiting a couple more weeks.

Ansgar Dietrichs: Yeah, I mean, I think we can make that assessment, next week, but I would say, maybe for clients, then the prompt at least, if ideally early next week, I mean, ideally on ACD, but even… but at least some point next week, if you could have at least a feeling of. Are there any unexpected big regressions, big blockers? So basically that we, if we at least have, like, a 90% confidence level by next week of, like, okay, this looks good, these numbers will likely hold. I think that's probably good enough for us, so if… if you all could spend the time to basically, like, get to… Get to a reasonable confidence level there, that would be good. And…

yeah, maybe ideally just be in the loop with Maria to see if there's anything specific to pay attention to. Maria just posted something in chat as well. Okay. Sounds good. Then, yeah, let's just make sure that repricing's, doesn't look good. Kind of… getting to the final DevNet too much, And that's it. Anything else on realpricings? Okay, then the other item for DevNet 8 would be Discovery V5. There were some elements to that, one just in general, kind of, like, status regarding Discovery V5 support, but then I think there were also some considerations around potentially doing the DevNet discv5 5 only, and or otherwise, just thinking about how you would want to move mainnet to…

discv5 only, like, at what… on what timeline and everything, and… and how to… how to then do that with the DevNets and testnets ramping up to… to mainnet. I think, Barnabas and Caba are the two people with… That have been looking into this. Can either of you give an update of the open questions there?

Csaba Kiraly: Yeah, so the… The agreement was that, everyone turns on Display 5 in the releases. Keeping a screen foil on, and then at one point, we, turn off the screen foil, and that's what we want to test now. I was testing with other clients in a Kurtosis testnet, and it seemed that LAS has issues, but it… seems, turned out, good to have confirmation, that they have, also syncs working on the main bench. It was just the .NET7 branch, which, which had Zync not merged cherry-picked for this, and it wasn't 11.7Gore, so it's fine. So, how it seems is that we have… Lady to have, this V5 only, testing, two clients were missing the… the flag to turn off the screen foil, but that should be easy. And, some clients, it seems, need to replace Blanche oil, but I guess everyone will reconstruct the blanches.

To some extent, or jelly pick, or the base, whichever is the choice. So it seems good, good to go. for Demet 8.

Ansgar Dietrichs: Sounds good. Maybe just to quickly confirm the REST status, dragan, I think you said that that's being finalized on the REST side?

Dragan Rakita: Yeah, I think some changes already merged, but some are currently in PR form. So for disk 5, yeah, we should… Soon, we should have everything soon.

Ansgar Dietrichs: Sounds good. And, I mean, also, just to check, Caba, I assume… it's not a critical blocker for the DevNet, like, to have all the clients fully ready, right? Because we could always, like. have an updated client release form before we test the switching to V5 only? Is that right?

Csaba Kiraly: So, yeah, I think I didn't fully get the question. What's not critical and what is. The important part is that, yeah, it would be bad if we set up the network, and then some clients just don't connect at all, so… so that's what we want to avoid here, and then from there, I think it will be working, and in the background, there are hive tests, which every client should look into passing all of them. suited the implementation. The thing is, the implementations are… mostly shared with the CRs, and the CLs are running on this since quite a long time, so I'm not expecting, huge problems. It's not that we have to test new implementations of the protocol. So…

I guess everything will be fine if things are bootstrapping correctly. That was one issue in the boost step, but that was specific to Kurtosis, in which, there were different ways of passing the… the bootstep node addresses, and not all the tools were ready to pass it as an ENL. They were still passing it as an e node. This before I like, and then that wasn't digested by, and it's not mandated to be digested, by some of the clients. Some clients handled it, some not. Maybe I'll make sure it's buzzed as any other…

Barnabas Busa: I have a fix for that.

Csaba Kiraly: Yeah, I think… also, I think we both have a fix for that.

Barnabas Busa: It would also be good if, EL teams now returned the ENR fields, maybe in addition of the eNode fields in the admin node info RPC endpoint. Or just the, you know, if disk V5 is the only thing enabled.

Csaba Kiraly: Yeah, do you have a… do you know which clients are determining it which not? I wasn't looking into that.

Barnabas Busa: So, currently, only the E node field is, returned by every single client.

Csaba Kiraly: Okay.

Barnabas Busa: Not DNRs.

Csaba Kiraly: Yeah, that's a good point.

Ansgar Dietrichs: Okay. And then… is that… is that everything regarding DevNet 8? For… for Describe? Sweep? Then if so, just a quick question, just to flag that, at some point, we should also then discuss, how we will kind of, like, sunset Disk V4 support on Mainnet. I assume we don't have to discuss this today, right? But, at some point between now and… Main Network, we should… we should have a strategy there in place. Okay, then those are the… were the two main topics, regarding the readiness for… DevNet 8, and then the last question there regarding DevNet 8 is, there is this… proposal by PandaOps to basically turn it into a more public-facing, testnet, short-lived testnet, with a name that I… I'll have a hard time… Plata Berget.

Testnet, Maybe, Barnabas, do you want to briefly summarize what the idea behind that is, what the difference would be in practice, and any decisions we need to make regarding this today?

Barnabas Busa: Yeah, so the main… the main reason we want to launch this is to be able to get, everybody onboarded, and we noticed that if you just call it a devnet-number, most people will still, Not really pay attention to it, or they just, dismiss it, so that's why we decided that maybe we could have a named testnet that would run, approximately till the… is hit… hitting Amsterdam, so I would expect it to be a couple of months, and then after that, if everything was smoothly there, then we would just, sunset it.

Ansgar Dietrichs: Sounds good. And then a question in chat would be whether there would be a separate DevNet Wiki brand, I guess DevNet 7 in this case, that we would wanna… or the NFT DevNets.

Barnabas Busa: Yeah, we still plan to do, like, large-scale DevNets in the meantime, but we just want to make sure that the public-facing testnets are available as early on as possible with the latest pack. So this would be… Yeah, this would assume that we are no longer doing any further repricing. So it would be a prerequisite to finish all the pricing for… before we launch this, doesn't.

Ansgar Dietrichs: Sounds good. So then, for now, maybe… I mean, is there… is there a decision to be made here? I think it seems like a good idea, kind of, like, pretty uncontroversial. Any… anyone that has concerns around going… going this route? Okay, so then, basically, like, for anyone listening, we can already kind of say, if you are… app developer, anyone else, an infra provider, anyone who wants to start testing, this testnet will be kind of your place to do that. Exact timing of launch, TBD, Barnabas, yeah?

Barnabas Busa: Yeah, so the exact launch is DBD, hopefully we can make a decision on that on next week's ACDT. And then, after the launch, we are expecting to wait approximately a week, maybe 10 days, to do the fork, and this should give enough time for all the builders to get their, to get ready for the fork as well, and try to be online on the… At the fork.

Ansgar Dietrichs: Sounds good. So, if you are a builder or anyone else affected by the fork itself, you should pay attention from the start, and otherwise, if you want to just test the steady state after, you have a little bit more time to wait. Sounds good, and I'm sure we'll give more information, more advisory for people, kind of, like, in other forms, as well, in the coming days. Once… once we lock in a decision around timeline… timing? Okay. Sounds good. I think that's all then for… DevNet 8, well, for the testnet. And then everything also for Glamsterdam. Do we have any other Glamsterdam-related topics?

Stefan Starflinger: One thing we could mention is I posted in the chat. that we can get the Hive chain to date. I think Chase is looking into that. I just wanted to kind of give a shout out to that, so that we can get RPC compatibility across the board. For, Glamsterdam endpoints. I think there's still some work to be done to get, the hype chain up to date with Glamsterdam, but once that's done, we will have some, tests running to see that all clients, are passing those. compatibility tests. Enrico Sioux.

Ansgar Dietrichs: Sounds good. Your audio was a bit bad, but I think everyone could understand this, hopefully. Yeah, I'm sorry, this was my mistake. I miscategorized it at the very end of the call, but you're right, this should be a glams at our item. Chase, you're also on the call, anything to add from your side?

Chase Wright: Yeah, I just wanted to say, like, right now, Hive Chains, to date, has mostly been handled by Felix, and so I was looking into how we could update Hive Chain for Glamsterdam, and I'm using the Latest Clamsterdam 7, images, and I'm trying to do that, but there's some, like, complex… EIP interactions around the ball list, so… If someone could take a look at that, that would be great. I'm… trying to, like, vibe engineer my way through it, hitting some blockers, and I just… I just like some extra eyes to help me get past that.

Ansgar Dietrichs: Sounds good. Anyone in particular that you… or any… any… yeah. Or just anyone who feels… Like, they have context.

Chase Wright: I mean, I'll take any help I can get.

Ansgar Dietrichs: Sounds good. Okay. Awesome. So, please have a look. Then that's probably all for Amsterdam. Yep, if there's nothing more, then we can move on to the headquarter section. Before, we have… we have a bunch of PFI EIPs, and on that point, I wanted to briefly just talk about the proposal deadline specifics again. So, the proposal deadline, as we communicated in the past, is next week, no, next week is obviously ACDC, so on the ACDC side, any EIP proposed before the ACDC call is in time. On the ACDE side, what I was thinking is basically have the same deadline, so basically, like, the beginning of the ACDC call is the cutoff time, and if you want to propose an EIP by then, you can either do it by leaving a comment on the agenda for next ACDE, so basically, like, the agenda that will be up.

then, up on GitHub, Today, you can leave a comment, if that's there by… by next week, it's in time, or you can open a PR against the Meta EIP. Either way, basically, if it's clear that you… you were on time, by, next Thursday, by ACDC time. then your ELP is also still on time. Any questions there, or otherwise we can go into the PFI DIPs for this call? Okay, then… first up, we had, 3 EIPs from Etan.

Etan Kissling: Yes. The first one is 8115. Today, at the end of every transaction, we credit the fee recipient of the block with the priority fee. And the proposal is to, collect all these priority fees and credit them at the end of the block, instead of after every individual transaction. That has two benefits. One of them is that, like, parallel transaction execution is a tiny bit better, because not every transaction has to write to the fee-based VPN. And also, it is better for the UX, because if you are a blog producer, and you are, like, a fee recipient, someone and you open that up in MetaMask, you have, like, 300 entries with, like, microtransactions giving you tiny priority fees in there, if you chose these, even. But, like, it… consolidating them into a single entry.

would make that a little bit cleaner. The downside is that the priority fee would be only spendable in the next block. Because it would be credited at the end of the block, so that's the difference there. That's the 8115. And then the next one, 8116, that one is also a UX thing. Today, if you query a receipt of a transaction. It has this field, it's called, cumulative gas used. It's like all the gas summed up, up to and including the current transaction. So, if you query the fifth transaction in the block, you get the cumulative gas used of the first five transactions. So, if you only care about the actual gas used. That means that you have to download two of these receipts.

And then do the difference there, which is inefficient and makes, like… trust-minimized approach is a bit trickier, so the proposal there is to replace that cumulative gas used field with just, like, whatever gas that individual transaction used. Like, it's still the same information, but, like, stored in a slightly… easier to access. way. And then… The last one is 7807. That one was originally proposed as a headliner, which got rejected. But now it's, like, scoped down, to a non-headliner, and this is about changing the way how the block hash is computed. To be based on SSZ. So it's just a block hash now, it's not transactions, not receipts.

Anymore, so that it stays simple. It also has a way smaller dependency list now than it used to have. The main benefit here is that, again, for the users who are accessing it, they can prove individual fields of the block without downloading the full header. And also for the CL, it allows the CL to compute the block hash locally, because today, the CL has to send every single block to the EL to compute the block hash and verify that it's correct, even during sync, right? So this should improve the sync process for the CL. I think there's also some interactions with Yatex TopUpSync, Well, yeah, the idea here is just change the block hash. To the same way how we hash it on the CL and align those two.

Then, let me check the comments real quick. There is some similar EIP problem as if you want to use priority fee. Yes, so… Yeah, the priority fee would be credited at the end of the block, and the downside is you can only spend it in the next block. It's mostly a thing for the builders to figure out, I guess. individual TX guys used. Yes, it's in the API, but it's not in the on-chain data, so if you want to have a trust-minimized way, where you, only wanna, like, you prove, the Merkle Patricia Trie proof, you do a Merkle proof that this individual receipt that you get is actually part of the block route. You will have to download both of them to have a trust-minimized way to verify that the data is correct that you receive from the server.

Yes, it's in the response, but it's not committed on-chain. Like, the server can just put whatever data is in there, and you have no way to verify. Unless you download both. And then this should take into account… We now have state gas and Execution gas. 78 Austin. Yes, I mean… I mean, yeah, like, we can… huh? But it's… What… I'm not sure what EIP it is about.

Jochem Brouwer: Yeah, sorry, okay, let me quickly explain. So, you were saying we should change this cumulative cash in the receipts for EIP8116. EIP8037. We now have two levels of state gas, what we are accounting for, so we have… so we have two different, dimensions of gas, what we are accounting for, the state gas and the Execution gas, and this is… this… well, I… like, I… I like this idea, but we should specify, like, what exactly is being, like, is it the gas, what is being spent in total? Like, what the user or the Transaction Center is paying for, or is it only the execution gas, or is it only the state gas? But this should be specified. That's my… that's my comment, but it's slightly detailed.

Etan Kissling: Yeah, I mean, the EIP can obviously be updated. The idea is to, like, whatever you receive over the JSON RPC should also be on-chain, so that it's verifiable. Otherwise, you cannot prove the data with the Merkle proof. So if there are two… Gas-used values, then of course you would put both of them, just change it to be just about the individual transaction instead of cumulative. And… Yeah, I mean… If there is more stuff that has to go in there, of course, we can also put that as part of the same effort. Like, the idea is just, what's in the JSON RPC, put that on-chain.

Jochem Brouwer: Yep, sounds good. Thanks.

Etan Kissling: And also for the 7807, for the block hash, I removed the logs bloom field from the block header as part of that. And over JSON RPC will just receive all ones, so you don't break the legacy client, but it would not be hashed into the block hash anymore, so that we can phase out the logs bloom. That's it from my side.

Ansgar Dietrichs: Perfect. Thank you, Etan. Any… anyone else with questions that I didn't already put in chat? Okay. Then, up next, Derek, you wanted to propose EIP7819? I'm not sure if you're on the call.

Derek Chiang: Yes, yes, I'm on the call. Yeah, so I'm mostly here because, I wasn't sure if the original author of the EIP, Hadrien from OpenZeppelin was gonna be here. But I see that he's on the call right now, so, HJ, do you want to… do you want to do the proposal, or do you want me to just, I guess, say out what I prepared?

Hadrien Croubois: You can go ahead, that shows that people besides me have an interest in this proposal.

Derek Chiang: Sure, sure, sure. Yeah, so to me, like, the EIP7819 is mostly important from the standpoint of. you know, we are trying to get account abstraction, really wisely adopted on Ethereum, right? You know, so especially if we manage to ship native account abstraction in Hegota, you know, this is, like, all the more important. But even without native Aid, you know, even in the context of just like 4 through 7, it's really important to optimize for A, right? So the, specifically, you know, like, with, Glamster, that, you know, we all know that state creation's gonna get more expensive, right? You know, so I think it's gonna get something like, like, 5x more expensive to create a new state. So this is, like, a really big, I guess.

setback for AA, just because, right, like, because, like, every time you create, like, new smart accounts, you're creating new state, right? So, these days, smart accounts are typically deployed with minimal proxies, with minimal proxies, And those proxies, they are pretty minimal, but there's always, like, a limit to how minimal they can be, right? So, this new EIP, EIP7819, is essentially, like, this very elegant idea that we can, essentially make proxies a native concept on Ethereum by reusing the delegate concept introduced in, EIP 7702. So, if you guys recall, with 7702, you know, you can, send a new transaction type, you know, that, essentially, sets the codes of an account to. This, like, delegate prefix. plus the address of the implementation that it points to, right? So then, like, the entire code

you know, of the accounts only takes 23 bytes, so 3 bytes for the prefix, and 20 bytes for the address of the implementation. So this is, like, kind of like the minimal possible, I guess, proxy, right? You know, but the reason why Samsung 2 is not, like, enough by itself is because you can only create that delegate pointer through a new transaction type, right? You know, which means that, like, this mechanism is not composable on-chat, right? So, for example, if you want to have, like, a proxy factory that uses this pattern, that's not really possible. So, 7819 is just, like, a very simple EIP that introduces a new opcode called ZetDelegate that essentially allows a contract to create

you know, accounts with such delegate pointers. So the end result is that you can now create, like, much, much cheaper, proxy accounts, you know, which will make it much cheaper to, use Account Instruction. Yeah. Any… thing… Hadrian, you want to add?

Hadrien Croubois: You know, I think it summarized it pretty well, yeah. Thank you, thank you for pushing this today.

Derek Chiang: No problem.

Ansgar Dietrichs: There's a question in chat. What's the difference between this and delegate call?

Hadrien Croubois: So, if I can answer here, like, right now, most of the proxy and clones that Dietrich mentioned use a delegate call mechanism. But in order to use the delegate code mechanism, you have to… Deploy some piece of code, either the code nor the proxy. And that means you have to copy all the code data to memory, and then you have to delegate, and this has a significant cost. Also, you have to SLOAD, possibly, the address of the destination that you want to target. So, the idea is that EIP7702 implements this natively in the protocol. And so, what this proposal does is propose a mechanism to use this native construction instead of doing it in the user space through a delegate code. But it behaves… you can have the same behavior today through a delegate code, it's just significantly more expensive because

There are possibly SLOAD involved, and there is a way bigger bytecode that has to be deployed, and that is replicated Possibly millions of times on the chain.

Ansgar Dietrichs: Sounds good. Any other questions? I saw Derek already answered one in chat as well. Anything else? Okay, then thank you, Derek and Hadrien. Next up, we have… An EIP proposed by Alex? 7906, are you on the call?

Alex Forshtat: Yeah, hi. Can I share my screen? Can you hear me well?

Ansgar Dietrichs: We can hear you, and I think you should be able to share your screen. Yes, we can see your screen.

Alex Forshtat: Okay, great. So I'm proposing EIP 7906 for inclusion. These are transaction assertions, and this, EIP will allow us to do, like, enforce transaction outcomes natively, and verify state changes, on-chain. So, the definition of the problem that the EIP is trying to solve is that transaction outcomes are currently unpredictable specifically for the users, because users don't exactly control outcomes of their transactions. they do control the inputs, but the inputs only form a part of what determines the outcome of the transaction. They will call the bytecode, and the bytecode will read some state, and all of this together will produce the outcome that users actually care about. And I think with EIP8141 included, we got a very simple solution for that, and we can just expose the state change that happened directly.

So, this, like, gap in transaction visibility of the outcomes is real, and it's causing, like, a lot of, losses through hacks and user mistakes. and there are entire groups of attacks that are happening frequently on Ethereum and causing, like, huge losses. The major families of attacks that we're trying to address are, like, account control takeover, where, like, people just end up transferring their entire smart account to a malicious party. all the drainers and fake DEXs, or, like, swaps, like, fake airdrops and things like that. People also, like, use funds to, like, aggressive MEV sometimes, because the transactions they approved, allow, like, very lenient slippages or, like, price impact. And also front-running, where, like, the expected contract behavior can change before the user's transaction settles. And this can, like, even target the wallets that exist today, and they try to simulate what the outcome of the transaction will be.

And there are, like, major incidents, like, the most famous, probably, is Bybit, which is, like, $1.5 billion, where, like, the safe was transferred, due to, like, people not being able to understand what will happen with the transaction. But there are many more, and they're often, like, chains… supply chain attacks, where, like, the legitimate sites or, like, underlying infrastructure is compromised. And, like, the mitigations that exist today are… like, there are two major groups, I would say. Like, one is this, mentioned, like, outcome simulation. Whereas a wallet does some, like, API request to its own backend, or, like, some third-party backend, and tries to, like, simulate a transaction and estimate what will happen when this transaction lands on-chain.

But, like, this simulation clearly runs against, the current state. Probably. It cannot… it's impossible to simulate every possible state that can exist. And if the transaction in the simulation is unreliable on itself, it can be its own threat vector, because, like, users trust the simulations, but this is not what is necessarily happening. And there are, like, problems with it, because, like, this is some backend service that has to provide this, so it may not support some chains, some Devs, or, like, refuse service to users. So it's not standardized, it's, like, proprietary ad hoc solution, and it kind of needs you to just give this transaction to this, like, third party for the simulation, and you get the best effort simulation.

The second approach is, like, on-chain, like, guard modules for smart accounts that try to run this, like, check after execution type of, assertion on-chain, and multiple, like, smart account modules do that. And the problems here is that without, like, native EVM support. Like, these modules are limited in what they can do. Because they cannot, express, what we call negative conditions, which means, like, nothing happened except for the thing that, like, we want to happen. You cannot express this on the current EVM. You cannot observe state changes, if they are not shown by the contract as a public view function. So, for example, proxies are not visible. Like, proxy implementation addresses are usually not visible. And, like, even if it was visible, you would… you cannot trust it, because if the proxy was taken over, then it will lie to you in its, like, Get implementation function.

And, like, even if you say that I just want to check that my assets are not moved, some asset types, like NFT tokens, it would be not feasible to iterate over all possible assets that you have. So the guard modules are, like, good, but it is not the full, safety for users. So, I believe the real mitigation here is to give users, like, full control over the possible outcomes of their transactions. Because if, you look into it, the, like, financially important outcomes of EVM transactions are usually quite simple. These are, like, native balance changes, like, most of the time it's ERC20 balance changes, and, like, almost every other situation is, like, one or a couple of storage slots written in specific contracts.

So we can give users the outcome control with two steps. The first part is to expose these storage diffs and balance changes into the EVM. And the second is to create the tooling for the wallets and, like, off-chain, like, programs that can interpret what these storage changes even mean. So, the EIP7906 that I'm proposing for inclusion, it is the way to expose these balances to our changes. So, it consists of three opcodes. TX trace, txDiff, and to work with events, it has event data copy. And together, they expose absolutely every state change that can happen on Ethereum in the EVM. And we use, like, EIP8141. To get access to this opcodes. to a specific frame. We introduce a new frame mode, which is, like, called post-Traction, and this frame has to run after the transaction finalizes. It cannot be included anywhere in between, and these opcodes don't work outside of this frame. So, like, there… it does not allow in Transaction introspection, you cannot, like.

Suddenly make decisions based on other storage rights. And the only thing that it can do, it can decide to revert the entire execution body of the transaction. So every state change, that happened in the transaction reverse means that Smart Account, like, has to decide, like, and accept the finalization Of the observed state change. So this is what the, like, sequence diagram for this would look like. The first four steps are equivalent to how French Transaction would look like right now. There are some changes at validations, and the last frame can make a call to the enforcer of transaction assertions, and this is an all-seeing frame that can observe directly into the state changes that happened throughout the transaction.

It makes this decision to revert or not. So looking into the opcode. There are three, because they provide a different splice of information, so TX trace, exposes the state change as an iterator. And it very much follows the shape of a T experiment. And crucially, if something is not present in a TXTrace result, it means that this change did not happen in the current transaction. This is what allows us to express negative conditions, like, nothing changes, or, like, nothing else changes. TXD gives you direct access to specific variables and storage slots of every contract on-chain. And it can look into things that did not change and act as an alias for a SLOT, basically. And it is necessary because if you only had an iterator, it would be kind of complex to reach the specific slots.

And event data copy exposes, like, the data from events, for, protocols that may, like, be event… and they're even, like, like, meta-transaction relays, bundlers, and, like, cross-chain bridges, things like that. So the perfect user experience that we can achieve from accepting EIP 7906 and the surrounding tooling is to make the transaction simulations feel like… and actually be enforced. So, the user confirmation includes all the financially important state changes that can happen in the transaction. And users can control them per transaction, and users also can install, like, persistent post-transaction policies in their smart account wallets. And basically, any violation of this policy is a guaranteed on-chain revert. So, the tooling that is required to do that, most of it already exists today, it is just not joined into a single protocol.

So, there is a clear sign-in work group, and it is a group that's working on creating a registry of all verifying known contracts and their, like, metadata descriptions, specifically for clear signing in ERC 7730. And, like, Sourceify is, of course, working on verifying all contract source codes, and Solidity already has a storage layout flag that allows you to export the storage layout definitions. And, Get has all the tracing support to collect the storage changes that happen in Transaction. And now, like, there are multiple, like, kind of debuggers, like, for example, Tenderly can perfectly show you what variable changed based on the transaction trace. So, like, by connecting all these tools, we can get this, like, outcome clear signing protocol.

So, like, to talk briefly about the impact, it kind of makes sense that the most… the first adoption and the perfect customer for this are, like, sophisticated institutional vaults and, like, projects dealing with blockchain security. Because, like, we are closing here the time of check, time of use gap for existing simulations and all the policies based on the simulation. We kind of collapsed the pre-execution simulation and on-chain enforcement as a single stack. And yeah, of course, they can, implement policies like ban any unexpected change unless they have signed off on the allowed change. So this can help them defend against attackers who know exactly what the stack they're using right now. And, like, existing solutions, like the safeguards, they get, like, superpowers from adopting, like, transaction assertions natively.

There are a couple of questions that are often asked, like, one is, like, if tax rates is too much introspection, like gas and origin, and I believe that it's not the case because we have frame transactions, and because we can limit use of this opcode to the final static frame mode. And guarantees that the only, like, decision you can make based on this new knowledge is if you revert or not, do not revert this transaction. And the important thing is, with 8141 implemented, 7906 is very simple. Like, the state diff that you need to expose, like, all nodes already have to collect it. They just need to export it with this frame. And, like, if there is a… it's possible that some contracts cannot be supported by this off-chain tooling if they do very custom things with their search.

But this should be very rare, and, like, I believe on day one, the vast majority of contracts that are actually financially meaningful can be supported, and, like, we can try to cover the long tail, down the road. And, I have a couple of links to share, like, this is already implemented by ethrex. I would like to invite them to speak, if they are present on the call about the implementation. They have a public DevNet that is running this EIP. I have built a, like, quick playground demo of how it should look like to use Ethereum with EIP7906, and I've, like, wrote about the off-chain tooling and the clear sign-in aspect of it on Twitter on this link, if anyone's interested.

Thank you.

Ansgar Dietrichs: Sounds good, thank you. Could… where could people find the links from the last slide?

Alex Forshtat: Let me just paste them to…

Ansgar Dietrichs: Sounds good.

Alex Forshtat: chat. Yeah.

Ansgar Dietrichs: Paste them through the chat. Thank you. There was some discussion while you were talking, anyone wants to briefly speak up, raise any questions, or… I mean, otherwise we can also leave that in chat. Okay, but, sounds like, from chat there was quite a bit of interest, In the EIP, what's the best place for continued discussion?

Alex Forshtat: like, clear signing work group, like the Ethereum magicians, and, like, DM me. I'll try to go over the questions in the In the chat, after the call.

Ansgar Dietrichs: Sounds good. Yeah. In the interest of time, I would maybe… I mean, you did mention ethrex. If anyone from ethrex wants to briefly speak up about this topic, now would be the time, but I would ask to keep that short.

Iván | ethrex: Just a quick word, it was, we think the EIP is good for Ethereum, for security. There are lots of… Cases that could have been prevented using this feature, and… Yeah, we… we didn't announce the demo yet, because we are including lots of EIPs on top of frames, but we will plan to do it soon.

Ansgar Dietrichs: Sounds good. Okay, any other comments, questions now, live? Otherwise, we can move on to the next EIP? Okay, then, next up is Jocham with EIP7668.

Jochem Brouwer: Yeah, I can be very short, so EIP7668 is about to be moved. bloom field is, and I think I just folded them. Ansgar, so that's very funny. So, this EIP, we know the Boom filters, they were, so these are the locked Bloom filters. They are not, either not being used anymore, or, like, not very useful anymore, so we should remove them. Well, what is removing means, that is something that we can talk about. What was very, surprised about is that EIP7906, which is the SSZ block. Execution blocks is, well, this is exactly what Tony is asking right now. I was surprised that, this is part of the SCC Execution EIP also, but I still want to propose this EIP, in,

individually, because if Etan's EIP does not, if Etan's EIP does not make it, I think they support that EIP, but if it does not make it, then we can still deprecate slash remove the logs bloom. EIP 8304, which is the Justice Log and Transaction Index. This actually, it says it will not remove the Bloom filters itself, but I think this specific EIP, which removes the Bloom filters, works perfectly together with that EIP. So this is why I'm proposing it. It's a very simple change. The Bloomfields are not being used anymore, but clients still… all the clients are still re-executing this, and therefore calculating it. That's a waste of energy, and clients can use that elsewhere. So, let's remove funds.

Thank you.

Ansgar Dietrichs: Sounds good. Yeah, and in case, of course. both EIPs moved forward, we could figure out whether to use one combined EIP, or just remove it from the scope of the other EIP.

Jochem Brouwer: Yes.

Ansgar Dietrichs: Excellent. Yeah, sounds good. Okay, any questions, comments, otherwise? If not, then we can move on to Kev, who wanted to propose EIP 8200. Kev, are you on the call?

Kevaundray Wedderburn: Yep, sorry, also front-run Ansgar. So I want to propose EIP8200. I will first paste another link in. Where, essentially, we analyzed 99% of the blocks to see the precompile usage, and figured out that around 50% of the precompiles are barely being used, with, like, some of them, like Blake2F, being essentially used by one contract. And yeah, so the issue of this… Sorry, yeah, the issue of this is that for ZKVMs, each precompile implies an accelerator or a circuit, which essentially just means the ZKVM needs to have special logic or dedicated circuits to make sure that these precompiles are fast. So it increases the attack surface, or the surface that we need to audit for ZKVMs.

A lesser motivation, which, pre-ZKVMs is that once you EVMify a precompile, you can essentially remove the native library that you have. And the way to do it is, essentially, we set the code of the precompile… at the precompile address for some equivalent EVM bytecode. It's not super difficult, so that's about it.

Ansgar Dietrichs: Okay. There's a question in chat from Toni?

Kevaundray Wedderburn: What is the difference to just repricing the precompiles when we roll out ZK EVMs? So if you reprice… so the difference here is that you'll be pricing it based on the opcode. Basically how much it costs to… run this library, so, like, the Blake2F equivalent library. Whereas with ZKVMs, you'd be repricing it, based on prover costs, if we introduce prover costs. Yeah, I was.

Toni Wahrstätter: I was more thinking of just repricing it based on how much it would cost with EVM code, and under the hood, clients could basically change nothing.

Kevaundray Wedderburn: I think that does introduce some complexity, right? Because you'll be repricing it based off of a contract that's not… In Consensus, like… It's easy for, precompiles that sort of have static costs. Like, if Blake2F was always just, like, 1,000 guests? But if the cost is, sort of dynamic or based on branching, then I think it becomes a lot more difficult. Like, you need a lookup table, essentially.

Toni Wahrstätter: You mean in the CKVM?

Kevaundray Wedderburn: I just mean to measure the gas cost of… the EVM code there. Like, if you imagine we… buildings,

Toni Wahrstätter: But to me, to me, what is not clear is, like, what is the difference to just… writing the precompiles in EVM code, then benchmarking them. And then repricing the precompiles based on that. And after doing so, they are expensive enough such that they are not an issue for ZKVMs anymore. And, at the same time, clients Don't have to change anything today. Because I assume the precompile logic is exactly the same. No matter if you write it as clients do today, in some optimized language, versus in EVM.

Kevaundray Wedderburn: Yeah, so I guess the difference is that like, if we just take Blake 2F, the easy case is that we measure it outside of, consensus. We just say, okay, the cost of it is 1,000 gas, and then you can just put that inside of the code. But, usually what happens is that the cost of a precompile is based on the input, so it's not sort of a static function, so it's not easy to… Just reprice it once. And then, have… and then just put it inside of the code, right? Does that make sense, Toni? Like, the gas accounting?

Toni Wahrstätter: Yeah. Yeah, it does. Yeah, I see. I have to think about it more, but this makes sense, yeah.

Kevaundray Wedderburn: Eocon says we should also PFI the identity precompile for Hegota. Yeah, I agree. I think this EIP relied on it, if I remember correctly. Or I might have removed it.

Jochem Brouwer: Yeah, it's nice to be honest, but then we should still be a Vice Hotel. I mean, it is implicit, but then we should still PFI 7, 6, and 6 together with 8200.

Kevaundray Wedderburn: Right, okay, makes sense. I guess the one funny case, here is the Modex precompile. Which, Yeah, if you look at the link that I sent in, for inputs that are less than 256 bits, it's used quite heavily, but for more than 256 bits, it's, like, barely used, and the less than 256 bits usage is predominantly just for snark or zk verifiers. Yeah, any questions?

Ansgar Dietrichs: Any other questions, comments? Two cups. EIP. If not, then…

Kevaundray Wedderburn: Oh, maybe I could make another comment, sorry. Yeah, maybe it's not super obvious, but this is, like, an implicit repricing, so… the website that I linked also sort of shows what happens if you, like, 2X the cost of a particular precompile, or 5x, like, what breaks. The main concern being that there is a transaction gas limit, so… you can't make it, like, too expensive, whereas contracts actually do break pretty badly. And yeah, I've tested out a few contracts to see, like, how bad it will be. the BLS12, this set of precompiles for BLS12 are basically not used that much, but I wasn't able to get, sort of, optimized bytecode for it. So it wasn't included.

Toni?

Toni Wahrstätter: Yeah, what is the argument of already doing it… now? Because if it's, like, impacting users, it might be worth to do it with a larger CKVM repricing later.

Kevaundray Wedderburn: Yeah, so… The idea is only to do it to the precompiles that are basically not used. So this shouldn't impact, users, like, it shouldn't break any of the users? any of the ones that… the ones that do break users, I basically just remove them from the initial EIP. So, like, that's why a BLS12 was, removed. Looked at the 19… right?

Ansgar Dietrichs: Okay, I mean, anything else to add, Decaf, or…

Kevaundray Wedderburn: I think that's it. Cool, thank you.

Jochem Brouwer: Yeah, sorry, I just have one question without this. So, for the precompiles, the reason why we want to EVMify is that it is going to be easier in the ZK EVM to, well, we'll use less code, because you do not have to need to have these, these dedicated circuits. I do not know what that means, but I can understand it from an engineering perspective. It's, like, a very nice property. So, my question is, like, for instance, we can see on your site that the BLSP precompiles are not being used as much. If we then want to, reduce our work, or, or, that we want to signal to the community, like, do not use these precompiles anymore, then we might also want to consider to either remove these precompiles, or, because they are actually being used, to reprice them to signal that we intend to remove these. And if you want to do that, then we should draft an EIP for this, and we should propose this forCode.

Kevaundray Wedderburn: Yeah, I mean, I think that's fair. It did sound a bit contentious, even if you look at the usages. But yeah, yeah, I mean, yeah, we could do that, it just sounds a bit more contentious. Especially since we just, added them, like, was it one fork ago, or… Or maybe it was 2. But yeah, you can, yeah, you can check the usage. Any usage, as far as I could see, was, like, maybe a bit spam, or someone testing out the precompiles, so it's not… Not being used.

Ansgar Dietrichs: Okay, yeah, I mean, now that this EIP is PFI'd, we could still consider just expanding the scope if there is appetite for that. Okay, then I think… That wraps up, Kev, your EIP. And with that, I think those were all the PFI EIPs for today. Is there anything else headquarter-specific for today to discuss? Okay, then for the last section, some housekeeping. We already went over the Hive PR by… Chase. So then, last thing is some housekeeping items by Pooja. I don't think it makes sense to go over all of them synchronously now on the call, but Pooja, is there anything specific from the list that you posted that maybe specifically requires attention?

Pooja Ranjan: Yes, I just wanted to share that from the last meeting, it was decided that all Glamsterdam upgrade EIPs can be moved to SFI, so there is a PR open for this, upgrade stage. And we are requesting author's approval there. It is pending for author's approval. In the last meeting, we also discussed about some of the core EIPs to move into the review status in order to keep it in sync. Once that is done, that is actually, approved by most of the authors just waiting on EIP 8038 to be promoted to review. Once that is done, the next step would be to move all other EIPs, which are not core, but networking and informational, and yet listed in the meta EIP to be moved to the review status.

I have added 5 new PRs in order to ensure that all other EIPs are also listed in the right status. We have received for, one. EIP8070, but for the rest, 4. PR is still open. I would request authors to maybe take a look at it, and kindly approve. So we can move all these proposals to the review status. And the final thing here would be, once all of the Glamsterdam-listed EIPs are in review status, then there would be another PR coming up for the next ACD meeting, where EIP 7773, which is the meta EIP for Glamsterdam, will be moved to review. But we can do it only if all other EIPs are moved into review status. So, kindly take out time, take a look at the PRs, and grant your approval. Thank you.

Ansgar Dietrichs: Thank you, Pooja. And with that, we've reached the end of the agenda. Is there anything else to discuss today?

Barnabas Busa: Maybe to mention that we have one more week left from the… Proposal? Deadline?

Ansgar Dietrichs: Yeah, I mentioned it earlier, but yeah, one more reminder, one week left for proposals, so, Anyone who feels particularly inspired about changing Ethereum, you have one week left, otherwise you'll have to wait for a while again. Okay, and with that, thank you everyone. You can take the last 15 minutes to celebrate. The birthday? But not on the call. Go celebrate somewhere else. And, I'll see you all in 2 weeks. Bye, everyone.

Marius van der Wijden: Bye-bye, happy birthday!

Justin Traglia: Hi, everyone.

Jochem Brouwer: Happy birthday, Ansgar. Bye-bye.

Transcript adapted from ethereum/pm, CC BY-SA 3.0.