All Core Devs - Execution #235

Transcript

Guillaume Ballet: Hello.

Ansgar Dietrichs: Hello, lol.

Okay, okay, okay, call is filling up, let's wait one more minute, and then we can go live.

Carson: The number of edge cases.

Ansgar Dietrichs: Sorry, what was that?

Carson: I just hit the audio button accidentally, sorry about that.

Ansgar Dietrichs: No worries. Okay, are we ready to go live?

Josh Davis: Ready when you are.

Ansgar Dietrichs: Perfect, then let's get started.

Josh Davis: Alright, you're live.

Ansgar Dietrichs: Perfect. Hello, everyone. Welcome to… All Core Devs, episode 235, I'll put the… Link to the agenda in chat. Mmm… And, yeah, we have quite a few agenda items today. Before we get started, though, one quick note in terms of ACD housekeeping directly. As you all are aware, Nixo already filled in for me two weeks ago on the call, and by all reports, did an amazing job there. And we wanted to announce today that Nixo will, join me as co-lead of, All Core Devs going forward, so… A very warm welcome to Nixu in that role. Yeah, I think this is going to be great. Mmm… And then with that, we can go to the… into the agenda. First up, we have quite a few Glamsterdam items, starting with DevNet updates. I think, Mario, you, had some BAL DevNet 4 related updates?

Mario Vega: So yeah, basically, we made a release, a couple of days ago, with the updated version of EIP83.7. And basically, it would be nice to hear from clients today if they were able to consume the test, issues that they have found, if any. Just to get, A notion of how, is everyone doing regarding this release? I think first question is, where… was everyone able to consume the tests in the latest release of EALTS tests? Yeah, I guess.

Ben Adams: Rift. Yes, from Nethermind.

Mario Vega: What issues, is there any issues that you have found, number of failure cases, or… Anything worth raising up?

Ben Adams: No issues.

Mario Vega: What about the rest of the clients?

Andrew Ashikhmin: On Erigon's site, we were able to consume the tests, and we are working on the BioDevNet 4 changes.

Mario Vega: Okay, thanks. The rest of the clients get, Do we have anyone from Besu, read?

Daniel Lehrner: On, on Besu side, no, no issues. So everything, everything worked as always.

emma (reth): On Reth's side, I don't think any issues either, but I'll let Dragon chime in if so, but I think we're all good.

Dragan Rakita: We are currently implementing them, so… cannot confirm. To have something today, maybe tomorrow.

Ansgar Dietrichs: Anything beyond that, Mario?

Mario Vega: Do we want to touch upon the topic of 83.7 yet, or…

Ansgar Dietrichs: I know we have this on the agenda in a bit. So, yeah. Otherwise, first, any other DevNet-related, updates or anything to discuss?

Barnabas Busa: I could maybe quickly discuss the progress, with the Merge DevNet, so Glamsterdam DevNet Zero. We have been working with Prism and Geth, to get some initial, DevNets running, and It's still a work in progress. Hopefully, tomorrow is the day when we get up and running. But it's almost there.

Ansgar Dietrichs: That's very exciting, that's a…

Barnabas Busa: Yeah, all of our tooling is updated to Alpha 5 now, and Yeah, we have the spec sheet with the current images that we can use, that you can use locally as well. I just pasted the link here.

Ansgar Dietrichs: Awesome. Any specific action items for the other clients there? Or just in general, for people to keep track of?

Barnabas Busa: Yeah, so this is just general to keep track of it, hopefully, based on the decisions that we make today, we can basically, finish up the, spec discussion for DevNet Zero, and then, Then there's just implementation questions going forward.

Ansgar Dietrichs: Sounds good. Thanks. I assume there's no further Devon-related topics?

Stefan Starflinger: I could just give a quick overview of DevNet3. It's still running pretty well. We have a gas limit of $60 million that I've increased to $100 million to correspond to, the… set value that we have for 8037. Now, and in general, I think only Erigon, still has some issues there, but I think it's not really worth to spend too much time on it and try to get resi for all Definite 4. Which we can then merge. But yeah, there's more topics on that. And we talked to Odia about it.

Ansgar Dietrichs: Sounds good. Then next up, there was a topic about, an engine API change. I think there were two separate proposals, PR's number 770 or 786, I think they would be… Physically, to alternatives. They were… the… the PRs were by, Mikael, but I think, Stefan, you… put the topic on the agenda. I think the idea is that this would ideally roll out together with Glamsterdam, if one of the two… Yeah, it's chosen?

Stefan Starflinger: It would be great, to have them implemented for Belle DevNet 4. But it's not necessarily required for the DevMet, so that we then have it ready for Amsterdam DevNet Zero, for them working together, because I think it was something that the CLs require from the ELs. And I think there's been quite a lot of work on it, In the past, so if Mikhilton or Potus maybe has an update there, they're more… In the topic.

Ansgar Dietrichs: I think Putis just joined, I'm not sure. Fortis, would you be ready to briefly talk about the… Engine API updates.

Potuz: Wait, sorry, I was just switching from phone to… To my computer, and I missed, I missed Stefan. Are you guys talking about my proposal EIP, or… oh, so these two EIPs, Amisha is not there. Yeah, okay, so I can briefly say a little bit. The issue is, we need to reorg back. to a previous head, which on the EL side might be canonical, it was already canonical. But on the CL side, it's actually on a different branch. Because the payload content is different. So these two EIPs address the same thing. And there's a difference in subtleties, on what is the depth of the reorg that is allowed. One EIP allows… so… forces the clients to support up to 32 blocks height of a reorg.

Which is more than what we expect to ever need. I think we would never reorg. More than, just one slot, unless there's a very heavily staked attacker. Or a bug. And then there's this other EIP… this other PR that proposes a reorg up to finalized, which is formally correct for the CL side, but on the other hand, it might pose a problem that is impossible to support on the EL side. So that PR says that they need to reorg up to the finalized checkpoint, the finalized hash, but if you cannot handle such a reorg, then you return an error. Anyway, so I would let the ELDFs to… this is a no-wop on either side for the CL. The CLs just need to be able to reorg. We already implemented the call to FCU to… to trigger such a reorg.

So, this is mostly on the EL side, on what's their flavor of what they… they… they prefer? So I would let to them to decide which one of the two. So the difference is, as I said, one forces the clients to Support up to 32, the other one… Says you need to support a deep reorg, which is up to the finalized hash, and if you cannot handle it, you just implement whatever you can handle and return an error.

Ansgar Dietrichs: M… What's the, kind of, timeline on this? Like, how urgently should we make a decision here?

Barnabas Busa: Good day.

Potuz: No, I kind of disagree with Barnabas here, but I guess this depends on the devs mostly, but it sounds to me that it's completely irrelevant on making a decision on either side. The client devs will trigger… the CL devs will trigger this reorg in this exact same manner. the… it's not a breaking change on the… on the… on the AP… on the API. we would just send the FCU with the payload attributes that would trigger this reorg, and then this EL handles it, or it doesn't handle it. So, the handling part is the one that needs to be implemented right now. Which one of the two PRs you choose, it doesn't matter, really, for us.

