Ansgar Dietrichs:Perfect. Hello, everyone. Welcome to… All Core Devs, episode 235, I'll put the…
Transcript
Ansgar Dietrichs:Link to the agenda in chat.
Ansgar Dietrichs:Mmm…
Ansgar Dietrichs:And, yeah, we have quite a few agenda items today. Before we get started, though, one quick note in terms of
Ansgar Dietrichs: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.
Ansgar Dietrichs:And we wanted to announce today that Nixo will, join me as co-lead of, All Core Devs going forward, so…
Ansgar Dietrichs:A very warm welcome to Nixu in that role.
Ansgar Dietrichs:Yeah, I think this is going to be great.
Ansgar Dietrichs:Mmm…
Ansgar Dietrichs: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.
Mario Vega: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.
Mario Vega:Just to get,
Mario Vega:A notion of how, is everyone doing regarding this release?
Mario Vega:I think first question is, where… was everyone able to consume the tests in the latest release of EALTS tests?
Mario Vega:Yeah, I guess.
Ben Adams:Rift.
Ben Adams:Yes, from Nethermind.
Mario Vega:What issues, is there any issues that you have found, number of failure cases, or…
Mario Vega: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,
Mario Vega:Do we have anyone from Besu, read?
Daniel Lehrner (Besu):On, on Besu side, no, no issues.
Daniel Lehrner (Besu):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.
Dragan Rakita: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.
Ansgar Dietrichs:So, yeah. Otherwise, first, any other DevNet-related, updates or anything to discuss?
Barnabas:I could maybe quickly discuss the progress, with the Merge DevNet, so Glamsterdam DevNet Zero. We have been working with Prism and Geth,
Barnabas:to get some initial, DevNets running, and
Barnabas:It's still a work in progress. Hopefully, tomorrow is the day when we get up and running.
Barnabas:But it's almost there.
Ansgar Dietrichs:That's very exciting, that's a…
Barnabas:Yeah, all of our tooling is updated to Alpha 5 now, and
Barnabas:Yeah, we have the spec sheet with the current images that we can use, that you can use locally as well.
Barnabas: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:Yeah, so this is just general to keep track of it,
Barnabas:hopefully, based on the decisions that we make today, we can basically, finish up the, spec discussion for DevNet Zero, and then,
Barnabas: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.
Stefan Starflinger:We have a gas limit of $60 million that I've increased to $100 million to correspond to, the…
Stefan Starflinger:set value that we have for 8037.
Stefan Starflinger: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.
Stefan Starflinger:Which we can then merge.
Stefan Starflinger:But yeah, there's more topics on that.
Stefan Starflinger:And we talked to Odia about it.
Ansgar Dietrichs:Sounds good.
Ansgar Dietrichs: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…
Ansgar Dietrichs:Physically, to alternatives. They were… the… the PRs were by, Mikael, but I think, Stefan, you…
Ansgar Dietrichs: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…
Ansgar Dietrichs:Yeah, it's chosen?
Stefan Starflinger:It would be great, to have them implemented for Belle DevNet 4.
Stefan Starflinger: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.
Stefan Starflinger:And I think there's been quite a lot of work on it,
Stefan Starflinger: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.
Ansgar Dietrichs:Fortis, would you be ready to briefly talk about the… Engine API updates.
Potuz:Wait, sorry, I was just switching from phone to…
Potuz: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.
Potuz:The issue is, we need to reorg back.
Potuz: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.
Potuz:Because the payload content is different.
Potuz:So these two EIPs address the same thing.
Potuz:And there's a difference in subtleties, on what is the depth of the reorg that is allowed. One EIP allows… so…
Potuz:forces the clients to support up to 32 blocks height of a reorg.
Potuz:Which is more than what we expect to ever need. I think we would never reorg.
Potuz:More than, just one slot, unless there's a very heavily staked attacker.
Potuz:Or a bug.
Potuz: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.
Potuz: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.
Potuz: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.
Potuz:So, this is mostly on the EL side, on what's their flavor of what they… they… they prefer?
Potuz: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
Potuz:Support up to 32, the other one…
Potuz: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: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.
Potuz:the… it's not a breaking change on the… on the… on the AP… on the API.
Potuz: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.
Potuz: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.
Marius van der Wijden:786 is… The more principled solution, 770, is the easier solution to implement for us.
Marius van der Wijden:Both are okay,
Marius van der Wijden:I think the, the big, the big difference will be in, in, in, in testing, One… yeah.
Marius van der Wijden: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…
Ansgar Dietrichs: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…
Łukasz Rozmej: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.
Łukasz Rozmej:For example, might be even.
Łukasz Rozmej:Make more sense than 32.
Łukasz Rozmej: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?
Ansgar Dietrichs:Okay, the panel, just to double-check, the cap one is 770, right? Can we confirm this?
Ansgar Dietrichs: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
Toni Wahrstätter:situations where we could hit it, like, at least in theory, and I think POTUS is right, that we would just stall.
Toni Wahrstätter: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.
Toni Wahrstätter:Just to make sure that we don't fall back into snap sync in such a situation.
Toni Wahrstätter: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…
Toni Wahrstätter:live with the fact that ELs might not be able to attest to blocks after such big rewards.
Toni Wahrstätter: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.
Marius van der Wijden:We can just go.
Toni Wahrstätter:Okay.
Marius van der Wijden:that other block.
Marius van der Wijden:So the, the, the, the thing is, We…
Marius van der Wijden:What we are changing here is whether we can reorg to a previously canonical block.
Marius van der Wijden:And also, the thing that Peritosh is saying is wrong, because canonical in that sense, means
Marius van der Wijden:the… the block that we have currently as head. So, we…
Marius van der Wijden:Right now, we cannot reorg to an ancestor of our current head.
Marius van der Wijden:And this changes it, so we can… can reorg to ancestors of our current head.
Marius van der Wijden: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.
Marius van der Wijden:That has some descendant that is in… within our…
Marius van der Wijden:current chain, but it's not on our current chain itself. So, we will happily reorg over there.
Marius van der Wijden:And that means undoing some blocks, and then redoing some blocks, and then arriving at the… at the… at this, con…
Marius van der Wijden:A competing chain.
Toni Wahrstätter:I see, okay, this explains it. So the question would then be, can all clients
Toni Wahrstätter: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,
Potuz:But, again, I think people are missing something, which is the fact that this reorg is not going to be triggered network-wide.
Potuz:It'll only be triggered by the next proposer that is trying to propose a block based on a previous payload.
Potuz:everyone else in the chain will not trigger such a reorg, because it will not send an FCU with, payload attributes.
Potuz:So this is just simply let the next proposer trigger block production for a previous… based on a previous head.
Potuz: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.
Potuz: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.
Potuz: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
Toni Wahrstätter: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.
Potuz: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.
Potuz: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.
Potuz: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.
Marius van der Wijden:We only have the 128th
Marius van der Wijden: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.
Marius van der Wijden: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.
Marius van der Wijden:Until we get to a… to the point where we are being re-oped to.
Marius van der Wijden:What we cannot do is reorg to something that is
Marius van der Wijden:longer than these 90,000 blocks. And these 90,000 blocks are chosen because it gives us 2 weeks of
Marius van der Wijden:Non-finality.
Toni Wahrstätter:Right, but this isn't a critical path now, so…
Toni Wahrstätter: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.
Ansgar Dietrichs:I would personally feel like that it would feel a little problematic to take the cap
Ansgar Dietrichs: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
Ansgar Dietrichs: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.
Ansgar Dietrichs:The finality-based one, which seems like the proper solution.
Ansgar Dietrichs:yeah, I don't know, do people want to take this offline, or do we just want to have it to go with the,
Ansgar Dietrichs: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…
Marius van der Wijden:At this point, we have no…
Marius van der Wijden: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
Marius van der Wijden: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…
Marius van der Wijden: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…
Ansgar Dietrichs:What's the situation from death's side?
Marius van der Wijden:Yeah, we can, we can, we can do it.
Marius van der Wijden: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
Marius van der Wijden: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.
Dragan Rakita:And after that, decide on the limit.
Dragan Rakita: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.
Bosul Mun: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…
Ansgar Dietrichs:Personally, I feel like it might just be best to basically just, like.
Ansgar Dietrichs:block… go with 786, but just to revisit, I think we have some…
Ansgar Dietrichs: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.
Ansgar Dietrichs: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.
Mario Vega: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.
Marius van der Wijden:reox when, within the current head.
Marius van der Wijden:And not… and not… Even specify the behavior for… for…
Marius van der Wijden:what happens with reorgs that are longer than one block?
Marius van der Wijden:Or longer than 32 blocks, or longer than 128.
Marius van der Wijden:So this would be a way of… Going around this.
Ansgar Dietrichs:So then, what, what is the implied for the decision today?
Ansgar Dietrichs:Do we just… Is it okay if we just… Say…
Ansgar Dietrichs:786 is our candidate, and then if they're… if they are…
Ansgar Dietrichs:Lasting concerns, we can revisit, but we log in 786 for now?
Ansgar Dietrichs:Anyone… Opposed to that?
Ansgar Dietrichs:Okay.
Ansgar Dietrichs:then let's do that. So, 786… 78… sorry, sorry, did I confuse the numbers? I think it's 786, yeah, 786…
Barnabas:How hard is it?
Marius van der Wijden:Sorry.
Ansgar Dietrichs:No worries. 786 it is, and yeah.
Ansgar Dietrichs:And we can continue the discussion there async, if there's anything we have to discuss. Okay, awesome. Decision made.
Ansgar Dietrichs: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…
Ansgar Dietrichs: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…
Ansgar Dietrichs: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.
Potuz:It is a very minor change, I think so, and and it'll make syncing, especially on non-finality, much, much faster and safer.
Potuz: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.
Potuz:The reason is that, up to now, we sync blocks
Potuz: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.
Potuz:the Seattle side is on a very…
Potuz:Far away head several days ago, and you still want to not
Potuz:You want to follow the chain. You want to download all blocks and follow the chain.
Potuz:Currently, we download everything. We download the blocks that already contain the payload for the execution site.
Potuz:Some clients even download this twice.
Potuz: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.
Potuz:Some clients don't even send the payload to the execution layer, they validate the block hash themselves.
Potuz:And then they let the execution layer sync on their own, which means downloading the payload yet again.
Potuz: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.
Potuz: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,
Potuz:Some examples are withdrawals. We need to make sure that the withdrawals that are,
Potuz: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.
Potuz:But if we are not validating the block hash, then we need to have some way of making sure that
Potuz: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
Potuz: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.
Potuz: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.
Potuz: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.
Potuz: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.
Potuz:And it would allow us to, like, remove
Potuz:All of the syncing by range on payloads, for example.
Ansgar Dietrichs:Sounds good, thank you for that context. Have EL…
Ansgar Dietrichs:The client teams already had time to have a look at this?
Ansgar Dietrichs:Okay, Panos, thank you for the context. Sorry, I wasn't aware of that.
Ansgar Dietrichs:Okay, so then I assume people are aware.
Ansgar Dietrichs:I think the main question for today, then, would be, is there a reason to…
Ansgar Dietrichs:is it worth considering adding this, to Glamsterdam, yet, or just basically have it wait in line for H-star?
Ansgar Dietrichs:Obviously, the threshold for adding ERPs after the
Ansgar Dietrichs:The window… the proposal window has been closed, should be high.
Ansgar Dietrichs:So yeah, I'd be… I don't have the context on this, I would be curious if people have opinions on…
Ansgar Dietrichs: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…
Marius van der Wijden:On being given the payload from the…
Marius van der Wijden: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…
Toni Wahrstätter:new payload in the engine API.
Potuz:New payloads shouldn't change.
Potuz:If we add it to the payload.
Toni Wahrstätter:Right, same thing. Right, right.
Toni Wahrstätter: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.
Ansgar Dietrichs: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…
Ansgar Dietrichs:we just, by default, add it to the, the list of, of PFI, HSA EIPs.
Ansgar Dietrichs:For now, and…
Ansgar Dietrichs:Yeah, and so make sure, context by Barnabas in the chat as well.
Ansgar Dietrichs:Sounds good.
Ansgar Dietrichs: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.
Potuz:And then have our clients, like, trying to be pointed to an unfinaled checkpoint, and try to sync from there.
Potuz: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.
Potuz: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.
Ansgar Dietrichs:Awesome. Then, I think that's all for now, then, on this EAP.
Ansgar Dietrichs:then you're sorry for misplacing it in the Glamsterdam section. Next up, then, on, Glamsterdam, the last main item is…
Ansgar Dietrichs: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
Mario Vega: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.
Mario Vega:And basically, I mean.
Mario Vega: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.
Mario Vega: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.
Mario Vega: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
Mario Vega:Concerning, because, while, I mean, it's a simple, perhaps, couple of changes per test.
Mario Vega: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.
Mario Vega: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,
Mario Vega:with, with contracts, etc. So I think it is worth highlighting that this is breaking an unusual amount of… of tests.
Mario Vega:The…
Mario Vega: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
Mario Vega: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.
Mario Vega:This is very hard to do now, because now we have the reservoir interactions happening.
Mario Vega: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.
Mario Vega: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.
Mario Vega: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
Mario Vega:To, to, to achieve the full, the full coverage that we want to with this, with the CIP.
Mario Vega:And I think lastly, the things that we still have to resolve, and, some, members of the other teams can, can, can,
Mario Vega: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.
Mario Vega:And this is now directly related to how, the estate, opcodes are charged to the… for the transactions.
Mario Vega: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.
Mario Vega: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.
Mario Vega:For us to ask for a simplified version of the EIP, or is it too late in the process?
Mario Vega: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
Andrew Ashikhmin:to be very complicated, so on… probably on par with, with the headliner blog access lists. So, I think…
Andrew Ashikhmin: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,
Andrew Ashikhmin:the… State gas limit.
Andrew Ashikhmin:to be derived, like, to… to be just hard-coded, like it is on Bell DevNet 3,
Andrew Ashikhmin:is fine. We can always, you know, like, make it dynamic later, and readjust it later, and maybe have a small
Andrew Ashikhmin:walk or whatnot, but I would… I would keep it simple.
Andrew Ashikhmin:But, you know, logically sound.
Ansgar Dietrichs:And Marius?
Marius Van Der Wijden (M):Yeah, so I think it makes no sense to have this,
Marius Van Der Wijden (M):8037 with fixed gas costs, because that really defeats the purpose of 8037.
Marius Van Der Wijden (M):What we…
Marius Van Der Wijden (M):What we would just instead do is pull it out and set a static gas cost for
Marius Van Der Wijden (M):how these, how, how state, well, how state-producing, operations cost. How much state-producing operations cost.
Marius Van Der Wijden (M):The problem with this is, we want to massively increase the gas limit with block access lists and the
Marius Van Der Wijden (M):to, 60 megas per second, we can, in theory, handle at least 300 megas per block.
Marius Van Der Wijden (M):So, if we set the… Cost?
Marius Van Der Wijden (M):as if we have 300MGAS, and we stay at 60 MHz, then all of the costs for users will 5X. So…
Marius Van Der Wijden (M):We can only really change the…
Marius Van Der Wijden (M):The gas, the gas, costs?
Marius Van Der Wijden (M):As long as we also change the gas limit in the same at the same time. So…
Marius Van Der Wijden (M):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
Marius Van Der Wijden (M):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?
Maria Silva:Yes. So I… I think I would advise, I guess, pulling it out, so I think… so…
Maria Silva: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
Maria Silva:Maybe trying to guesstimate the… Better, in hindsight, what the…
Maria Silva:average gas limit will be between Glamsterdam and Eguta?
Maria Silva:Because on EGOTA, we could update this again, if we go with the… with the fixed,
Maria Silva:cost per bite. I agree with Marius that having the dynamic one is nicer because it gives us more flexibility.
Maria Silva:On the… on how we increase the… the block limit.
Maria Silva:Another kind of, like, middle ground would be some sort of, like.
Maria Silva:preset, schedule, where we say we will go through these gas increases between Amsterdam and Agata, and try to have
Maria Silva:either… A middle ground, anchor that
Maria Silva: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.
Maria Silva:I just think any of these options are better than not doing 8037 at all, because that means we cannot
Maria Silva:Increased, the block limits.
Ansgar Dietrichs:Yeah, maybe, just, before I get back to, Andrew, from my side, I would just say that,
Ansgar Dietrichs:Given that the…
Ansgar Dietrichs:theme of Glamstadam is mainly around scaling, and that without any changes to state gas, state creation cost,
Ansgar Dietrichs:We basically have this shared understanding that
Ansgar Dietrichs:there is no real headroom for scaling beyond, where we are at basically now already with the E70 changes.
Ansgar Dietrichs: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
Ansgar Dietrichs: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
Ansgar Dietrichs:we should just, going also into next week, and, and some of the work there, just…
Ansgar Dietrichs: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…
Ansgar Dietrichs: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.
Ansgar Dietrichs: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,
Andrew Ashikhmin: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…
Andrew Ashikhmin: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…
Anders Elowsson: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.
Anders Elowsson: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,
Anders Elowsson: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.
Ansgar Dietrichs: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.
Ansgar Dietrichs:I…
Maria Silva:I… I just have a quick question, just to make sure. So, how does this impact
Maria Silva:VolDevNet 4, so VolDevNet 4, we're still doing the dynamic cost, right? It's just the test coverage is not…
Maria Silva:as wide.
Maria Silva:Is, the case.
spencer:Maybe I can say something here. I think, I feel like we should stick with, Bell DevNet 4 as the current spec is.
spencer:And any other changes we can discuss next week and follow that up, either during next week or…
spencer:after, after next week.
spencer:We did add, I think.
spencer:Around 200 and… it was 208 unique tests following
spencer:From Belle Devin at 3 to Belle Devonet 4 specifically for 1837. So we did already add significant coverage, but,
spencer: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?
Ansgar Dietrichs:Anders?
Ansgar Dietrichs:Otherwise, Peter?
Peter Miller:Oh, hello,
Peter Miller: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.
Peter Miller: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
Peter Miller: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
Peter Miller:That much of a grasp on the final design.
Peter Miller: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.
Peter Miller: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…
Peter Miller: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.
Peter Miller:And so I just wanted to, like, get a feel for… Where people are, because…
Peter Miller: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.
Peter Miller: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…
Peter Miller:implement it, and, like, we'll fix it properly with the multimedical gas pricing. But the experience that we have
Peter Miller:seem to be having is that people are running into lots and lots of problems.
Peter Miller:And if we're gonna go through that much pain, we kind of want it to be for a permanent solution.
Peter Miller:Rather than, like, this transitional solution before we go to proper multi-dimensional state gas pricing in presumably, the next…
Marius Van Der Wijden (M):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.
Marius Van Der Wijden (M):The… the thing that's going to change is how these… how are these reservoirs
Marius Van Der Wijden (M):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,
Marius Van Der Wijden (M):Why, this is… For me, this is the first step to the fully multidimensional gas, spec.
Marius Van Der Wijden (M):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
Marius Van Der Wijden (M):are likely not inside the EVM either, right? Except maybe for state access, everything else, call data,
Marius Van Der Wijden (M):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…
Maria Silva: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.
Maria Silva:So, my understanding is that for testing, the complex part is the dynamic cost per bytes, okay?
Maria Silva: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.
Maria Silva:the feature of the multidimensional metering, as Marius was saying, is definitely not transitional. Like, we need to have that.
Maria Silva:To be able to better manage state, and then do…
Maria Silva: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?
Maria Silva: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.
Maria Silva:And that part would be… Or would be better implemented in a more long-term pricing.
Maria Silva: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.
Ansgar Dietrichs:It doesn't yet… Seem, like, in a place where we are comfortable… we are…
Ansgar Dietrichs:High conviction that it will remain in its current shape.
Ansgar Dietrichs:Okay, perfect.
Ansgar Dietrichs:Then I think we can go to the next agenda point for now.
Ansgar Dietrichs: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.
Ansgar Dietrichs:And then we can move on to the, HEGOTA-related items. We have two EIP proposals there.
Ansgar Dietrichs:For PFI, the first one is, EIP8163.
Ansgar Dietrichs:And that was… proposed…
Ansgar Dietrichs: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.
Piotr: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.
Piotr: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.
Piotr:And without risking, becoming incompatible.
Piotr:because of the conflict, using conflicting opcodes, right?
Piotr:And, if new features prove to be successful outside Ethereum, the idea is that they could be ported back.
Piotr:And…
Piotr:Well, that is really basically it. I will post… paste the link to the EAP and Evemark a thread in the chat for details.
Piotr:Soon, and my first ask,
Piotr:is… are there any concerns with the proposal? Second, what would be the best way to formalize… to formalize such a commitment?
Piotr:Should I just go ahead and propose for inclusion in Agata? And if not, what other options are there?
Piotr: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…
Ansgar Dietrichs: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.
Ansgar Dietrichs: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.
Ansgar Dietrichs: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
Ansgar Dietrichs:approach to, to the, to this pre-compact topic.
Ansgar Dietrichs:But yeah, of course, the specifics of whether we actually…
Ansgar Dietrichs:ready to do so would then be part of the, H-star.
Ansgar Dietrichs:governance process, I would say.
Ansgar Dietrichs:yeah, any, any other clients?
Ansgar Dietrichs:Comments?
Ansgar Dietrichs:On this now?
Marius Van Der Wijden (M):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
Piotr:gone up.
Marius Van Der Wijden (M):shoreline.
Ansgar Dietrichs:Did you maybe DM?
Marius Van Der Wijden (M):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 (M):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…
Marius Van Der Wijden (M):Yeah.
Marius Van Der Wijden (M):Otherwise, I'm totally fine.
Piotr:Yeah, I mean, there isn't much,
Piotr:you know, logic behind the choice of the AE, I just… it just seemed, like, less… least obtrusive.
Piotr:Away from any parts of the range that is interesting further.
Piotr:But if there's, like, counter-proposals, then,
Piotr:Yep, I think, I encourage everyone to maybe leave them in the IFMAC thread.
Piotr:And… F range is… yeah, it is, it is pretty crowded.
Piotr:And sorry, Anskar, I didn't quite catch your suggestion about the, like, the governance process. Is it… is it…
Piotr: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.
Ansgar Dietrichs: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.
Ansgar Dietrichs:And then we have, Greg, who wanted to…
Ansgar Dietrichs:directly propose EAP7979, but also wanted to, I think, talk about
Ansgar Dietrichs: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.
Greg Colvin:Yeah, I wanted to put these in today, bring them up, and, you know, proposed them.
Greg Colvin: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…
Greg Colvin: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.
Greg Colvin:So…
Greg Colvin:It's a very simple proposal, so far as the interpreter goes. You can pretty much read,
Greg Colvin: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,
Greg Colvin: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.
Greg Colvin:So if you're only down to technical considerations, I don't think that's a very difficult discussion.
Greg Colvin: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
Greg Colvin:someone hasn't understood, and I don't blame anyone. This topic spans everything from
Greg Colvin:interpreter design, to, graph theory, and everything in between.
Greg Colvin:So… And then the third one…
Greg Colvin: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.
Greg Colvin:Split it this very simple proposal.
Greg Colvin:Can, get in first and pave the way, because this is pretty much the minimum that everyone's gonna need.
Greg Colvin: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.
Greg Colvin: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.
Ben Adams:Is this the preferred format?
Ben Adams:But you… Me too.
Ben Adams:At this stage.
Greg Colvin:Everything… Everything before EOF is basically dead.
Greg Colvin:Has been for a long time. Uf is still there.
Greg Colvin:So far as I know, it has no champions. So, it's on life support at best.
Greg Colvin:And, so this is… this is pretty much a resurrection and reworking of,
Greg Colvin:EIP2315 from long ago, attempting to answer all of the… all the criticisms there that I felt were legitimate, and
Greg Colvin:in the informational EIP, I just answer all the questions that came up there and through the years that seemed to need answering.
Greg Colvin:And there are, of course, discussion threads on the magicians, and
Greg Colvin:I would really like to hear there, or one-on-one, or on the breakout.
Greg Colvin: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.
Greg Colvin: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 (M):Yeah, I can speak a bit on that, because I was pretty opposed to the first one.
Marius Van Der Wijden (M):And that was okay with, with the EOF, but…
Marius Van Der Wijden (M):What changed for me there was…
Marius Van Der Wijden (M):was definitely Solidity putting their weight behind it. I think that there was the…
Marius Van Der Wijden (M):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…
Marius Van Der Wijden (M):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…
Marius Van Der Wijden (M):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
Greg Colvin:whims of the core devs.
Greg Colvin:that essentially they were not even going to examine it, until it was actually on the chain.
Greg Colvin:And there's been even more rug pulls since.
Greg Colvin: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,
Greg Colvin: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.
Greg Colvin:So this is just such a very simple thing.
Greg Colvin:The mechanism has been the underlying mechanism for every proposal so far, and many VMs over the years.
Greg Colvin: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.
Greg Colvin:Yo.
Greg Colvin: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.
Greg Colvin:You know, I'll do what I can, but there really is a limit there.
Greg Colvin: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.
Ben Adams:one of the issues is with just pure random jumps everywhere. Essentially, an EVM contract works as, like, a…
Ben Adams:a 30 kilobyte… Single function.
Ben Adams:And that becomes…
Ben Adams:next to impossible for a compiler to optimize. It can… it can create the machine code, but it can't…
Ben Adams:The… because of the complexity.
Ben Adams:Can be essentially infinite with, how the Everything jumps around.
Ben Adams:It just sort of bails on trying to optimize. Yeah.
Ben Adams:So, it would be good to have some enforced structure.
Ben Adams:To… to smart contracts.
Ben Adams:And that, that will probably also…
Ben Adams:or what Guillaume was talking about in terms of chunking.
Ben Adams:Having that structure will fit more, better with… with code chunking.
Ben Adams:Rather than, you know, you jump from
Ben Adams:Jump completely all around the contract, it's just all go-to's.
Ben Adams: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.
Greg Colvin: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,
Greg Colvin:is optional, and happens at create time, so before the interpreter runs.
Greg Colvin: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,
Greg Colvin: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,
Greg Colvin: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.
Greg Colvin:Well, not having validation was one of the strong objections to EIP2315.
Greg Colvin:That's… that's why it's there.
Greg Colvin:And… the, the objection to needing two interpreters is why it's optional.
Greg Colvin:I don't think… I don't think the core devs can force this sort of change,
Greg Colvin:Onto the rest of the community.
Greg Colvin:But neither can we… neither can we wait for the community to resolve the chicken and egg problem for us.
Greg Colvin: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
Ansgar Dietrichs:Venue to discuss?
Ansgar Dietrichs:these topics.
Ansgar Dietrichs:Sorry, that was… that would be a question for you, Greg?
Greg Colvin:Oh.
Greg Colvin:I brought that up. I will…
Greg Colvin: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.
Greg Colvin: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.
Greg Colvin: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
Ansgar Dietrichs: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.
Ansgar Dietrichs:roll out and work backwards from when we need to close EAP proposals. So this will…
Ansgar Dietrichs:likely still be open for a while. We will definitely give, I would say,
Ansgar Dietrichs:A four-week, ahead warning, if, if, before the, before the proposal window is closed.
Ansgar Dietrichs:Which also means that, so for now, we…
Ansgar Dietrichs:We are trying to really not yet dive into individual EIP discussion.
Ansgar Dietrichs: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.
Ansgar Dietrichs: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…
Greg Colvin:resolve objections sooner rather than later.
Greg Colvin: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…
Ansgar Dietrichs:Last two small items that we have, not specific to H-star, but more miscellaneous.
Ansgar Dietrichs:The first one is, I think a topic about, engine API performance and potential changes to improve performance for ZKVM use cases.
Ansgar Dietrichs:I… don't quite know… how to pronounce the… the name?
Ansgar Dietrichs: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.
Developer Uche:Skishan API change introduction, so I dropped the…
Developer Uche:the link on chat. So it's more like an optimization to enable
Developer Uche:current head view time proving for ZKVMs.
Developer Uche:So, currently, zKVMs, of course, you need the assistant,
Developer Uche:The additional weakness to generate proofs?
Developer Uche:And, to do that, we have to, like, use the debug on escalation witness.
Developer Uche:Rp, the method, but it's…
Developer Uche: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…
Developer Uche: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…
Developer Uche:The witness, the escortion witness alongside.
Developer Uche:The… the pilot, status investments.
Developer Uche:So, currently, it takes about 1.2 second-ish and, the eTrex, prototype paired with, Lighthouse.
Developer Uche:And, with… with that, we have, sufficient time to… Comments on the…
Developer Uche:The proof for that particular block's payload.
Developer Uche:on the ZK VM. So the goal is to have, some… you know, look into this, VM.
Developer Uche:some more details and, some more metrics on the PR,
Developer Uche:the PR details to see, what they think about it, and how
Developer Uche:How to go further with this.
Developer Uche:There's also a link to the eTrex prototype.
Developer Uche:And, some modern metrics.
Developer Uche: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.
Andrew Ashikhmin: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.
kevaundray wedderburn:The second one is adding…
kevaundray wedderburn:The return of the execution witness when you do engine new payload.
kevaundray wedderburn:I think the first one…
kevaundray wedderburn: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?
Gary Schulte:I'm just wondering why specifically SSC.
Developer Uche:Yeah, yeah, yes it does. So,
Developer Uche:No, the normal serialization is JSON.
Developer Uche:Which is about 2x smaller than the output we get when we use, SSE. So the smaller the witness size, the…
Developer Uche: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,
Gary Schulte: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.
Gary Schulte:Yeah, just basically that.
Gary Schulte: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: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
Dustin:want for the ELs to use.
Dustin: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.
Dustin: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.
Dustin:Try that first, and then see what's left.
jonny (geth):I can speak to Geth, the issue is with…
jonny (geth):The issue is… is with the JSON marshalling and…
jonny (geth):and go. And there's actually a PR open in Geth that, like, speeds it up by 10x, so it's certainly,
jonny (geth):a fixable issue in Geth.
jonny (geth):Then it's, it's pretty comparable, to SSC and RLP once this fix lands.
jonny (geth):I can post the PR… I can… I'll link to the PR.
Dustin:Sure, I'm curious.
Barnabas: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,
Barnabas: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…
Barnabas:Just gonna keep adding time to it.
Barnabas: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,
Ben Adams:It means we have to parse the JSON work out.
Ben Adams:what it is.
Ben Adams:Because the… the methods in the… in the JSON.
Ben Adams:So we have to use, like, a completely generic parser, rather than going
Ben Adams:oh, it's… it's calling ETH this, therefore I can use this optimized parser that only
Ben Adams:Needs to worry about those… those fields.
Ben Adams:So, having, having a rest where it's telling you in the, in the path.
Ben Adams:What you should be expecting as data.
Ben Adams:Yeah.
Ben Adams:Opens up optimization opportunities.
Ansgar Dietrichs:We are at slightly above time already, even. This seems like, in general, like, a topic that
Ansgar Dietrichs:But obviously… is important.
Ansgar Dietrichs: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…
kevaundray wedderburn:how that's going.
kevaundray wedderburn:And to see if this can just be a subset of that.
kevaundray wedderburn:Oh, Nevermind is doing a redesign. Yeah, we can sync up with Nevermind to see M…
kevaundray wedderburn:Like, how far that's going, and whether this can be a subset of that.
kevaundray wedderburn:at least the first stage, because Disturb also proposed to add a new method.
kevaundray wedderburn:That Rattel Dortens.
Ansgar Dietrichs:Sounds good. Then probably put stopping point for now.
Ansgar Dietrichs: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.
Ansgar Dietrichs:I think one of them is…
Ansgar Dietrichs: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…
Ansgar Dietrichs:Shh,
Ansgar Dietrichs:comment from… Shabba in chat earlier, just to briefly mention it, about Discovery V5,
Ansgar Dietrichs:There's… there's the comment in chat, so for people, maybe also go… Have a look there, Al.
Ansgar Dietrichs:just copy and paste the…
Ansgar Dietrichs:comment that Chabba had, just for… if anyone missed it.
Ansgar Dietrichs: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,
Bosul Mun: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.
Bosul Mun:And since Paris Boku is a CFI'd, and some clients have I'll draft for Ed.
Bosul Mun:And also, it is expected to reduce the bandwidth required for block propagation significantly. I would appreciate if other clients can take a look.
Bosul Mun:into this PR and, get this merged to Glamster down, SPAC, and…
Bosul Mun:It is also possible… no, it is not strictly required to implement entire possible pool to support those,
Bosul Mun:New engine APIs, so please take a look and,
Bosul Mun:I, I would appreciate your feedback.
Bosul Mun: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.
Ansgar Dietrichs:I put the link in chat one more time, Mercy had already put it, but just so people…
Ansgar Dietrichs:Don't get confused.
Ansgar Dietrichs:Perfect. Then, that's all for today. Thank you all for bearing with us for the extra 7 minutes, and
Ansgar Dietrichs:Talk to you all, in two weeks. Yeah, bye everyone.
Barnabas:Bye-bye.
Marius Van Der Wijden (M):Bye-bye.
Chat Logs
00:03:14
Ansgar Dietrichs:https://github.com/ethereum/pm/issues/2015
00:03:16
nixo:episode 😂
00:03:51
Josh Davis:Hooray!!
00:03:55
Barnabas:Replying to "episode 😂"
its soap oepra
00:03:57
Pooja Ranjan:Congratulations, Nixo!
00:04:02
Parithosh Jayanthi:Congrats! <3
00:04:05
Christine Kim:lets goooo nixo!
00:04:09
David (dionysuz):gz 🍺
00:04:12
Tim Beiko:Congrats Nixo 🫡
00:04:29
Justin Florentine (Besu):Replying to "the vibes remain off"
it's a good question tbh. the enthusiasm is usually warranted, but lately... I promise it will always be sincere
00:04:32
Carson:Yaaay nixo!!
00:04:33
Mario Havel:lfg Nixo!
00:05:13
Łukasz Rozmej:I think we did
00:05:30
Daniel Lehrner (Besu):Besu: Yes, no issues
00:05:31
Barnabas:geth now has bal-devnet-4 branch
any other client has a branch prepared already?
00:05:55
FLCL:tomorrow
00:06:01
Daniel Lehrner (Besu):Replying to "geth now has bal-devnet-4 branch
any other client has a branch prepared already?"
We have one as well. But 1 PR still needs to be merged in
00:06:22
Marius van der Wijden:The new 7 changes did turn the implementation quite ugly for us
00:06:33
Iván | ethrex:No issues on the ethrex side
00:08:19
Barnabas:https://notes.ethereum.org/@ethpandaops/glamsterdam-devnet-0
00:09:51
Stefan Starflinger:bal-devnet-4 spec https://notes.ethereum.org/@ethpandaops/bal-devnet-4
00:10:53
Barnabas:https://github.com/ethereum/execution-apis/pull/786
or
https://github.com/ethereum/execution-apis/pull/770
00:11:15
Marius van der Wijden:Both are fine, I don't care either way
00:11:27
Barnabas:Replying to "https://github.com/e..."
could EL teams chime in which one would they prefer
00:11:47
Marius van der Wijden:Replying to "Both are fine, I d..."
786 is more principled, 770 is slightly easier to implement
00:11:58
Stefan Starflinger:https://github.com/ethereum/execution-apis/pull/770
or
https://github.com/ethereum/execution-apis/pull/786
00:14:51
Barnabas:its been in discussion for over a month. Would prefer to make a decision
00:15:15
Potuz:I prefer 786 because it is formally correct at least for consensus
00:15:40
Potuz:+1 for what Marius says, just ship whatever
00:15:48
Toni Wahrstätter:It feels like, in case there's no finalization for more than 128 blocks, then ELs should keep the state diff / state snapshot available to be able to do auch a deep reorg without falling-back to snap sync. I think Marek mentioned that option last time.
00:15:49
Potuz:flip a coin
00:16:42
Marius van der Wijden:128 is also good for us
00:16:57
Marius van der Wijden:going lower than 128 requires more work
00:16:57
Toni Wahrstätter:What happens if we hit that cap?
00:17:06
Potuz:we stall
00:17:22
Potuz:yeah cause no block can be acccepted
00:17:39
Potuz:ah that was a reply to Marius
00:18:19
Francesco Risitano:I believe reth already supports reorg up to finalised using config on the engine
00:19:28
prestwich:what does “reorg within the canonical chain” mean?
00:20:15
Potuz:Replying to "what does “reorg wit..."
the CL chain has more nuance about what's canonical than the EL, we can reorg to a previous hash of the chain as canonical, but the CL takes a different CL block for it
00:21:16
Marius van der Wijden:Replying to "what does “reorg ..."
Reorg within the chain that leads to our current head
00:21:22
Marius van der Wijden:Replying to "what does “reorg ..."
Thats our currently canonical chain
00:22:35
Tomás Arjovsky | Lambda | Ethrex:Is this really a reorg then or is it just building on top of a previous block in the canonical chain?
00:23:32
prestwich:Replying to "what does “reorg wit..."
you’re saying that we may maintain a header chain, but the contents may change?
00:24:18
Marius van der Wijden:Sounds like we should do the principled solution
00:24:40
Marius van der Wijden:@toni we have state for the last 90k blocks
00:26:08
Potuz:we've already wasted enough time on this, the cap of 32 is fine too, it doesn't matter, we will need a majority attacker to trigger this and we'd be already in trouble anyway
00:26:21
Potuz:we will never reorg more than 1 block
00:26:23
Potuz:ever never
00:26:47
jochem-brouwer (Fairphone):We can add this reorg scenario to benchmark scenarios. (In fact we should)
00:26:50
Barnabas:786 lets go
00:27:15
Toni Wahrstätter:Replying to "we've already wasted..."
...or a bug
00:27:36
Louis:Replying to "We can add this reor..."
Add in todo list
00:27:55
Toni Wahrstätter:Replying to "we've already wasted..."
Imo such a big attacker is less likely than a bug. At least empirically
00:28:16
Łukasz Rozmej:FCU->finalized_hash->block_number lookup -> keep one pointer to it
00:28:18
Potuz:just put the cap internally
00:28:26
FLCL:do we need finalized-1?
00:28:34
jochem-brouwer (Fairphone):Replying to "We can add this reor..."
Thanks 🙏
00:28:58
Potuz:let's just test depth 1 :) that's all that will happen ever
00:29:00
Barnabas:Replying to "786 lets go"
who removed my own ship? 😂
00:29:07
kevaundray wedderburn:I think we would need to make an assumption around how long we can have periods of non finality?
00:29:29
Tomás Arjovsky | Lambda | Ethrex:Replying to "let's just test dept..."
This is the only real epbs need, right? The rest is just making a good spec
00:29:45
Toni Wahrstätter:I'm fine with it but let's just be intentional that ELs would stall if such a scenario ever happens.
00:29:48
Potuz:Replying to "let's just test dept..."
yes unless there is a majority attacker on the validator set that wants to trigger this
00:29:51
Potuz:Replying to "let's just test dept..."
or a bug on clients
00:30:14
Marius van der Wijden:Replying to "I'm fine with it b..."
It wouldn't stall, it would just reject this
00:30:20
Yann Vonlanthen:Replying to "let's just test dept..."
Or asynchrony / network issue
00:30:32
Potuz:Replying to "let's just test dept..."
no that can't be the case for this
00:31:15
Potuz:Replying to "let's just test dept..."
because it would be pretty weird that the CL p2p is gossiping blocks+payloads and not attestations
00:31:29
Marius van der Wijden:768 and stop arguing
00:31:40
Potuz:Replying to "768 and stop arguing"
that's a new one?
00:31:40
Tomás Arjovsky | Lambda | Ethrex:Agree with 786
00:31:43
Potuz:Replying to "768 and stop arguing"
up to genesis
00:31:47
Barnabas:Replying to "768 and stop arguing"
786
00:31:49
nixo:no u right
00:32:39
Marius van der Wijden:Replying to "768 and stop argui..."
I'm not good with numbers
00:32:48
Bosul Mun:Felix(Geth): Is 786 in now ??
00:33:21
Barnabas:Replying to "Felix(Geth): Is 786 ..."
please close 770
00:33:39
Justin Florentine (Besu):is it useful to CL clients to give them our max reorg depth via a config api?
00:34:32
Ansgar Dietrichs:sorry for saying “emergency inclusion” - that’s obviously silly in this context, I just meant inclusion after the CFI window has been closed
00:36:41
Dustin:Replying to "is it useful to CL..."
for Nimbus CL not really. either it needs the reorg or no
00:36:41
Barnabas:This was brought up many times in earlier calls, its just got its own EIP now
00:36:53
Dustin:Replying to "is it useful to CL..."
it's going to follow whatever its fork choice requires
00:36:54
Potuz:again I do not really feel strongly about this, it's a good to have it EL devs think its easy
00:39:06
Barnabas:I think I might have misunderstand terence’s comment yesterday, thought it was high urgency for gloas
00:39:18
Potuz:all I'm asking is for EL devs to take a look at it cause it would really save **a lot** of bwidth and speed to sync clients
00:40:23
Marius van der Wijden:Why do we need the accumulator?
00:40:35
Enrico Del Fante (tbenr):Ye it would be very nice
00:40:40
Potuz:Replying to "Why do we need the a..."
because the attacker can lie what the withdrawals were
00:40:45
Toni Wahrstätter:Yeah it's def nice and should be done in hegota
00:40:51
Mario Vega:https://github.com/ethereum/pm/issues/2015#issuecomment-4305210461
00:40:52
Potuz:Replying to "Why do we need the a..."
the validators can be malicious and finalize an invalid block
00:42:24
Potuz:One last thing on 8237 (or against 8237 lol) it's absolutely fine to ship in Hegota cause there's very little tech debt, a couple of structure changes but the whole range requests can be deleted from clients and deprecated immediately as soon as the EIP is SFId, so no problem to include it later
00:43:02
Marius van der Wijden:Replying to "Why do we need the..."
Hmm I see
00:43:59
Marius van der Wijden:I have to run, I think we need 8037. Otherwise we can't really increase the gas limit
00:44:45
Marius van der Wijden:I agree that the complexity increased quite significantly
00:47:28
FLCL:So we agree to try to simplify? Want to try some ideas
00:47:42
Anders Elowsson:Adapting the price with the gas limit is a “nice-to-have” that increases the probability of setting an “appropriate gas price” (facilitating multidimensional metering with high throughput) at any given gas limit. However, it does not guarantee that an appropriate price is set, because the price will not adapt with actual demand anyway (as in the EIP-8075 proposal).
So the best way to understand the functionality of adapting the price with the gas limit is that it makes it more likely that we can set an appropriate gas price across a wider range of gas limits, but it never actually provides any guarantees that the price would be set correctly at any limit. The direct outcome is that a fixed price must be set such that there will be a higher probability that the price is a too high initially, and too low when closing in on the Hegota fork.
00:48:38
Peter Miller:STEEL has spent all day trying to simply 8037. We came up with approaches to attack all the problems, but the changes were so numerous it was basically a rewrite.
00:49:05
pk910:I've been preparing spamoor to work under the new eip 8037 gas model.
While doing so, we'Ve noticed that a lot of the deployments take significantly more gas,
pushing some of the existing contracts, especially related to Uniswap over the transaction gas limit of 16M.
So, implementing 8037 leads to the situation where existing big projects are likely no longer able to deploy their contracts on chain,
because the combination of increased state cost and the per tx gas limit leads to a effective reduction of the deployable contract size.
00:49:13
FLCL:do you have the list of all problems?
00:49:42
Dragan Rakita:This should be ~fixed~ slightly mitigated with 0 -> x -> 0 rule that is going in devnet4
00:50:11
Ansgar Dietrichs:@Marius Van Der Wijden (M) do you still have your hand up or again?
00:50:14
Marius Van Der Wijden (M):Replying to "I've been preparing ..."
Why? We remove the 16m gas limit, so they should be able to deploy
00:50:34
Barnabas:Replying to "I've been preparing ..."
wait we removed the 16m gas limit?
00:51:09
pk910:Replying to "I've been preparing ..."
yea, didn't know that we're removing the per-tx limit too.
00:51:26
Marius Van Der Wijden (M):Replying to "I've been preparing ..."
Only for regular gas
00:51:34
Peter Miller:Replying to "I've been preparing ..."
There is mechanism that exempts state gas from the cap
00:52:07
Guillaume:Replying to "Lets discuss on sval..."
good job sharing the secret location
00:52:15
Dragan Rakita:Replying to "I've been preparing ..."
Yeah, gas more than 16M can only be spend on state increase.
00:52:17
Stefan Starflinger:Replying to "Lets discuss on sval..."
Its in norway
00:52:41
Peter Miller:Replying to "STEEL has spent all ..."
I don't have a comprehensive list in writing on me atm, sorry. We will get summary out ASAP.
00:52:53
FLCL:defining cost via header accumulator of state additions? welcome total state difficulty 😄 (and no 2nd dimension)
00:55:12
Tomás Arjovsky | Lambda | Ethrex:I think the main issue here is not devnet-related. The concern about big contract txs hitting the limit is probably the issue I heard that I find concerning
00:57:54
Barnabas:Is the risk of a major bug in EIP-8037 really worth the benefit? Do we need that much scaling in the next fork right now, or can we ship a simple state-cost bump this fork and give 8037 another cycle for coverage? I'd rather we prioritize shipping EIPs that are well-scoped and well-tested than shipping something that even our testing team is finding “impossible” to cover.
00:58:05
DanielVF:I think EIP-8037 is fundamentally flawed - it's both far more complexity than the benifits that it actually brings, and is also the wrong path long term for dealing with charging for state growth.
00:58:20
Anders Elowsson:Here is the research post:
https://ethresear.ch/t/failure-modes-in-eip-8037-and-state-gas-scaling/23975
It discusses state-gas parameter only (SGPO) hard forks. There are various levels of complexity that it could be implemented at.
00:59:06
Stefan Starflinger:8037 is really not that bad. Splitting regular gas and state gas makes a lot of sense. I agree, that simplification of the EIP is always a win.
00:59:27
Dragan Rakita:Imo EIP-8037 is nice change and it unlocks bigger block, so it feels impactful to stay.
00:59:29
DanielVF:That part isn't that bad. It's the dynamic gas pricing
00:59:45
Dragan Rakita:dynamic gas pricing is strange
01:00:05
Stefan Starflinger:Replying to "8037 is really not t..."
More backwards compatability considerations in the EIP would be great.
01:00:56
Mario Vega:Replying to "dynamic gas pricing ..."
indeed
01:01:12
Stefan Starflinger:Replying to "dynamic gas pricing ..."
I agree
01:01:39
FLCL:if you have state cost increase you can increase tx limit proportionally
01:01:42
Mario Vega:Replying to "dynamic gas pricing ..."
We always have done costant gas number consumed by opcode and then price the gas in wei, this thing is making the gas number consumed variable
01:01:42
Barnabas:Just imagine how much headache we gonna give to Devs…
01:02:10
Stefan Starflinger:Replying to "Just imagine how muc..."
ibuprofen
01:02:33
Barnabas:Replying to "Just imagine how muc..."
ibuprofen for mascot
01:03:24
jochem-brouwer:aextension :D
01:04:43
Anders Elowsson:Note that SGPOs would allow more accurate pricing than the current EIP, and therefore quite possibly more scaling, because devs can adapt things to actually observed demand.
01:04:48
Piotr:EIP-8163 - https://eips.ethereum.org/EIPS/eip-8163
https://ethereum-magicians.org/t/eip-8163-reserve-extension-0xae-opcode/27756
* Reserve `EXTENSION (0xae)` for non-Ethereum L1 EVM use
* Equivalent to `INVALID (0xfe)` on Ethereum L1 EVM
* No implementation effort needed :tada:
01:05:02
Dragan Rakita:Replying to "dynamic gas pricing ..."
Yeah I know, I needed to propagate this variable everywhere so it is a new mechanism I needed to make
01:05:35
lightclient:the problem is that we need L2s to agree on how they will use the opcodes that are blocked off
01:06:01
DanielVF:Yes 0xae
01:06:11
jochem-brouwer:https://eips.ethereum.org/EIPS/eip-8163
01:07:00
Danno Ferrin:F range is oversubscribed, more proposed opcodes than space left.
01:07:23
Danno Ferrin:0xef may be better
01:07:49
jochem-brouwer:Antwoord verzenden naar "0xef may be better"
l2 contract cannot start with this byte if it implements the blockoff of 0xef at start of contract
01:08:21
jochem-brouwer:Antwoord verzenden naar "0xef may be better"
https://eips.ethereum.org/EIPS/eip-3541
01:08:25
Danno Ferrin:Replying to "0xef may be better"
Right, so start with jumpdest/ef-extansuon
01:08:33
jochem-brouwer:Antwoord verzenden naar "0xef may be better"
ah right yes that works
01:10:05
Ben Adams:https://eips.ethereum.org/EIPS/eip-7979
01:13:05
Piotr:Replying to "the problem is tha..."
The EIP-8163 sets some minimal constraints (mainly not breaking JUMPDEST analysis), and punts coordination on the actual extensions to be outside of EIP-8163 scope (suggests coordinating via EthMag to start with).
(also to be maybe more explicit - it's L2s as well, but alt L1s primarily)
01:13:37
Łukasz Rozmej:Replying to "https://eips.ethereu..."
Nethermind supports this EIP
01:14:32
Łukasz Rozmej:Replying to "https://eips.ethereu..."
but I agree we do need compiler confirmations
01:14:43
Felix (Geth):I have a technical question but cannot speak rn. What is the purpose of the validation phase of EIP-7979
01:15:15
Felix (Geth):would it be possible to add CALLSUB/RETURNSUB without this validation phase?
01:15:19
Dustin:that seems a misguided approach
01:15:48
Dustin:(not Felix's comment, the Vyper idea of not even looking)
01:16:35
Felix (Geth):I'm just curious because there is no rationale section about the existence of the validation
01:16:36
DanielVF:I've used VM's that work like this, and it worked well.
01:16:39
kevaundray wedderburn:Would be great if solidity/vyper could form an opinion on it — or else it may be implemented in a way that they in retrospect would not like
01:17:14
jochem-brouwer:Antwoord verzenden naar "Would be great if ..."
I'll forward to vyper
01:18:49
Csaba:Not in agenda, but adding a reminder here for EL devs to check the Discv5 tracker at https://notes.ethereum.org/IhGB-cc9S5WClyd9KBjAIA
Next steps:
Start running some of our devnets with Discv4 off
Pass Discv5 hive tests
Agree on date to change default Discv4 off
Turn Discv4 off
01:18:50
Felix (Geth):sorry can someone relay my question please
01:19:31
Felix (Geth):thanks for answering it Greg
01:19:39
Felix (Geth):but can we then remove the validation?
01:19:47
Felix (Geth):I still don't get it
01:20:22
Tomás Arjovsky | Lambda | Ethrex:Replying to "Not in agenda, but a..."
I’m pretty sure we support discv5 now, but I’ll ping you afterwards to see if there’s gaps
01:20:55
Tomás Arjovsky | Lambda | Ethrex:Replying to "Not in agenda, but a..."
We already support discv5 by default and pass the hive tests
01:22:08
marc | wolovim:#evm channel in R&D is where it has been referenced already
01:23:22
Csaba:Replying to "Not in agenda, but a..."
Yeah, that was my impression.Thanks
01:23:44
Csaba:Replying to "Not in agenda, but a..."
Also, I’m adding a new column to collect CLI flags to turn off discv4. Could be useful for devnets.
01:25:02
Developer Uche:https://github.com/ethereum/execution-apis/pull/773
01:27:29
Marius Van Der Wijden (M):I got kicked, what was the ask?
01:27:33
Felix (Geth):just a comment, newPayloadWithWitness is not a part of the standard engine API
01:27:44
Ansgar Dietrichs:Replying to "I got kicked, what w..."
https://github.com/ethereum/execution-apis/pull/773
whether any opinions
01:28:02
Felix (Geth):but this change is strange because it moves exactly one method to another API
01:28:14
Felix (Geth):(another 'transport' I mean)
01:28:27
Felix (Geth):we anyway want to migrate the engine API to another transport
01:28:38
Developer Uche:Replying to "(another 'transport'..."
Yeah
01:28:42
Felix (Geth):so it's a bit strange to only do one method
01:29:27
Marius Van Der Wijden (M):I also think we should rather rmove the whole engine api (and refactor it)
01:29:30
Łukasz Rozmej:this also plays well with adding SSZ to engine API -> Nethermind works on this
01:29:42
Barnabas:Replying to "I also think we shou..."
this is not reasonable within the timeframe tho
01:29:59
Tomás Arjovsky | Lambda | Ethrex:The PR linked has a good amount of metrics I think
01:30:01
Łukasz Rozmej:Replying to "I also think we shou..."
why?
01:30:03
Dustin:Why is this doing SSZ in a random ad hoc way
01:30:05
Dustin:please no
01:30:13
Francesco Risitano:Json represents bytes as hex so one char per nibble. This results in 2 x compared to something binary.
01:30:31
kevaundray wedderburn:To Felix, yeah we could add ssz to all engine api methods and then this proposal’s diff becomes adding a new engine api endpoint
01:30:45
Tomás Arjovsky | Lambda | Ethrex:I think this proposal is great to do a PoC about ssz for the engine api
01:31:13
Felix (Geth):Replying to "To Felix, yeah we ..."
my point is more that there is already work underway to redesign the engine API with a different method
01:31:15
Tomás Arjovsky | Lambda | Ethrex:Instead of going “we should do a full on rehaul of everythin first” doing an off-standard change for a single method to test it is a good approach
01:31:29
Tomás Arjovsky | Lambda | Ethrex:and based on how this goes we can also think about a full rehaul of all the engine api
01:31:44
Felix (Geth):Replying to "Instead of going ..."
the thing is, this is not proposed as "try it", it's proposed as a standard
01:31:47
kevaundray wedderburn:Replying to "To Felix, yeah we could add ssz to all engine api methods and then this proposal’s diff becomes adding a new engine api endpoint"
Isn’t this redesign using ssz too?
01:32:05
Tomás Arjovsky | Lambda | Ethrex:If anyone doesn’t like ssz (mind you, still very much used in consensus) it won’t harm to have counterproposals with measurements
01:32:08
jonny (geth):https://github.com/ethereum/go-ethereum/pull/33969
PR for speeding up json marshaling in geth
01:32:19
Potuz:wait I don't buy that JSON will ever be comparable to SSZ
01:32:28
Felix (Geth):we all agree that a binary format is preferable
01:32:30
Francesco Risitano:Json payload size is doubled by json so then transport becomes the overhead.
01:32:33
Potuz:that's impossible, we need to go RLP -> JSON-> SSZ on the engine
01:32:44
Potuz:this can never be comparable to RLP -> SSZ
01:33:40
Dustin:Replying to "wait I don't buy t..."
yeah, it's a question of priority. Using a 600ms JSON decode pessimized Geth decoder as reason for SSZ is odd
01:33:45
Dustin:Replying to "wait I don't buy t..."
I support SSZ
01:33:46
pk910:Replying to "https://github.com/e..."
uff, that's a interesting approach :D
basically unrolled the whole generic json parsing.
I guess you don't wanna do this for the whole engine api
01:33:52
Tomás Arjovsky | Lambda | Ethrex:Replying to "Instead of going “we..."
Well yeah, but how would you “try it” without it being spoken on acde first? I think bringing it here so client teams can implement PoCs is good manners
01:34:14
Felix (Geth):nethermind is doing that redesign
01:34:19
Tomás Arjovsky | Lambda | Ethrex:Replying to "Instead of going “we..."
This is not my proposal btw, I just like the idea of testing how it performs
01:34:33
Gary Schulte:which eth r&d discord channel to follow for this?
01:34:43
jochem-brouwer:Antwoord verzenden naar "Would be great if ..."
Have forwarded
01:34:58
Francesco Risitano:Replying to "which eth r&d discor..."
#l1-zkevm-protocol
01:34:58
Dustin:Replying to "and based on how t..."
The risk it ends up as random compatibility jank after that
01:35:08
Mercy Boma Naps-Nkari:https://github.com/ethereum/execution-apis/pull/755 https://github.com/ethereum/execution-apis/pull/774
01:35:30
jonny (geth):Replying to "https://github.com/e..."
It’s really only an issue for endpoints that could potentially have large payload sizes so I dont think it is necessary to do the whole engine api
01:36:18
Gary Schulte:Replying to "and based on how thi..."
right. the xkcd standards comic
01:36:22
Ansgar Dietrichs:Not in agenda, but adding a reminder here for EL devs to check the Discv5 tracker at https://notes.ethereum.org/IhGB-cc9S5WClyd9KBjAIA
Next steps:
Start running some of our devnets with Discv4 off
Pass Discv5 hive tests
Agree on date to change default Discv4 off
Turn Discv4 off
01:38:01
Ansgar Dietrichs:https://github.com/ethereum/execution-apis/pull/774
Summary
11 highlights
· 4 decisions · 3 action itemsExperimental
Summary
11 highlights · 4 decisions · 3 action itemsExperimentalorganizational
- Nixo joins as co-lead of All Core Devs alongside Ansgar00:03:14
fork status and schedule
testing progress
eip discussions
client updates
- Geth JSON marshalling 10x performance improvement PR available01:31:35