Ansgar Dietrichs: I see. Yeah, makes sense. Still sounds like it would be nice then, at least. Maybe it's not strictly necessary, but it would be nice to make a decision. Do we have, generally, like, opinions among the client teams of, the preferred approach here?

Marius van der Wijden: Yes, I already put my opinion in the chat, I don't care. 786 is… The more principled solution, 770, is the easier solution to implement for us. Both are okay, I think the, the big, the big difference will be in, in, in, in testing, One… yeah. So, I really don't care, and we should just make a decision.

Ansgar Dietrichs: Sounds good. Do we have any other client and… client team with… with any… preference? Otherwise, yeah, we just pick one.

Łukasz Rozmej: The difference is that it should be until finalized, or until some cup, right? That's the main difference?

Marius van der Wijden: Yeah, either until head minus 32, or finalized.

Łukasz Rozmej: Okay, so, like… I would prefer having some cup, can be bigger than 32, can be 256, which is, for example, 1 to 8, which is, similar for snap serving. For example, might be even. Make more sense than 32. But I would prefer to have the cup.

Ansgar Dietrichs: Yeah, the… does anyone who would strongly be, or would really prefer to not go with the CAP approach? Okay, the panel, just to double-check, the cap one is 770, right? Can we confirm this? Also, Tony, you have your hand up, maybe?

Toni Wahrstätter: Yeah, it seems like this cap approach is very simple, but I'm wondering what happens if we hit the cap, because there are actually situations where we could hit it, like, at least in theory, and I think POTUS is right, that we would just stall. And I'm not sure if this is the best approach. I remember Marek last time said something where the EL has to keep track of what the finalized block is, and depending on that, keeps more state lips around. Just to make sure that we don't fall back into snap sync in such a situation. like… The cap is probably the easiest thing to do, but it doesn't seem like the correct thing.

Marius van der Wijden: Yeah, but if we're doing more than 128 block reorg, then we also have some other problems, right?

Parithosh Jayanthi: I mean, during non-finality, it is a possibility, right?

Toni Wahrstätter: Exactly. If we have no finality for some period, this is just like, if we do the cap, then we have to… live with the fact that ELs might not be able to attest to blocks after such big rewards. And this is something we have to be intentional about.

Ansgar Dietrichs: photos?

Marius van der Wijden: Well, no, not really, because we can always reorg to a different chain, we just cannot reorg within the canonical chain.

Parithosh Jayanthi: But during non-finality, you don't know what's canonical.

Toni Wahrstätter: Yeah, and would you have the state around? Like, if you had to react 130 blocks, there's no state around anymore, so…

Marius van der Wijden: No, we haven'.

Toni Wahrstätter: How would you go.

Marius van der Wijden: We have, we have the, we have the state diffs. We can just go.

Toni Wahrstätter: Okay.

Marius van der Wijden: that other block. So the, the, the, the thing is, We… What we are changing here is whether we can reorg to a previously canonical block. And also, the thing that Peritosh is saying is wrong, because canonical in that sense, means the… the block that we have currently as head. So, we… Right now, we cannot reorg to an ancestor of our current head. And this changes it, so we can… can reorg to ancestors of our current head. There's… I don't see any place where we are reorging to an… where we need to reorg to an ancestor of our current head that is not this new speciality of EPBS. In every other case, we have a con… we have another chain.

That has some descendant that is in… within our… current chain, but it's not on our current chain itself. So, we will happily reorg over there. And that means undoing some blocks, and then redoing some blocks, and then arriving at the… at the… at this, con… A competing chain.

Toni Wahrstätter: I see, okay, this explains it. So the question would then be, can all clients do that. Arrive at the state that is, like, potentially more than 128 blocks in the path.

Ansgar Dietrichs: produce underpower?

Potuz: Yeah, so I think people are missing some nuance here of what these reorgs are. Marius is right, that this is a different… so that the EL is supposed to already handle a reorg in which there is actually two branches on the EL, But, again, I think people are missing something, which is the fact that this reorg is not going to be triggered network-wide. It'll only be triggered by the next proposer that is trying to propose a block based on a previous payload. everyone else in the chain will not trigger such a reorg, because it will not send an FCU with, payload attributes. So this is just simply let the next proposer trigger block production for a previous… based on a previous head.

And then everyone that gets that payload and gets the next block, it will see on the EL an actual fork, an actual reorg, which can be as deep as it wants. So I really don't see what's the push against just put the cap, your implementation would be the same, implement the reorg up to 32, but let the spec says that you're supposed to implement the reorg up to finalize. The implementation doesn't change, that's why I don't care if this decision is made now or not.

Toni Wahrstätter: The thing is, ELs need the state at a block where they want to reorg to. So if the reorg.

Potuz: If they don't have it, it's fine. They can just return an error, and the EPBS proposer is going to support… it was going to rely on the next builder being able to propose that block. If no builder supports this, then we're kind of screwed until some EL client can actually make the reorg. But this reorg might happen. If we know… if no one supports it, then we just stall, and that's it. That's… that's what FortChoice tells us.

Marius van der Wijden: Why… why do we need to build on top of a block that is, like, 128 blocks, or…

Potuz: Ford Choice, the guarantees that Ford Choice gives us is just that. Everything can be reordered up to the finalized thing. In this case, everything that is not finalized can always be reorged out. That is what finality means, that's our finality gadget. We need to change the entirety of consensus in Ethereum if we're not going to support reords of anything that is not finalized. And answering to Thomas' question in the chat, by definition, a reorg is proposing a block on top of a previous head.

Toni Wahrstätter: So just to clarify, this means if I'm a local builder, and I don't keep more than 128 statistics around, and the Rio is deeper than 128, then I won't be able to propose a blog.

Potuz: That is correct if… unless some builder actually gives it to you.

Marius van der Wijden: You're gonna send them…

Potuz: you, and some builders are going to be… if some builder actually manages to propose it, you're going to take that bid.

Toni Wahrstätter: Okay, then I guess we should specify that somehow, that builders should keep around more status than just the 128 that I guess most EL clients do.

Marius van der Wijden: No. So, Tony, we are able to support reorgs up to 90,000 blocks in Geth. We only have the 128th forward state diffs, and then we have the data on disk, and then we have 90,000 or 90,000 minus 128, I don't know. reverse state diffs. And what we would do in a reorg that is longer than 128, we would roll back to the snapshot on disk, and then we would apply these reverse diffs to the disk. Until we get to a… to the point where we are being re-oped to. What we cannot do is reorg to something that is longer than these 90,000 blocks. And these 90,000 blocks are chosen because it gives us 2 weeks of

Non-finality.

Toni Wahrstätter: Right, but this isn't a critical path now, so… I think we should just do benchmarks and see how long it takes to take 90,000 statives from .

Marius van der Wijden: I can, I can… I can tell you it takes, it takes, like, 4 minutes or something.

Ansgar Dietrichs: Okay, can I briefly interject here? I think this is going too deep. I think this would be best taken offline, so the question then to me seems… I mean, I must say I'm not super deep in this topic. I would personally feel like that it would feel a little problematic to take the cap approach and lock it in today, because, I mean, it seems like it's probably fine, but given the concerns and the confusion around this topic, then I would rather take it offline and make sure everyone is actually aligned with this. If we want to make a decision today, I think the only option would be to go with the other approach. The finality-based one, which seems like the proper solution.

yeah, I don't know, do people want to take this offline, or do we just want to have it to go with the, What's the number? 786 today?

Marius van der Wijden: So the only problem with 786 is that, we might not be able to support it fully, because we… At this point, we have no… where this happens, we have no real, notion of finalized. Like, Geth is not storing what the latest finalized point is anywhere, so there might be cases where we don't know if, like, we would… we might just do a reorg beyond finalized, if the CL tells us.

Potuz: Don't you get… don't you get this finalized hash on the pay… on the attributes itself?

Marius van der Wijden: True, yeah, we could. But then we would need to go through all… through all blocks and see whether this was… Before or after, I was thinking about…

Ansgar Dietrichs: Alright, so Marius, would you feel comfortable today logging in 786, even with those concerns, or… What's the situation from death's side?

Marius van der Wijden: Yeah, we can, we can, we can do it. Well, the problem with putting the cap internally, Portos, is that the testing team will go ham with this, and will create tests that we can then They're not, do because we have the cap.

Dragan Rakita: Maybe…

Ansgar Dietrichs: Go ahead.

Dragan Rakita: idea, maybe we can leave for the team to test and see how the clients behave. And after that, decide on the limit. particular… We could just choose one number and just see how clients behave.

Ansgar Dietrichs: Postal?

Bosul Mun: Sorry, it's me, actually, it's Felix. Maybe funny. I just wanted to ask, so, are we confirmed now that the 786 is going in?

Ansgar Dietrichs: Well, it was… I think when we're about to make that decision. I… Personally, I feel like it might just be best to basically just, like. block… go with 786, but just to revisit, I think we have some… in-person events next week, as well, where maybe the… if there's some concerns or so, that could still be addressed. So, with the understanding that this decision could be reversed if there's unexpected issues with it, but just so we have a decision, I would propose we go with 786. Mario?

Mario Vega: Yeah, I just wanted to understand a little bit better what is being left upon us. If we don't have a number or a tag. against what to test, it doesn't feel like we can validate anything, right? There's always a… you need a number to verify anything.

Marius van der Wijden: Well, so one… one thing that we… that we can also just spec is that we say all clients must be able to do one block. reox when, within the current head. And not… and not… Even specify the behavior for… for… what happens with reorgs that are longer than one block? Or longer than 32 blocks, or longer than 128. So this would be a way of… Going around this.

Ansgar Dietrichs: So then, what, what is the implied for the decision today? Do we just… Is it okay if we just… Say… 786 is our candidate, and then if they're… if they are… Lasting concerns, we can revisit, but we log in 786 for now? Anyone… Opposed to that? Okay. then let's do that. So, 786… 78… sorry, sorry, did I confuse the numbers? I think it's 786, yeah, 786…

Barnabas Busa: How hard is it?

Marius van der Wijden: Sorry.

Ansgar Dietrichs: No worries. 786 it is, and yeah. And we can continue the discussion there async, if there's anything we have to discuss. Okay, awesome. Decision made. Next up, Protos. I think there was this… there's this new EIP, 8237. My understanding is that there are some reasons for why we might want to consider a kind of… out of… out of process emergency inclusion to Glamstadam, already, so then today we would basically CFI the EIP. Can you give people some context on… The situation?

Potuz: Just a disclaimer, I… I mean, this needs to be on a fork. It doesn't really need to be in Glamstaden. I think every client has already implemented Sync. It is a very minor change, I think so, and and it'll make syncing, especially on non-finality, much, much faster and safer. So let me describe what the change is, and I'm not really advocating strongly to keep it for Glamsterdam, it's just that I think it simplifies our life quite a bit. The reason is that, up to now, we sync blocks by… say that we're not finalizing, you spin your node that has been offline for a few days, but the EL side has the full state. the Seattle side is on a very…

Far away head several days ago, and you still want to not You want to follow the chain. You want to download all blocks and follow the chain. Currently, we download everything. We download the blocks that already contain the payload for the execution site. Some clients even download this twice. So what the spec says is that when we download these blocks, we execute the state transition function on the consensus layer, we send the payload to the execution layer to validate, and we continue like this. Some clients don't even send the payload to the execution layer, they validate the block hash themselves. And then they let the execution layer sync on their own, which means downloading the payload yet again.

And what I'm proposing is for the CL to not even download the payload at all. We've just merged a PR, a change to EPBS, which is 1594, that allows us to execute the state transition function without ever validating the block hash, without ever even seeing the payload. The problem that this brings is that there are some fields on the payload that needs to be in sync between the EL and the CL, Some examples are withdrawals. We need to make sure that the withdrawals that are, fulfilled on the CL side match what the withdrawals are on the EL side. Currently, since withdrawals are part… well, since we have them as part of the block hash check, then since we are checking the block hash, we are checking that the withdrawals are right, and we have this as a validation on the payload anyways.

But if we are not validating the block hash, then we need to have some way of making sure that whenever we get a valid, we actually catch up to head, and the EL has catch up to head, and we get that the EL has had a valid execution up to the head, then we need to make sure that everything that was proposed was already, consumed on the CL side matched what it was consumed on the L side. So for this, we need a new accumulator on the L side. It could be on the block header. It could be on the payload, and this accumulator just hashes the previous hash, the withdrawals, the execution requests, and so forth, with the previous value of the hash.

So this means that when we sync to head, and we find out that the block was valid, and we both, the EL and the CL, have the same accumulator, then the whole chain is valid, and all of our validation was correct, even though we never saw a pay loop. So this requires changes on the EL side, and that's why I opened this as an EIP. I would need input into how difficult it is. On the CL side, this is essentially a no, it's a very small change. And it would allow us to, like, remove All of the syncing by range on payloads, for example.

Ansgar Dietrichs: Sounds good, thank you for that context. Have EL… The client teams already had time to have a look at this? Okay, Panos, thank you for the context. Sorry, I wasn't aware of that. Okay, so then I assume people are aware. I think the main question for today, then, would be, is there a reason to… is it worth considering adding this, to Glamsterdam, yet, or just basically have it wait in line for H-star? Obviously, the threshold for adding ERPs after the The window… the proposal window has been closed, should be high.

So yeah, I'd be… I don't have the context on this, I would be curious if people have opinions on… how valuable it would be to consider this in Amsterdam already.

Marius van der Wijden: Well, For us, it's a no-op, because we don't depend on the… On being given the payload from the… from the CL, we have our own sync.

Potuz: It's not a no, Marius, I'm changing the state transition function on the EL. You need to add this accumulator and check the validity of it.

Marius van der Wijden: Oh, sorry. Yeah, no. Then, not for glamsterdam.

Toni Wahrstätter: As far as I can tell, it also involves changing the EL log header, and… new payload in the engine API.

Potuz: New payloads shouldn't change. If we add it to the payload.

Toni Wahrstätter: Right, same thing. Right, right. Yeah, right, the new payload wouldn't change, just the payload itself would change, yeah.

Ansgar Dietrichs: Okay, so it sounds like, I mean, given that process you have also burned, actually, sorry, I think I misunderstood this in the lead-up. given that you yourself also don't necessarily think this is high value for Glamstadam already, and if there's skepticism from the EL side as well, that it amounts to that level, then I think… we just, by default, add it to the, the list of, of PFI, HSA EIPs. For now, and… Yeah, and so make sure, context by Barnabas in the chat as well. Sounds good. Anything else, put us to add to that EIP, then?

Potuz: No, no, just… it's just requesting ELDF to look into this, because, it is… it is really a matter of safety, like, sinking on the case of non-finality is something that we have had trouble even testing. The solutions we had is to agree, coordinate on an unfinalized checkpoint. And then have our clients, like, trying to be pointed to an unfinaled checkpoint, and try to sync from there. Which requires, again, like, dealing with this… this sort of meetings, and agreeing on what the checkpoint would be, and these kind of crazy things, whether this would just bring us back to syncing speeds pre-merge. Which, I think people should understand how much of a game changer it is to sync for us without downloading the payload, and having tiny blocks to execute.

Ansgar Dietrichs: Sounds good. Awesome. Then, I think that's all for now, then, on this EAP. then you're sorry for misplacing it in the Glamsterdam section. Next up, then, on, Glamsterdam, the last main item is… EIP8037 testing concerns. I think, Mario, you wanted to… to… to bring this up.

Mario Vega: Yeah, thank you. I'm gonna share the comment that I posted. Basically, it's a summary of the things that we found during the last sprint, where we tried to make the release, which happened at the start of this week. We hit a bunch of issues during that, and I think, the main purpose of us, like, highlighting these issues is that we want to make sure that we… everybody understands, what we found, and everybody is okay with us continuing with the EIP as is. And basically, I mean. There were… there were several issues. One of the main ones that I… I would like to highlight first is the amount of tests that broke, and required changes. So, basically, around 30% of the tests, I would say, were, had to be updated in some form for us to be able to run them and fill them, for you guys to consume.

this is due to the, the new account creation and the new, block gas limit interaction of the… of the transactions, with this new EIP. We thought that it would… it was basically Concerning, because, while, I mean, it's a simple, perhaps, couple of changes per test. it feels, it feels, like, not common for an AP to break this amount of tests, or require this amount of changes for a test. What I wanted to highlight is that perhaps this could, manifest itself, in some other ways, right? After… after the fact, when the EIP is finally live in Maynard. Perhaps, interactions with, with, with contracts, etc. So I think it is worth highlighting that this is breaking an unusual amount of… of tests.

The… Another thing that we, we found it really hard is, like, now with the, state gas, dynamics that were introduced, we normally have to specify gas limits to be able to verify edge cases on gas consumption, right? So, if we have a test case where the… the test is supposed to consume and run out of gas specifically at a certain point, or during a gas… oh, I'm sorry, up-code operation. This is very hard to do now, because now we have the reservoir interactions happening. So, I would say that we have fixed most of the cases, but, we're still worried that we have to really double-check that we have not made any test cases, any pre-existing test cases inefficient because of this change.

That's one concern. Also, I mean, this would require for us a lot more time for… to process, to be honest. We do not… at this very point on the… on the stage of the… of the deadness, we do not feel confident about the amount of coverage that we have achieved with this… with this, with our tests. Another point is that the… we have not sufficiently colored the edge cases of the refunding mechanisms for this EIP. Basically, there's a lot of bullet points that describe the refunding mechanisms in this EIP, and we still need more time to fully coverage To, to, to achieve the full, the full coverage that we want to with this, with the CIP.

And I think lastly, the things that we still have to resolve, and, some, members of the other teams can, can, can, can chime in also, is that the benchmarking is going to be more difficult because, one of the key controlling aspects of the benchmarking that we do is that we need to control perfectly the block estimate, right? For the setup of the benchmark tests. And this is now directly related to how, the estate, opcodes are charged to the… for the transactions. So this makes our lives much harder. We have to plan on how we are going to modify the benchmarking test. Still, we have not resolved this issue, and we still have to think about how we are going to resolve it.

We have, more issues, that, I… I think… I mean, simpler issues, but it's, it's… it's good that we raise this, these points, so we get to discuss them, get to see if there's… if this is sufficient concern. For us to ask for a simplified version of the EIP, or is it too late in the process? Yep.

Ansgar Dietrichs: Yeah, I would also have some comments on this, but Andrew, maybe you go first?

Andrew Ashikhmin: Yes, so I think, indeed, 8037 ended up to be very complicated, so on… probably on par with, with the headliner blog access lists. So, I think… we should keep its salient features and simplify it when we can… where we can, without compromising, like, its, you know, structural soundness. So, to me, just having, the… State gas limit. to be derived, like, to… to be just hard-coded, like it is on Bell DevNet 3, is fine. We can always, you know, like, make it dynamic later, and readjust it later, and maybe have a small walk or whatnot, but I would… I would keep it simple.

But, you know, logically sound.

Ansgar Dietrichs: And Marius?

Marius van der Wijden: Yeah, so I think it makes no sense to have this, 8037 with fixed gas costs, because that really defeats the purpose of 8037. What we… What we would just instead do is pull it out and set a static gas cost for how these, how, how state, well, how state-producing, operations cost. How much state-producing operations cost. The problem with this is, we want to massively increase the gas limit with block access lists and the to, 60 megas per second, we can, in theory, handle at least 300 megas per block. So, if we set the… Cost? as if we have 300MGAS, and we stay at 60 MHz, then all of the costs for users will 5X. So…

We can only really change the… The gas, the gas, costs? As long as we also change the gas limit in the same at the same time. So… I think it makes no sense to have this static gas cost in 8037. Either we do 8037 properly, or we decide to pull it out and just 5X all of the gas costs, or maybe even more, and, and then go to $30 million.

Ansgar Dietrichs: Maria?

Maria Silva: Oh, sorry, can you hear me? Yes. So I… I think I would advise, I guess, pulling it out, so I think… so… the decision between a fixed gas cost and completely pulling out these EIP, I think, is the difference between remaining at the current block limits versus Maybe trying to guesstimate the… Better, in hindsight, what the… average gas limit will be between Glamsterdam and Eguta? Because on EGOTA, we could update this again, if we go with the… with the fixed, cost per bite. I agree with Marius that having the dynamic one is nicer because it gives us more flexibility. On the… on how we increase the… the block limit. Another kind of, like, middle ground would be some sort of, like.

preset, schedule, where we say we will go through these gas increases between Amsterdam and Agata, and try to have either… A middle ground, anchor that maybe at the beginning will be too expensive, and at the end will be too cheap, so it will kind of compensate, or we even do something like BPO-style forks, where we just have a schedule for increasing both the gas limit and the cost. I just think any of these options are better than not doing 8037 at all, because that means we cannot Increased, the block limits.

Ansgar Dietrichs: Yeah, maybe, just, before I get back to, Andrew, from my side, I would just say that, Given that the… theme of Glamstadam is mainly around scaling, and that without any changes to state gas, state creation cost, We basically have this shared understanding that there is no real headroom for scaling beyond, where we are at basically now already with the E70 changes. So that, to me, means that, basically, Amsterdam will need to have some version of this, or some version of state changes. I would maybe personally just take these flagged concerns. This is kind of the third round, I think, now, of concerns that we had. We had the breakouts where we already tried to simplify. There were some other attempts there. It really does seem thorny to get to a better version. Doesn't mean it's not possible, but I would say that maybe

we should just, going also into next week, and, and some of the work there, just… basically make it a priority to… to… to try to find the… basically, the simplest possible version that we… that we feel is realistic in the circumstances, but not today, maybe make… I would… I would try to… I don't think it is productive to specifically try to find a concrete solution today. I think the design space is too complex for us to… for us to discuss this live on the call now. But I still think, yeah, if there's concrete comments now, I think that's fine, but I would otherwise just say, let's flag this topic as something important. Andrew, do you want to have… add anything to this?

Andrew Ashikhmin: Yeah, so, yeah, I, I agree with Maria, and we all already have a precedent, we have the, BPO schedule, so I think, that, cost per state byte, can… can be, static, but with a schedule, so we can… I don't see a problem with that, if it makes… Our lives simpler than there is already a precedent.

Ansgar Dietrichs: and Anders?

Anders Elowsson: Oh, yeah, I can just mention that I have a research post where I present such a schedule for changing the gas price as one of the options to do this. And I would also like to mention that this dynamic price is not… It's not a critical feature of the EIP, because it's still a guessing game, and we try to guess, you know, the demand elasticity. So it's not like having this dynamic change with the gas limit ensures that we get the exact price that we want. It's not like that at all. So if we do, for example, some sort of, where we can manually make adjustments along the way, then we are probably in a better place than if we have this dynamic. So, it's a matter of complexity there.

Ansgar Dietrichs: Sounds good, and maybe if you can find the link to post it in chat, I think that could be helpful for people. Yeah, again, I think, for now, really, I think for today, mostly just about flagging the issue one more time, so people are aware that this still is not fully resolved. Any last comments on AD37 for today? Otherwise, I would move on. I…

Maria Silva: I… I just have a quick question, just to make sure. So, how does this impact VolDevNet 4, so VolDevNet 4, we're still doing the dynamic cost, right? It's just the test coverage is not… as wide. Is, the case.

Spencer Taylor-Brown: Maybe I can say something here. I think, I feel like we should stick with, Bell DevNet 4 as the current spec is. And any other changes we can discuss next week and follow that up, either during next week or… after, after next week. We did add, I think. Around 200 and… it was 208 unique tests following From Belle Devin at 3 to Belle Devonet 4 specifically for 1837. So we did already add significant coverage, but, Yeah, it was very rushed and needs more, more eyes still.

Ansgar Dietrichs: Sounds good. Anders, do you have your hand up yet, or again? Anders? Otherwise, Peter?

Peter Miller: Oh, hello, Yeah, I… was one of the people who, like, flagged this, so, Steel, like, sat down and talked about, like, all of the complex problems, and we, like, went through the IP to try and, like, get to grips with it. I think the big concerns we had on, like, a sort of conceptual level, I know that Mario's talked about the practical situation. Is that, firstly, this is, like, a transitional EIP. Like, in the long term, we want to do proper multidimensional gas pricing, and the concern… part of the concern is that there's a lot of complexity later 37, and it's not clear that that complexity is going to stay into the world of multinational gas pricing when we don't, like, have

That much of a grasp on the final design. And I'm worried that some of the quite complicated mechanisms, related to reservoirs could be designed differently, and it's just got really complicated. Another class of problems that came up was that I, after reading the IP, flagged that, some of the gas cost numbers related to how many… but how much bigger does the… because there's some numbers in there that say, how much bigger does the database get if you… increase… if you do a certain operation, if you add a storage key, if you add an account. And I wasn't sure if those numbers were correct, and so there's also a little bit of a concern about whether the EIP, has had enough eyes on it.

And so I just wanted to, like, get a feel for… Where people are, because… this EIP is just turning out to be a lot of implementation complexity, a lot of technical complexity, and I really don't… and I think there's just a bit of concern that if we commit to that. we're committing to adding a lot of complexity that is stuck forever because it's part of the history of the chain. And so, if it was, like, an EIP… if this was an EIP that was, like, transitional and was turning out to be really simple to implement, I would… we'd entirely be on the side of… implement it, and, like, we'll fix it properly with the multimedical gas pricing. But the experience that we have

seem to be having is that people are running into lots and lots of problems. And if we're gonna go through that much pain, we kind of want it to be for a permanent solution. Rather than, like, this transitional solution before we go to proper multi-dimensional state gas pricing in presumably, the next…

Marius van der Wijden: So, just as a counter to that, I think most of the complexity, or all of the complexity of 8037 is actually within the metering within the EVM, and that will not change between AT37 and whatever fully… fully multidimensional gas thing we're going to decide on. The… the thing that's going to change is how these… how are these reservoirs collected, and how do we put stuff in, and how… how much do we put back out? So, basically, the outer frame of the EVM, but not within the EVM. So this is kind of my counter-argument why, Why, this is… For me, this is the first step to the fully multidimensional gas, spec. Because the metering that we need to do in the EBM is not going to change. And also, the dimensions that we're going to add

are likely not inside the EVM either, right? Except maybe for state access, everything else, call data, Whatever is outside of the EBM.

Maria Silva: Can I… can I just add, like, all the transitional part and also the complexity part? So, I think… it's not helpful to say things are complex without stating specifically where things are complex, because I think what is happening with 8037 is that for testing, the complex part is a completely different part from what is complex for clients and implementation side. So, my understanding is that for testing, the complex part is the dynamic cost per bytes, okay? While for client implementations, the part that is giving the more complex… or is giving more work is actually the multidimensional metering part, so separating regular gas from state gas, okay? And so on those two features, so this EIP is mainly those… these two features.

the feature of the multidimensional metering, as Marius was saying, is definitely not transitional. Like, we need to have that. To be able to better manage state, and then do… the longer-term full pricing thing. Like, if we are not separating… if we are not calculating how much state gas is being used, we cannot price it. So all that work from the client side is not transitional. It's something, like, all the issues we are facing, we are already resolving them now, so when we introduce new dimensions, it will be much simpler, okay? where I sort of agree on the transitional part is the dynamic cost. So the dynamic cost is the part that is giving the most headache to the testing side, from my understanding.

And that part would be… Or would be better implemented in a more long-term pricing. And on that part, I think we can discuss better alternatives, but I would really strongly argue against the idea that the whole EIP is transitional. There are a lot of things that we are implementing here that are really important and will be important going forward.

Ansgar Dietrichs: Sounds good. Yeah, I think, again, I really don't think it would make sense to try to push for any changes in any form today. I think it's really just about saying, yes, let's revisit this. It doesn't yet… Seem, like, in a place where we are comfortable… we are… High conviction that it will remain in its current shape. Okay, perfect. Then I think we can go to the next agenda point for now. Well, there was one more agenda point for Glamsterdam, but this one, I think I just want to briefly mention, last call for mascot selection for Glamsterdam, so do go to the agenda if you want to participate there. And then we can move on to the, HEGOTA-related items. We have two EIP proposals there.

For PFI, the first one is, EIP8163. And that was… proposed… Yeah, 8163, the extension opcode, do we have the author on the call?

Piotr: Yep, can you hear me?

Ansgar Dietrichs: Yes, you can go ahead.

Piotr: Okay, thank you, hello, my name is Piotr, I work at Monopt Foundation. I'm here to intro EIP8163. Which reserves AE as an extension opcode. So the AP asks to agree that Ethereum EVM will not use the AE opcode as a valid instruction. And that it will remain equivalent to invalid. The idea is that AE would be reserved for other ETM implementations to use for features requiring new outputs. And without risking, becoming incompatible. because of the conflict, using conflicting opcodes, right? And, if new features prove to be successful outside Ethereum, the idea is that they could be ported back. And… Well, that is really basically it. I will post… paste the link to the EAP and Evemark a thread in the chat for details.

Soon, and my first ask, is… are there any concerns with the proposal? Second, what would be the best way to formalize… to formalize such a commitment? Should I just go ahead and propose for inclusion in Agata? And if not, what other options are there? Yeah, I'm… Yep.

Ansgar Dietrichs: Sorry to jump in. Thank you, Piotr. Actually, just a quick comment there from my side. Unfortunately, I'm not super up to speed of the details anymore, but we actually, a year ago or so, had some discussions on orchadevs regarding… similarly, back then, there was this roll call effort, and out there came this idea to… I think back then was to formalize blocking off some precompile ranges for exclusive L2Us, and I think we did that through some meta-EIP of sorts. Would have to look back to the details there again. I think we also already started discussing back then, blocking off opcodes. It's obviously a bit more committal, because there's a limited opcode range, versus with pre-compile addresses, it's kind of free to do.

But I think, so basically there is precedent in this direction. So, in principle, this should be possible, and should maybe then follow a similar approach to, to the, to this pre-compact topic. But yeah, of course, the specifics of whether we actually… ready to do so would then be part of the, H-star. governance process, I would say. yeah, any, any other clients? Comments? On this now?

Marius van der Wijden: Yeah, which, which one, which number was it, 8… 8E or something?

Piotr: The number of the opcode of the… or the APS, AE. I… I posted something in the chat, but it doesn't seem to have gone up.

Marius van der Wijden: shoreline.

Ansgar Dietrichs: Did you maybe DM?

Marius van der Wijden: Yo.

Ansgar Dietrichs: I can see your comment, by the way, Piotr.

Piotr: Okay, okay, okay, so it's just grey dog.

Marius van der Wijden: Yeah, I don't know, it seems to me that this might be better in the F range, if we still have something in the F range, but… Yeah. Otherwise, I'm totally fine.

Piotr: Yeah, I mean, there isn't much, you know, logic behind the choice of the AE, I just… it just seemed, like, less… least obtrusive. Away from any parts of the range that is interesting further. But if there's, like, counter-proposals, then, Yep, I think, I encourage everyone to maybe leave them in the IFMAC thread. And… F range is… yeah, it is, it is pretty crowded. And sorry, Anskar, I didn't quite catch your suggestion about the, like, the governance process. Is it… is it… Should we just go ahead and… Pfi this?

Ansgar Dietrichs: Yeah, I think in general, it can't hurt to just say we print out PFI this, and then closer through the decision process if we think that it should have a different form, or, whatever, we can always make corrections, but this way it doesn't just drop off. So I think, PFI is suitable PFL now.

Piotr: Okay, sweet, makes sense. And, thank you very much, that's it from me. There are no other comments.

Ansgar Dietrichs: Perfect. Thank you. And then we have, Greg, who wanted to… directly propose EAP7979, but also wanted to, I think, talk about one or two other EIPs in connection with that. Are you on the call?

Greg Colvin: Yes I am. Can you hear me?

Ansgar Dietrichs: Yes, go ahead.

Greg Colvin: Okay. Yeah, I wanted to put these in today, bring them up, and, you know, proposed them. And sometime in the next couple weeks, have a breakout, so that two weeks from now, we can start, to consider them. We can push that schedule out. I've, I've sort… I don't know when we're actually going to close off, close off this stage of the process, but I want to get it going. So… It's a very simple proposal, so far as the interpreter goes. You can pretty much read, the first several lines of the abstract. You could almost implement it from there. We've implemented it. I'm not sure how many times,

I think at least 3 times in some clients. So it's simple to do. We know how to do it, so it's very low risk. From that point of view. So if you're only down to technical considerations, I don't think that's a very difficult discussion. If you're still not understanding the value, or have other motivational issues, or wanting to understand things, I've factored most of the motivation out into that higher level, informational EIP, because over the years, there's just been any number of things that someone hasn't understood, and I don't blame anyone. This topic spans everything from interpreter design, to, graph theory, and everything in between.

So… And then the third one… is if somebody really wants a lot more instructions with more power, there's a very stripped-down version of EOF functions, that I would prefer not to propose until, a future fork. Split it this very simple proposal. Can, get in first and pave the way, because this is pretty much the minimum that everyone's gonna need. So, that's what I have to say right now.

Ansgar Dietrichs: Sounds good. Thanks, Craig. And… yeah.

Greg Colvin: So, if there's any questions on that, people like to bring up now. Either a proposal or a schedule going forward.

Ben Adams: Yeah, so is this the… I know there have been a number of, proposals over the years. Is this the preferred format? But you… Me too. At this stage.

Greg Colvin: Everything… Everything before EOF is basically dead. Has been for a long time. Uf is still there. So far as I know, it has no champions. So, it's on life support at best. And, so this is… this is pretty much a resurrection and reworking of, EIP2315 from long ago, attempting to answer all of the… all the criticisms there that I felt were legitimate, and in the informational EIP, I just answer all the questions that came up there and through the years that seemed to need answering. And there are, of course, discussion threads on the magicians, and

I would really like to hear there, or one-on-one, or on the breakout. from people who are just really opposed to this, because over the years, there's been certain people who've just been really opposed, and I'd like to understand why and see if there's changes that'll make a difference, or if the opposition is essentially unresolvable. And I'd be better off pulling the proposal now, rather than put, you know, more months of work into it.

Marius van der Wijden: Yeah, I can speak a bit on that, because I was pretty opposed to the first one. And that was okay with, with the EOF, but… What changed for me there was… was definitely Solidity putting their weight behind it. I think that there was the… That was the main reason why we removed the first one out of the fork, is because Solidity said that they're not going to use it, and I'm… I'm not opposed to the idea. I think the idea is pretty good, and it's… it's necessary, but if no one is going to use it, then it's just technical that we are introducing the protocol. With EOF, that was different, because Solidity said that they are behind EOF, and that they are going to use it. So I…

would really like to have, Solidity's opinion again on this one.

Greg Colvin: Yeah, I'll certainly invite them to the breakout call. There's a difficult chicken and egg problem here. Bryant from Viper expressed it quite explicitly all the way back at 2315. I forget how many years ago that was. He was asked if Viper was going to use it, and he simply said, we do not make plans based on the whims of the core devs. that essentially they were not even going to examine it, until it was actually on the chain. And there's been even more rug pulls since. So I think it's difficult for any team to put the resources into examining it if it doesn't exist. And in the case of 2315, the changes that one part of Solidity demanded then caused a performance regression that another part of the Solidity team objected to later. So it's just basically difficult to do, and I almost hate to even ask at this point. There's been so many rug pulls.

So this is just such a very simple thing. The mechanism has been the underlying mechanism for every proposal so far, and many VMs over the years. So it simply seems almost harmless. If ever a higher level language wants to take advantage of this, you know, either this or a follow-on will be what they need. Yo. And if we have to get buy-in from all the compiler teams, I cannot volunteer the time to do this. And I will simply leave the EVM broken in this way. You know, I'll do what I can, but there really is a limit there. I know for the… for the compiler I want to write, this is absolutely necessary, and I'm not the only person whose work is… is either completely blocked or made far more difficult by simply failing to have these industry standard instructions.

Ansgar Dietrichs: VIN.

Greg Colvin: So, that was a long answer, I'm sorry, but…

Ben Adams: From the NetherMind point of view, we have, tried to do, sort of, AIT on smart contracts. one of the issues is with just pure random jumps everywhere. Essentially, an EVM contract works as, like, a… a 30 kilobyte… Single function. And that becomes… next to impossible for a compiler to optimize. It can… it can create the machine code, but it can't… The… because of the complexity. Can be essentially infinite with, how the Everything jumps around. It just sort of bails on trying to optimize. Yeah. So, it would be good to have some enforced structure. To… to smart contracts. And that, that will probably also… or what Guillaume was talking about in terms of chunking.

Having that structure will fit more, better with… with code chunking. Rather than, you know, you jump from Jump completely all around the contract, it's just all go-to's. So, yeah, it's still worthless.

Greg Colvin: Yeah. It goes quadratic at best, and exponential at worst, and sometimes impossible, depending on what you're trying to do. That's good.

Ansgar Dietrichs: And any other comments or questions now, synchronously, on the call?

Greg Colvin: I'll point out that the validation, is optional, and happens at create time, so before the interpreter runs. And the instructions themselves, are backwards compatible. So they run with the same semantics, whether they're in valid code, validated code, or if they're in, so-called legacy code. So, you only need one interpreter, it does exactly the same thing. And the only difference is that, EF-marked code, will… will be, validated before it's run. So for… for those blocks of code, other tools can know that, yes, this is valid code, and I can, I know that it will have the properties that I need.

Ansgar Dietrichs: Felix in chat was asking, but then, can we remove the validation? I still don't get it.

Greg Colvin: I can't talk and read chat at the same time. Well, not having validation was one of the strong objections to EIP2315. That's… that's why it's there. And… the, the objection to needing two interpreters is why it's optional. I don't think… I don't think the core devs can force this sort of change, Onto the rest of the community. But neither can we… neither can we wait for the community to resolve the chicken and egg problem for us. They're looking to us to fix it.

Ansgar Dietrichs: Sounds good. Then maybe a question in terms of for asynchronous follow-ups, questions client teams might have, what's the best Venue to discuss? these topics. Sorry, that was… that would be a question for you, Greg?

Greg Colvin: Oh. I brought that up. I will… The magician's threads are there, and they're the primary, our primary place to put things, because that's a record, that lives on. I'd like to schedule a breakout call sometime in the next couple weeks, and schedule a longer period of time in 2 weeks, if that's amenable to people. But I'm… I'm not clear on the deadlines as to when we need to get this through, to considered, before it's too late.

Ansgar Dietrichs: Yeah, so I can speak on that. I think for the Alcodev side, basically, we are now in the open proposal phase. We haven't yet set a deadline for this, because that depends a little bit on Us getting more certainty on the Glamsterdam timelines, which then, basically, then we, then we can, can, can aim for, for more concrete H-star. roll out and work backwards from when we need to close EAP proposals. So this will… likely still be open for a while. We will definitely give, I would say, A four-week, ahead warning, if, if, before the, before the proposal window is closed. Which also means that, so for now, we… We are trying to really not yet dive into individual EIP discussion.

on the calls themselves yet so much, more just having them proposed, and then people can go and reach out to the ERP authors and discuss in the various places. Eat Magicians is a good one. So I would, for now, I mean, we can also follow up on this on the scheduling side asynchronously, but I think for now, I would not want to, schedule synchronous time on this in two weeks yet, because.

Greg Colvin: Good.

Ansgar Dietrichs: That would be more for once the proposing window is closed, and then the discussion starts on which of the proposed ERPs to prioritize and consider, if that makes sense.

Greg Colvin: Yeah, got it, thanks. Then, then I won't hurry a whole lot on the breakout, but try and do it in the next, couple weeks. And again, please contact me, and especially, to try and resolve… resolve objections sooner rather than later. And, thanks. Thank you very much.

Ansgar Dietrichs: Sounds good, thank you. Then, given that we only have a few minutes left, I would move on to the… Last two small items that we have, not specific to H-star, but more miscellaneous. The first one is, I think a topic about, engine API performance and potential changes to improve performance for ZKVM use cases. I… don't quite know… how to pronounce the… the name? there, but I think we have the author there on the call.

Developer Uche: Yay, thank you.

Ansgar Dietrichs: Perfect.

Developer Uche: So, I want to have some AIDS eyes on this. Skishan API change introduction, so I dropped the… the link on chat. So it's more like an optimization to enable current head view time proving for ZKVMs. So, currently, zKVMs, of course, you need the assistant, The additional weakness to generate proofs? And, to do that, we have to, like, use the debug on escalation witness. Rp, the method, but it's… it takes, quite a long time to do that. On something like GET, it takes about 22 seconds to get the weakness ready, and without the weakness, we could start… we can't start on improved generation. So this, change is introducing a new… route to the engine API. It's a raw HTTP route, which does the same operation the new payload, the engine new payload does, but returns the…

The witness, the escortion witness alongside. The… the pilot, status investments. So, currently, it takes about 1.2 second-ish and, the eTrex, prototype paired with, Lighthouse. And, with… with that, we have, sufficient time to… Comments on the… The proof for that particular block's payload. on the ZK VM. So the goal is to have, some… you know, look into this, VM. some more details and, some more metrics on the PR, the PR details to see, what they think about it, and how How to go further with this. There's also a link to the eTrex prototype. And, some modern metrics. Yep, that's it.

Ansgar Dietrichs: Sounds good. Do we have, do we have clients that already looked at this, that have an opinion? Otherwise, anything for the call now?

Andrew Ashikhmin: I haven't looked into it, but just my initial impression is that ZKIVM is strategically important, and we should optimize for it, so maybe we can prototype this EIP in Erigon. Oh, yeah, we'll try to do that.

Ansgar Dietrichs: Heath?

Developer Uche: Yeah, colleagues.

Kevaundray Wedderburn: Yeah, just to provide some context, you can think of this change as the two… in two phases. The first one is switching out JSON RPC and using SSV plus HTTP. The second one is adding… The return of the execution witness when you do engine new payload. I think the first one… We have another movement for Julio and Barnabas, so that seems like there may be a smaller lift to initial rehab.

Ansgar Dietrichs: Hey, Gary?

Gary Schulte: Does, does SSZ play into the, you know, the perceived speed benefit of adding this to a non-standard engine API? I'm just wondering why specifically SSC.

Developer Uche: Yeah, yeah, yes it does. So, No, the normal serialization is JSON. Which is about 2x smaller than the output we get when we use, SSE. So the smaller the witness size, the… Faster the witnesses to transport.

Gary Schulte: Wouldn't… I mean, isn't the bulk of the witness RLP encoded currently? Does that JSON encoding really make that much of a difference?

Developer Uche: Yeah, it does, Presley.

Gary Schulte: it'd be interesting to see some metrics on that. I'm not opposed to SES, it's just, it's historically, there's been some pushback on getting that into the client, the RPCs, so it'd be great to see, like, And if I missed that, it's already on the thread somewhere, just to kind of see what the performance difference is between JSON, full SSC, and, you know. Yeah, just basically that. I don't know what level of JSON is, if every… if the bulk of the witness isn't RLP encoded, it would be very interesting to see size and speed differences between the two, just kind of side by side.

Developer Uche: Yeah, sure.

Dustin Brody: Another point there about JSON and SSE speed differences, they vary considerably between different clients, and I would caution a little bit about adopting the worst-case JSON decoding times as a reason to use… and I say this as somebody who would want for the ELs to use. SSE, but to immediately switch over to especially a random, like, one-off SSE, method, is that, if I recall correctly from Julio's, posted benchmarks, in general, not about this. but for Engine API. They were… it was Geth and Erigon, I believe, were the relatively slow ones. And one answer's there to fix Geth and Erigon's JSON parsers. Try that first, and then see what's left.

jonny (geth): I can speak to Geth, the issue is with… The issue is… is with the JSON marshalling and… and go. And there's actually a PR open in Geth that, like, speeds it up by 10x, so it's certainly, a fixable issue in Geth. Then it's, it's pretty comparable, to SSC and RLP once this fix lands. I can post the PR… I can… I'll link to the PR.

Dustin Brody: Sure, I'm curious.

Barnabas Busa: One more, thing that the marshalling and unmarshalling is also an issue on the CL side, if you keep it in JSON. So this is not just an issue on the ES side. And, Yeah, as we increase the blob camp, it's gonna be a bigger issue, and we're gonna be going back and forth, basically, in JSON, martialit, unmercialit on both sides, and then… Just gonna keep adding time to it. But yeah, it's… yeah.

Ben Adams: One of the… one of the issues with the JSON RPC currently, rather than having a REST path in the URL, It means we have to parse the JSON work out. what it is. Because the… the methods in the… in the JSON. So we have to use, like, a completely generic parser, rather than going oh, it's… it's calling ETH this, therefore I can use this optimized parser that only Needs to worry about those… those fields. So, having, having a rest where it's telling you in the, in the path. What you should be expecting as data. Yeah. Opens up optimization opportunities.

Ansgar Dietrichs: We are at slightly above time already, even. This seems like, in general, like, a topic that But obviously… is important. Any… does anyone have thoughts on, like, how to best continue this discussion beyond this call?

Kevaundray Wedderburn: I think we can check the redesign that Felix mentioned on the channel to see how… how that's going. And to see if this can just be a subset of that. Oh, Nevermind is doing a redesign. Yeah, we can sync up with Nevermind to see M… Like, how far that's going, and whether this can be a subset of that. at least the first stage, because Disturb also proposed to add a new method. That Rattel Dortens.

Ansgar Dietrichs: Sounds good. Then probably put stopping point for now. We had one more agenda item, I don't… I think we don't really have time to go into the details. Yeah, I would, by default, just bump it to next call, if you want to give a, like, 10-second shout-out of just… for people to maybe already have a look. Now could be still the time, but…

Mercy Boma Naps-Nkari: Yeah, so we just want, call devs to look at the peers, and if they have comments or reservation around it, it would be good to find that out so we can measure it. It's just, two new methods we want to add.

Ansgar Dietrichs: Sounds good. I think one of them is… ETH cap… capabilities, and the other one is, an… Something engine got bops before.

Mercy Boma Naps-Nkari: Yeah.

Ansgar Dietrichs: Okay, yeah, sounds good. If necessary, we can have some more time there next call. We also had one… Shh, comment from… Shabba in chat earlier, just to briefly mention it, about Discovery V5, There's… there's the comment in chat, so for people, maybe also go… Have a look there, Al. just copy and paste the… comment that Chabba had, just for… if anyone missed it. But I think otherwise, we have reached the end of the call today. Brussels, Felix, whoever's behind this account right now. Do you have one last comment on this, or…

Bosul Mun: Hi, Yeah, so I want to talk about the 774 PR on the… on execution APIs really big. This includes changes required for the first book pool. And since Paris Boku is a CFI'd, and some clients have I'll draft for Ed. And also, it is expected to reduce the bandwidth required for block propagation significantly. I would appreciate if other clients can take a look. into this PR and, get this merged to Glamster down, SPAC, and… It is also possible… no, it is not strictly required to implement entire possible pool to support those,

New engine APIs, so please take a look and, I, I would appreciate your feedback. Thank you.

Ansgar Dietrichs: And that… and just to confirm, that's the PR774? Is that… is that the one?

Bosul Mun: Yes.

Ansgar Dietrichs: Perfect. I put the link in chat one more time, Mercy had already put it, but just so people… Don't get confused. Perfect. Then, that's all for today. Thank you all for bearing with us for the extra 7 minutes, and Talk to you all, in two weeks. Yeah, bye everyone.

Barnabas Busa: Bye-bye.

Marius van der Wijden: Bye-bye.

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