Ansgar Dietrichs:Awesome. Welcome, everyone, to…
Transcript
Ansgar Dietrichs:All core devs number 222. What a nice number. I am stepping in for… filling in for Tim today, who will be gone for the next few All-Codevs until the end of the year, and then he'll… he'll be back to… to take back over.
Ansgar Dietrichs:Yeah, we have,
Ansgar Dietrichs:I think in a, like, not too full agenda for today, just quite a few items, but they're all relatively minor, so let's just get started. So the first up will be a few Fusaka items.
Ansgar Dietrichs:The first of which is any definite updates. Do we have, any definite updates? Anyone here?
Parithosh Jayanthi:Yeah, so earlier today, we launched a Fusaka ShadowFock, sorry, a Seporia Shadow Fork, and so far, it's been, pretty…
Parithosh Jayanthi:uneventful, I guess. There… yeah, we've already gone through Fulu and BP01, and BP02 should be in, like, half an hour, and we don't seem to have any missed blocks or any problems.
Parithosh Jayanthi:We've only done a consolidation so far. We're gonna still do top-ups and exits to make sure that all of that looks good as well.
Parithosh Jayanthi:But while working on that, Barnabas found a few issues with, with the BPO schedule that he's also trying to, bring up on, ETH R&D, but I will let him continue with updates and, bring up that topic, I guess.
Barnabas:Yeah, so the general problem is that,
Barnabas:As we start, including the named forks in the blob schedule in the Genesis.json file, this will make the
Barnabas:this will make, basically, the generation of the Genesis file very, very complicated, due to the different, values, the BPO values can be set.
Barnabas:Because as soon as we start adding Amsterdam and Istanbul and Bangkok and whatever else future work we're gonna have, we're gonna need to have, logic for, using the latest BPO values that are currently used, and on top of that, add the,
Barnabas:the named, fork in there as well, even though that those named fork values will change no values whatsoever, because on the CL side, those named forks cannot, adjust the bloat values anymore.
Barnabas:So, they are basically redundant fields, and I'm proposing that we should probably get rid of the Osakov field, as well as Amsterdam, and all future forks as well.
Ansgar Dietrichs:Any comments on that point?
Marius van der Wijden:Yeah.
Marius van der Wijden:I…
Marius van der Wijden:I have argued against this, multiple times, because I think it's… it's much better to be very expressive.
Marius van der Wijden:With how the… how these configurations… like, it's better to be expressive about the configurations.
Marius van der Wijden:Than to, like, implicitly… Forced the…
Marius van der Wijden:users to know, okay, like, I don't know, now we have two…
Marius van der Wijden:Two named forks, but none of them have,
Marius van der Wijden:have any blob schedule, so I need to look 3 folks back to the last BPO to see what… what…
Marius van der Wijden:blob schedule to apply to the current fork, and that is one of the things, and the other thing is that we are limiting ourselves to never do
Marius van der Wijden:BPOs,
Marius van der Wijden:sorry, to never do, blob schedule updates, on, named Fox, and I think that is also something that…
Marius van der Wijden:I don't know. Like, we never really discussed this, and it's… It's… very…
Marius van der Wijden:It's very weird that, the,
Marius van der Wijden:that the CR teams have made that decision that they cannot do
Marius van der Wijden:blob schedule changes on named Fox anymore.
Barnabas:But they can. So, like, you could… you could have a block schedule change as well, but you would just basically schedule, Amsterdam, and you would schedule BP06 on to the same time slot on the ES side, and you would schedule on the same epoch on the CR side.
Barnabas:You would just not use the exact same name to schedule the, lobster schedule change.
Parithosh Jayanthi:So, maybe there's a bit… there's a bit of a diff that we need to explain. So, on the EL side, you're very explicit. I agree with you, Marius, you can look at one place where everything is scheduled, which is how it is today. But on the CL side, that's not the convention. So, in the CL, if there's a fork, and you don't append the value with the fork name, then you reuse the value from the previous fork.
Parithosh Jayanthi:So what would happen today is we would have a blob change with Pectra, and then you apply all the values for the BPO125,
Parithosh Jayanthi:And then…
Parithosh Jayanthi:it's sort of implicitly understood that Fulu has not changed the blobs, but if we decide to change it at the next fork, then
Parithosh Jayanthi:Glamsterdam would have a pending as well, so we've… it's somehow really weird in the CL logic to do it, and the easiest way to
Parithosh Jayanthi:sort of prevent that is to say we're only touching the blob schedule with BPOs.
Parithosh Jayanthi:And then it's consistent again.
Parithosh Jayanthi:And that way, it would be consistent on both sides.
Marius van der Wijden:Yeah, I don't like it, but it seems that I'm the only one arguing against it at this point, and…
Marius van der Wijden:It's not really a big change, so I guess we can just do it.
Parithosh Jayanthi:Also with, Dustin's point, even in the future, if we intend to change the blob parameters, we don't have to schedule it at the same epoch as a fork, we can just schedule it 10 epochs later.
Parithosh Jayanthi:If we want to.
Ansgar Dietrichs:And just as a clarification, sorry, I have no context on this, would this be something that we would then also already change now for the Fusaka rollout, or… or, like, going forward?
Marius van der Wijden:There's not really anything to be changed, right? It's just how the client, Interact with the…
Marius van der Wijden:With the… with the… with the config that they are given.
Barnabas:Whether you're expecting specific values in specific, fields or not.
Ansgar Dietrichs:Okay, and… but the config… the config for Fusaka itself wouldn't change? Or, like, the… sorry, okay, yeah.
Ansgar Dietrichs:I see. Okay, so then do we want to… like, it sounds like Marius is the… like,
Ansgar Dietrichs:was the only one? I mean, I saw Raul in the chat with some reservations as well, but do we just want to make a decision now, or is this something we want to keep discussing?
Raúl Kripalani:I would just like to point out, yeah, I misunderstood what Marius was saying. I agree with Panda… Panda Up's suggestion here, but I also wanted to bring up the fact that the EIP… that was the original intention, that the CL would list all
Raúl Kripalani:all blob parameter changes, regardless whether they belonged in a regular fork, a name fork, or a BPO fork, in the blob schedule, and it's actually… there's a statement in the EIP as well, it might have been overlooked, but… but yeah, I just posted it in the chat.
Parithosh Jayanthi:Also, this won't really relate to any changes that has to happen for Fusaka. This is just, at most, would affect, the block-level access list branches, which are DevNet branches anyway.
Ansgar Dietrichs:I see, makes sense. Yeah, sounds like the majority of you was to…
Ansgar Dietrichs:should then go with that, right? Of course, we can continue to discuss offline, given that there's no direct fault implications, but yeah.
Ansgar Dietrichs:Okay, then, I would move to the next point, which is the Holeshky status. Is there anything…
Ansgar Dietrichs:To report from that site?
Parithosh Jayanthi:Yeah, so the BP01 went live, I want to say 2 days ago, and I think there was, one…
Parithosh Jayanthi:a peer-to-peer thing on Lighthouse that's still being triaged, I guess, or already has a fix in a future release, where they were losing some peers around the BPO boundary. But other than that, I don't think there was anything to report.
Parithosh Jayanthi:Yeah, I would be interested to hear what the client team's monitoring has said, though.
Ansgar Dietrichs:Anyone here that can speak to that?
Dustin:Sure, I can describe, so…
Dustin:essentially, we've run into… we, Nimbus, have run into…
Dustin:some resource issues on, WoCore machines. It happens to be that the way… and this didn't show up on both
Dustin:Fusaka, DevNets, because they were run on… with more resources, relatively speaking, but effectively, we don't…
Dustin:the way… the way we happen to run our testnet nodes, they don't have that many cores, and because at… and somewhere around the 9 to 15, BPO, change in Hawashki.
Dustin:They started consuming enough CPU time, and we've benchmarked this, and it just… how much time the library takes to do this is not really Nimbus-specific.
Dustin:this part of it, but it takes, like, 4 seconds to do… to reconstruct on the supernodes, and…
Dustin:And that just doesn't work anymore with the one, one and a half effect, of course, so we're figuring out what to do with that. But it's definitely an issue with… a novelty to BPO1, as a result.
Ansgar Dietrichs:Okay.
Ansgar Dietrichs:M… Yeah.
Ansgar Dietrichs:Little to report from, book's always good. So,
Ansgar Dietrichs:Then we can move on. I think the next point was Alex wanted to briefly talk about the blob submission API, if I remember that correctly. Alex, are you on the call?
stokes:Yeah, can you hear me?
Ansgar Dietrichs:So, yeah.
stokes:Hello?
Justin Florentine (Besu):Go ahead. Okay.
stokes:Thank you. Yeah, no, I didn't have any, audio issues, anyway.
stokes:So this came up in the context of some of the roll-ups, getting ready for Sepolia.
stokes:And the question here was just how different clients will treat,
stokes:essentially, I think, what we're calling legacy blobs, or transactions, with the pre-Fishaka proof format and the new one.
stokes:So I just wanted to check in, just so everyone's here, and I think we could just…
stokes:Get a quick, update or status on how this works for each client, but essentially, yeah, when,
stokes:do… I guess the question is, do any clients have support for converting between the old proof format and the new one? Like, let's say…
stokes:There's the question of the fork boundary, but let's just say, post-Fusaka, yeah, what's the behavior here?
Marius van der Wijden:Yes, so,
Marius van der Wijden:what we… we discussed this for a really long time, and I'm pretty sure what we ended up with is, at the fork boundary, we,
Marius van der Wijden:We start converting, in the background, our own blob pool, from… from… from blob proofs to cell proofs.
Marius van der Wijden:And… We convert all of the transactions that we get
Marius van der Wijden:sent via RPC, from blob transaction, from blobproofs to sell proofs.
Marius van der Wijden:And… I think we stop accepting… Blob… Transactions on the networking.
Csaba:There we have a small window in which we are still accepting from the network.
Csaba:I think it's the hours or something.
stokes:And then, would you…
stokes:at some point into the physical fork, stop converting on the RPC. I think that'll be the main thing for the roll-ups.
Marius van der Wijden:Nope.
stokes:Okay.
Marius van der Wijden:Like, not within, like, the next one or two releases would we remove that converter.
stokes:Gotcha.
stokes:And I think Geth was special in this way, as in this is what Geth does, but I think other clients essentially just drop support. So it'd be nice if I could just…
stokes:Get a confirmation of that.
Andrew Ashikhmin:Yes, for Aragon, we just dropped support of, blob, proofs,
Andrew Ashikhmin:non-cell proofs, so, yeah, we are not as nice as Geth.
FLCL:Nevermind, we will,
FLCL:not, gossip, and, like, accept, such transactions with all proofs, right on, when Head is, post to Osaka.
FLCL:We will drop them from taxpool, but we'll allow re-entrance of the transactions.
FLCL:Of the same transactions, but with a new version.
FLCL:Of, the proofs.
FLCL:And, I guess, someone… maybe from Gask has,
FLCL:Some information about, with such conversion in, like, tough conditions when a lot of transactions are…
FLCL:In the pool, will such conversion lead to any luck of the client?
FLCL:Lots.
Marius van der Wijden:So we tested that, especially this case, on,
Marius van der Wijden:on, I think, Holeshky, on, like, the last fork, the last testnet fork, and, yeah, basically nothing happened.
Marius van der Wijden:We are…
Marius van der Wijden:Only converting them in the background, and we are also limiting the conversion so that we don't over…
Marius van der Wijden:overrun the node, but what we did, or what the Pandorops team did at the fog boundary, they sent a bunch of
Marius van der Wijden:transactions, so that the… our mempool was full, and, yeah, we converted them, no problem. Let's see.
FLCL:And, you do not… okay, so you do not drop transactions for some time from the pool, just, start converting it.
FLCL:And if a new note is connecting, will you gossip transactions that are not yet converted? Still not converted, and have all proofs?
FLCL:Or… Or not.
Csaba:Yeah, we are not sending these old proofs, so after the fork, we only send these new proofs.
FLCL:Thanks.
Csaba:That was a question.
FLCL:Yep.
Ansgar Dietrichs:Okay, were we missing any client, or do we… Alex, did you?
stokes:Well, Bessu and Reth, but I think they have the behavior…
stokes:That, yeah, others that think I've had, so… I think we're good.
Ansgar Dietrichs:And that was… that was all you wanted to discuss?
stokes:Yeah, I just wanted to know where people landed as of now. I'm talking to some other roll-ups just to make sure things are good on their end, and that should be enough for now. Thank you.
Ansgar Dietrichs:Awesome, and just one quick clarification, Marius, when you said you'd keep the conversion functionality until at least one or two releases after, in principle, not sure if this is at all relevant, but in principle, if there was any other users or so that would approach you to request extending the support a little bit, would you be open to that, or…
Marius van der Wijden:Yeah, we don't have a… we don't have a clear path to dropping that yet, anyway, so…
Marius van der Wijden:We will be in contact with the L2s to drop it at a point that is convenient for everyone, but I… I would also urge the…
Marius van der Wijden:the… Basically everyone that's sending blob transactions to update their code as soon as possible to
Marius van der Wijden:to create those sale proofs themselves, because otherwise you're creating a proof, and then we have to recreate the proof and the note again, and so we're wasting a bunch of time. So if you want to get your transactions in faster, create the proofs yourself.
Marius van der Wijden:The, the sale proofs.
Marius van der Wijden:proofs.
Ansgar Dietrichs:Yeah, that makes a lot of sense.
Ansgar Dietrichs:Awesome.
Ansgar Dietrichs:Perfect, then I think that would… that's all on that agenda point. Then, anything else on Fusaka people want to discuss before we move on?
Ansgar Dietrichs:Okay, then we have a quick single item, section, which is just scaling updates, where we have some
Ansgar Dietrichs:brief comments from Jocham, I think, on, some…
Ansgar Dietrichs:State access benchmarks that, that, that is looked into, is that, is that right?
jochem-brouwer:Yeah, thank you, thank you.
jochem-brouwer:Yeah, so I wanted to talk about, Camille, and, Camille from NerfsaMind, and I, we are working on tooling.
jochem-brouwer:To run execution spec tests, against, like, state snapshots, like, mainnet snapshots.
jochem-brouwer:So we can actually also incorporate the size of the state in these tests to perform performance benchmarks.
jochem-brouwer:And this is, of course, very broadly applicable, because we can also, like, test for different gas limits.
jochem-brouwer:And what we actually want to do here, like, what our holy grail would be, is if we see a slow block.
jochem-brouwer:Then we want to check this block, see if there's anything weird going on over there. We will then isolate this behavior.
jochem-brouwer:And then we would replay this on top of, well, most likely, it could, of course, have something to do with the state it runs against.
jochem-brouwer:And if we would then run it in isolation, we would also like to see that we can reproduce this slow block in isolation, so we can really take apart the client to figure out, okay, what is, like, the bottleneck here, so we can optimize the client.
jochem-brouwer:For these slow blocks, well, I think I've mentioned that many times already, but yeah, most of the times when a slow block is being reported, it has these very big sand transactions in it, so a transaction which interacts with Xen, which has a high gas limit.
jochem-brouwer:And we are currently testing this, and the… well, one of the current results is that if we do this on top of a mainnet state.
jochem-brouwer:that we rerun this, like, a lot of changes to the storage of Xen, then we still do not see really problematic numbers here.
jochem-brouwer:So this…
jochem-brouwer:It either means that the tests are wrong, or our tooling is wrong, or that we are missing something else.
jochem-brouwer:But yeah, I just wanted to bring that up, that this is, well, the current research we are doing for the state access benchmarks.
Ansgar Dietrichs:Sounds good. So basically, if I understand this correctly, because I heard that, from some of the test cases there, there were some, relatively, slow-performing, numbers, right, around some of these cases, but what you're saying is that, at least right now, it looks like this might just have been a, discrepancy in the testing process, and not necessarily, correctly
Ansgar Dietrichs:Expressing real, kind of, performance bottlenecks?
jochem-brouwer:Yeah, somewhat, so what I'm actually saying is that if we run these tests in isolation, the numbers there do not look super bad.
jochem-brouwer:But if we look at slow blocks on mainnet, especially those reported by, how is it called again? Like, we have a Grafana dashboard, which has slow blocks.
jochem-brouwer:And these are being accumulated from the lab, from Ivebender Ops, and…
jochem-brouwer:I think so far, I've only seen blocks with these Xen transactions in them.
jochem-brouwer:And this begs the question, like, maybe the result is that we do not have… we cannot reproduce these results in isolation.
jochem-brouwer:But that will then mean that these nodes, when they are live on mainnet.
jochem-brouwer:There is something else going on, but it simply causes, like, a…
jochem-brouwer:Well, not… yeah, somewhat like, yeah, a majority of these nodes are performing like slow blocks.
jochem-brouwer:Which we can't yet reproduce, so…
jochem-brouwer:Yeah, that's the current state of this research.
Ansgar Dietrichs:Okay, then I added it basically exactly backwards, but okay, awesome, perfect, then I think that's… that's a good, good point for… for follow-up work, but, yeah, thank you, thank you for supporting this.
jochem-brouwer:Yeah, I see one question from Ms. Yang. Yeah, we are running this on, I don't know the EIP number, but, like, the specified hardware specs.
Ameziane Hamlat:Okay, so when you say in isolation, what does that mean exactly? It just means that you are running that specific block on top of that snapshot, but the snapshot has, like, the whole database, all right? The whole blockchain and state.
Ameziane Hamlat:State, database, right?
jochem-brouwer:Yes. Yeah, so what we actually do here is, for these, well, these specific Xen situations, is, our hypothesis is that this has to do with, the storage rights to Xen.
jochem-brouwer:So what we do is we create a test which should actually perform worse, because what we will do here is we will fill the entire block
jochem-brouwer:We have storage rights, and we even optimize, like, this contract to do the storage writes to, well, to squeeze out even more storage writes than what would happen in the block which we have seen.
jochem-brouwer:And then when we run this, and by running this in isolation, I also mean we're starting… we are starting our client.
jochem-brouwer:And…
jochem-brouwer:without DevP2P, like, we are not going into the network, we are just only starting plans to run this specific block.
jochem-brouwer:And if you do that, we do not see, like, this execution bottleneck.
jochem-brouwer:or, well, not, sorry, not a bottleneck, but we do not get, like, these slow results as we would see on mainnet, which is, like, being reported by multiple different nodes, that this block is slow, but if we run it again.
jochem-brouwer:Which we would just say is, like, an even worse case than the mainnet block.
jochem-brouwer:We do not get the results which we would expect.
Ameziane Hamlat:Maybe one test that can be interesting is to run, all the time, one node on the same hardware specs that is basically running the mainnet.
Ameziane Hamlat:And then when we have, like, one slow block on that, like, with that hardware, we can pick up that slow block and run it on the same hardware in isolation. Because from what I understand, like, the blocks that…
Ameziane Hamlat:you get from, I think, from the network, from Ithpond.Ops team, can, you know, can run on different hardware types, right?
jochem-brouwer:Yes, okay, yeah, that's also a very good point, of course, that this could also be hardware-related, yes.
Parithosh Jayanthi:Yeah, I think part of the reason we don't want to over-index on just nodes that we run is then you're kind of canonicalizing an architecture and optimizing for a specific architecture. One of the benefits of relying on the contributor data set is
Parithosh Jayanthi:We… we are basically getting all types of nodes that people run real… in real world, on mainnet, as free data points.
Parithosh Jayanthi:But yeah, it is harder to reproduce, of course.
jochem-brouwer:Yeah, and one question, actually, about that, because I could not see on the lab, we can see, like, the contentless layer clients, but we cannot see the execution layer clients, like, their types. Is that correct?
Parithosh Jayanthi:We should have the data on a database. Maybe we can ask on a thread, and Sam or Andrew should be able to pull it out of the.
jochem-brouwer:Let's do that, let's do that. Yeah, sounds good.
Ansgar Dietrichs:Awesome. Any other comments now by Kodvs on this? Otherwise, maybe, Jocham also, where would the best place be for people to jump into that kind of work and conversation?
jochem-brouwer:Yeah, just, either send me a message on Discord or Telegram, or… yeah.
Ansgar Dietrichs:Okay.
Ansgar Dietrichs:Then I would move on to… The glum slump section?
Ansgar Dietrichs:We have a few items here, first a few general ones, and then, regarding ERP proposals. So first, on general, do we have any…
Ansgar Dietrichs:DevNet updates, so primarily that's a block-level access list,
Ansgar Dietrichs:Tony, are you on the call?
Toni Wahrstätter:Yes, I can provide a quick update on blockhead access lists.
Toni Wahrstätter:So we had a breakout call yesterday, things are, in general, looking quite good.
Toni Wahrstätter:Beso, GEF, RAF, and NetherMind are very, very close to being interop-ready, I would say.
Toni Wahrstätter:So, it's just a matter of time, getting those clients to interrupt, and…
Toni Wahrstätter:Aragon is also, getting there.
Toni Wahrstätter:Regarding DEFNET, I would pass to Stefan, who has, better insights, what the next steps, are there.
Stefan Starflinger:Hey, can you hear me?
Stefan Starflinger:So…
Ansgar Dietrichs:Yes.
Stefan Starflinger:Generally, I've been trying out, individual kurtosis testnets, with just individual execution data clients, and I've been able to run, Geth, Bazel, and RET, just
Stefan Starflinger:one client, each time, but I haven't been able to run any clients, like Nix, like Bezu and Wrath, I haven't been able to run them together, so I'm still trying to get that to working with clients, and never mind, I haven't been able to run
Stefan Starflinger:There is a small issue with the Genesis, and I posted that into the block-level accesses channel.
Stefan Starflinger:But in general, I think we're getting very close, maybe next week, if the interrupt, starts to look a little bit better.
raxhvl:Let me also give you an update on the state of tests.
raxhvl:We released our latest test a few weeks ago, with about 26 tests.
raxhvl:Since then, we've been tracking test results for cat, netheramide and red.
raxhvl:And they're roughly passing about 80% of the tests.
raxhvl:There's a particular test which is failing for all three clients, so we double-checked it to ensure that is okay.
raxhvl:Bessel is also passing tests locally, but fixing an issue with the hive.
raxhvl:So I think those… Should also be available, so that's 4 clients in total.
raxhvl:Since then, we've matched a few more PRs, and there are about 54 tests.
raxhvl:ready for BAL. Some of those tests, have variations, so in… in total, we have about 154,
raxhvl:Scenarios that we're testing, so we'll have these ready in an upcoming release soon.
Ansgar Dietrichs:Sounds good. And sorry, this is a dumb question. Was this… is this, buckler boxes specific, or…
Ansgar Dietrichs:Tests across the…
raxhvl:Yeah, yeah, yeah, specific to block the Nexus, yes.
Ansgar Dietrichs:Okay, perfect.
Ansgar Dietrichs:Anything else on BucketBox lists?
Toni Wahrstätter:Yeah, maybe one more thing, just to add, there's still one thing, one PR open around 7-7-02 about handling
Toni Wahrstätter:The authority tracking there correctly?
Toni Wahrstätter:This isn't merged yet, but, it's about to be merged very soon, so it's correct in the EAP, but it's not yet correct in the specs, and…
Toni Wahrstätter:I got a PR open there, and Philippe and me are working on this right now.
Ansgar Dietrichs:Sounds good.
Ansgar Dietrichs:Katya?
Katya:Hello, yeah, we also started working on metrics for, level access lists. That would be great if some of the clients at least started implementing, or we can communicate on this. So probably…
Katya:If not for DevNet 0, but for DevNet 1, we could have something already. Thank you.
Ansgar Dietrichs:Awesome, thank you.
Ansgar Dietrichs:And then, in terms of governance updates, or feature updates,
Ansgar Dietrichs:any… anything from the EPBS side, obviously that's more consensus layer side work, so just… just checking, is there anything, execution layer side, that…
Ansgar Dietrichs:Would warrant an update?
Ansgar Dietrichs:Otherwise, yeah, as Alex is saying, there's a breakout, I assume you mean for EPBS, right? EPS breakout tomorrow?
stokes:Yeah, I was just… Yeah, we have the breakout tomorrow, if people want to attend there.
Ansgar Dietrichs:Yeah, and I think one of the topics raised on last October, so maybe for those that were not on there, there were some questions around,
Ansgar Dietrichs:The unconditional payments, specifically, whether there should be some sort of,
Ansgar Dietrichs:and splitting it into separate EAP or something, yeah, if that's a topic that interests you, tomorrow would be the breakout.
Ansgar Dietrichs:Yeah, awesome. And I agree with Justin in chat. Great work all on these kind of glam-side dumb features already. It seems like we're already well into the work on this fork. We haven't even gotten Fusaka out the door, that's… this is… this is great.
Ansgar Dietrichs:Yeah, then Glamstam, next, well, I had testing updates, but I assume that's already covered now with the Black Lives specific testing. Was there anything else on testing, for Glamstam beyond that, that we should cover, or… I assume this was it?
Ansgar Dietrichs:If nothing else, then,
Ansgar Dietrichs:the, then for the rest of the call, we just have a few more, updates on other… on proposed EAPs and new proposed, EAPs for the non-headliner section of Amsterdam. Just before we do that,
Ansgar Dietrichs:A reminder, we had said that basically when, once we set the mainnet date for Fusaka, we will basically freeze the proposal window for…
Ansgar Dietrichs:For Gramstadam, we haven't done it yet, but obviously we're getting close to that point. And then on that last Orquadevs, on the ACDC side, we specifically, like, clarified the details of, like, what the exact timeline there looks like, so the idea is that
Ansgar Dietrichs:whatever point in time we actually do set the mainnet dates for Fusaka, that… then basically that will trigger, like, one last week of, proposal window for…
Ansgar Dietrichs:for non-Hightline ERPs for Ram Saddam, and then basically the deadline there would be then one week. So basically, the QRFs, the Okadavs call, one week after that.
Ansgar Dietrichs:In a date setting one.
Ansgar Dietrichs:That way, hopefully, people have time to get in U.S. Moment proposals.
Ansgar Dietrichs:With that out of the way, we have three, people that wanted to, to briefly talk about, some of these proposed ERPs. The idea would be that in next, ACDE call, so in two weeks, we would really go into the discussion,
Ansgar Dietrichs:More, more generally about,
Ansgar Dietrichs:what kind of the non-headliner section should be focused on, but for now, it's still just about just informing people about the individual proposals, so it's not necessarily meant as a governance discussion section or a technical information section. First up would be Maria, who wanted to briefly talk about an update on the repricing ERPs. Maria, are you on the call?
Maria Silva:Yes, hello. I'll just quickly share my screen. I have a few slides to help with the discussion.
Ansgar Dietrichs:It's still loading.
Maria Silva:Okay, can I…
Ansgar Dietrichs:We can see your speed.
Maria Silva:Perfect.
Maria Silva:Okay, so I will just give a quick overview on the repricing ZIP, so we have quite a few now. And just to say that, before we release the IPs, I wanted to just give an overview of why we are even doing repricings.
Maria Silva:So the… the first point is, like, we know that EVM operations don't have harmonized costs at the moment. So, for instance, on the compute side, we have operations that take
Maria Silva:show different, performance in terms of million gas per second.
Maria Silva:We, on, for instance, state creation, not all operations have the same cost per byte created, so, this creates, a situation where we have, like, specific bottlenecks, that sort of,
Maria Silva:limit us on how much we can scale, instead of just having everything, harmonized. The second point is that even
Maria Silva:if the costs are harmonized at resource level, the relative cost of resources, will likely change with, balls and EPBS. So, for instance, we may have more
Maria Silva:time for execution, but the state growth, we don't want it to increase at the same rate, so we want to keep state growth stable while giving more space for… for compute. So the relative cost there also changes. And finally, as we
Maria Silva:increase the gas limit as we are scaling, this will put pressure on these persistent usage resources, which are mostly history, growth, and state growth. So there… there… we also need to take this into consideration when we are doing the… the repricings.
Maria Silva:And, now on to the proposed EIP. So I just want to say that, EIP8007 has the full list, so if you ever want to check which EIPs are changing pricings for Amsterdam, you can check there.
Maria Silva:But this is mostly an informational EIP, so we are not,
Maria Silva:this is not the bundle, like, we are still discussing them one by one, and considering if we should include one by one, it's just a place where you can have a quick view of all the IPs and their status in the governance process.
Maria Silva:And so on to the various, EIPs. So first, on the compute and memory side, we have, 7904. This is the big repricing on compute, operations, that is,
Maria Silva:So we are using, benchmarks on each operation to
Maria Silva:harmonize their, costs, and also, this will likely lead to a decrease in most, compute prices, with, likely some, exceptions on some recompiles. But essentially, this is a massive, reprice on, compute operations, and
Maria Silva:most of it will be, making them cheaper. We have, 7667, so this is updating some, operations, based on the hashing cost for ZKVM proofing. So this is sort of,
Maria Silva:an EIP that, it's not directly to…
Maria Silva:It's not directly related to increasing, scaling, but it…
Maria Silva:it's something we might need down the line when we are moving to the ZKVM, and it's something we need to… to also account when we are working on the 7904, to make sure that these changes make sense and are consistent. And finally, we have 79…
Maria Silva:2, 3, and here, Charles is going to give an update, but essentially, we are introducing a new model for memory, and also updating the price accordingly.
Maria Silva:On states, we have 8032, which, Guillaume will also give an update next. And essentially, this is just repricing S-Store in a way that,
Maria Silva:takes into consideration the size of the contract storage. So essentially it's making larger, S-stores to larger, contracts more expensive than to smaller contracts.
Maria Silva:And then the next two EIPs are, the 8037, which is changing the state creation cost, so this is, targeting state growth, and it's, proposing an increase of around 10x on the state creation costs.
Maria Silva:And also adding an independent metering for the co-deposit components,
Maria Silva:And 8038, so this is focused on state access costs, and also it's sort of connected with the tree-based storage, but it's doing a more holistic reprice on all state access, and also taking into consideration
Maria Silva:If, it's your all three, is included, then, they will kind of work together, so the…
Maria Silva:8038 will simply
Maria Silva:change the constant part of SSTOR, and leave the dynamic part with the contract size scaling, consistent with, with, with that EIP.
Maria Silva:On data, we have two. We have 7981, that is, introducing a floor to access lists.
Maria Silva:And also, 7976, that, is further increasing the cost for call data. A point here that is important, so we have
Maria Silva:For data and state growth, these essentially are mostly independent resources from the execution and state access resources, and so it's important when we are setting the values here to make sure that things are consistent with a certain
Maria Silva:ghazi meat anchor, let's say. So,
Maria Silva:We are not introducing more mispricings.
Maria Silva:And finally, we have two more general or accounting EIPs. So, 2780 is proposing to reduce the intrinsic costs, so essentially making eTransfers cheaper, but also adding a component for account creation. So when an e-transfer is creating an account, essentially it will be more expensive.
Maria Silva:And then finally, 7778, that, proposes to remove the refunds, from the block limit accounting. So, they will still be a refund to the transaction, but they will not count for the block limit, so this should help us remove some
Maria Silva:Some, worst-case blocks that are making those cases not, as worrisome.
Maria Silva:So on the next steps,
Maria Silva:First, it's just, making sure that we are considering all mispriced areas, and, and see if there's anything else we should be adding, before the, the deadline for, EIP proposals. So if you have, any thoughts on these, just,
Maria Silva:reach out to me, and I'm happy to… to… to discuss it and support, any more EIPs that need to… need to be drafted. We also are working now, with,
Maria Silva:opcode benchmarking, and this will help us set the final parameters for some of the EIPs, and also updating a few parameters that need, updating.
Maria Silva:And also, we need to make sure on this step that, again, as I was telling, to have the alignment between the various EIPs and making sure that things are consistent and make sense.
Maria Silva:And then after this, we'll… the next step will be to start implementing these new price changes in all… in all the clients, and then running as benchmarks, so we make sure that,
Maria Silva:The worst-case scenarios, are covered, and we are not introducing more mispricings.
Maria Silva:And also, another big part here is, like, this is one of the biggest repricings that we've done in a lot of time, so it's important for us to really investigate backward compatibility issues and making sure that we are not introducing anything that could break.
Maria Silva:Important contracts, or…
Maria Silva:Yeah, and so here on, on this point, like, if you have any thoughts on what could break, also please reach out to me, so we can, we can work on these together.
Maria Silva:And this concludes the presentation. I was not seeing the shots, but I will stop Now, the slides and…
Ansgar Dietrichs:there were, again, maybe just read them out to you, there were two, I think, main questions. Well, one is just where practically, Charles was asking what the best way for people would be to reach out to you for feedback on these topics.
Maria Silva:Yes, so I'll say, Telegram is a good, a good place, so I can…
Maria Silva:put my handle if you don't have it, in the chat in a bit. But yeah, just Telegram is probably the easiest.
Ansgar Dietrichs:Sounds good. And then, Matt specifically asked you, you already touched on this a bit, on the question of backwards compatibility. Is there already ongoing work? Like, is this maybe different ERP by ERP? So what's, what's the current state of this, basically?
Maria Silva:Yeah, so I think on a couple of the IP IPs that were, either making things cheaper, usually the analysis was there's not,
Maria Silva:a lot of concerns there. I think the biggest concerns are actually on, probably the state's, state growth and state access ones that will have an increase, and on there, we do have some analysis planned, but, it's still ongoing, so we don't have any results yet.
Maria Silva:Guillaume, do you have anything to add here?
Guillaume:Now on this topic, I have something to… I mean, I want to talk about, EIP, yeah, okay, let me, let me proceed. I have two, two things going on. The first, the first one is that,
Guillaume:20, 2926 is not in the list, and it is a, it is definitely addressing,
Guillaume:the state growth in terms of code. And, I'm also quite surprised to discover AT37, which is very redundant with 2926.
Guillaume:I've also seen a, and unfortunately, Carlos is not here today, but Carlos was asking me to review something that I thought was going to be, AT37. When, you know, is, is it still, is it still evolving that,
Guillaume:And this is the supposedly definitive version.
Maria Silva:So, your sound broke out a little bit, so you are asking about, right.
Maria Silva:37.
Guillaume:AT37, yes. Okay, I'll just, I assume that was Telegram, taking over the sound, let me turn it off.
Guillaume:Yeah, so two things. The first one is that 2926 is very redundant with AT37, and it seemed to me that AT37 was going… I reviewed a document by Carlos, who unfortunately is not here today.
Guillaume:that was…
Guillaume:to be, I thought, the future version of AT37, so I'm just asking, is it the final version?
Maria Silva:this… this version is… is the most updated version. We may need some parameter changes down the line, but these should be the… the… the… and some… some more,
Maria Silva:So, improving sections on specs and backwards compatibility issues, but this should be the final EIP. I would say that the main difference there is that this EIP is not only focusing on contract code, but it's also focusing on other components, like account creation and so on and so forth.
Maria Silva:And I think we can make both VIPs compatible, so the… the… the… the biggest thing is, like.
Maria Silva:8037 is really focusing on an harmonization of state growth in general for all operations that, touch or increase state.
Maria Silva:And I think both VIPs are kind of… they work together, so you can have both, or you can have just one or the other, so it's… I don't think it's, like.
Maria Silva:If you have one, you don't need the other. They are kind of,
Maria Silva:So they… they… they have implications to one and the other, but they are not, exclusive, let's say.
Guillaume:Yeah, okay, I would still like to get, but I will talk to Carlos. I'd like to get to the bottom, because I reviewed something on Tuesday that was quite different, so I'd like to make sure I understand. But yeah, okay, we can take that offline.
Ansgar Dietrichs:But any other, comments on, the presentation?
Ansgar Dietrichs:Or any of the individual, repressing your piece?
Ansgar Dietrichs:Okay, and yeah, I saw Maria now put her telegram handle in the chat, so you can find it there.
Ansgar Dietrichs:Then, I think we'll move on for now, to the next item, where, Guillaume, you'll be up again, talking about EIP 8032.
Ansgar Dietrichs:Sorry, so before, before that, just one more, I saw Tony had a sent-up, sorry about that.
Toni Wahrstätter:Yeah, I… sorry, to interrupt. I just had a question, like, how would we best proceed with the repricing EAPs? Usually we have, like, client teams shortlist, their preferred EIPs.
Toni Wahrstätter:Yeah, should we… is there some different process involved, because it's, like, a bundled, repricing thing?
Ansgar Dietrichs:So, just… just to clarify, I think Maria did a good job summarizing this already. Basically, here this… why there is this extra information on ERP, which was a bit of an experiment as the form factor, but… and there is no specific bundling. So, obviously, some of them make sense together, and we can
Ansgar Dietrichs:point this out and talk about this a bit more, I think, in two weeks, but in principle, we can pick any and none and all of them, basically whatever we choose.
Ansgar Dietrichs:In terms of process, specifically, my idea was, and I'm happy for feedback if people think this is a bad idea, my idea was to say, start the conversation properly next, ACDE, so in two weeks, around
Ansgar Dietrichs:And what should be the priorities? How much room do we think we have in Amsterdam? Like, what is the different categories of the ERPs that basically were proposed? So to have some sort of baseline of what do we expect Amsterdam to look like, and then
Ansgar Dietrichs:on that basis, have some ERP-specific discussions, and then move to the step of having client teams, assemble their preferences.
Ansgar Dietrichs:so basically, like, today still focus purely on just the technical presentations of the individual ERPs. Does that make sense for people? If not, of course, this could be adjusted. I like the most reasonable approach to me.
Ansgar Dietrichs:Sounds good. Then I would for now stick with it, but again, also feel free to…
Ansgar Dietrichs:reach out to me, we can, we can discuss, some alternative processes as well. But yeah, then, for now, Guillaume, you're up.
Guillaume:Yeah, okay, I hope you guys can see my screen, or my window.
Guillaume:Yeah, I'd like to talk to you about EIP8032, which indeed stems from all the conversations about state access or state-related operations repricing. So…
Guillaume:there are very, simple goals for this thing. We want to limit the state growth.
Guillaume:We also want to make sure that no individual contract, and there's really one that we're thinking of when we say that, oops, is… their individual growth is reduced.
Guillaume:And then, of course, we would like a smooth transition as much as possible.
Guillaume:So, yeah, like, the idea, there's a big math formula inspired by the yellow paper, but it's very simple. You just, notice.
Guillaume:Write down, into the account what was the maximum depth that, was written to previously into this account, into this account storage tree.
Guillaume:And then, we target an activation depth, which would be, targeting that same contract I was talking about, but maybe other contracts if they happen to grow just as large.
Guillaume:And then the new gas cost for writing, so…
Guillaume:for writing, which is a store, would be, would be simply to take the delta written in the account, which is loaded at the beginning of the block execution, and then you have this constant value, which is today's value, or any value that is decided after the
Guillaume:repric… repricing EIP.
Guillaume:And then, you just get, the delta divided by this, delta 0, power of 16, and then you take the, the floor, like, the… the smallest, integer.
Guillaume:Down, from this number. And multiply by another cost, constant.
Guillaume:The idea is that everything that is below this delta zero will not see its cost changed at all.
Guillaume:And everything above, so that contract, will be, will see its, its cost, increasing exponentially.
Guillaume:And, yeah, how does the transition happen? It's just that from one block to the next.
Guillaume:At the end of a block, you just look at, for each account, when you recompute the storage root of this account, you just update the value, the delta value of this account, the maximum depth.
Guillaume:And then…
Guillaume:You don't update it with a new value, you just gradually increases one by one, so that the cost of those contracts that are already much larger than the limit.
Guillaume:increase somewhat progressively. I mean, it's going to be, probably 9 blocks, but it's still, it's still going to be a bit smoother.
Guillaume:And, yeah, maybe we can modify this, conversion to… sorry, this rule to be even more, disincentivizing of the state growth as a whole. So,
Guillaume:do the same thing, but add a gamma, which is the total state size, and we do have, at least in Geth, we did implement something to keep track of the total state growth. It's not exactly what we need, but it's close enough that we could modify it to be that.
Guillaume:And then we would have a second term in that equation.
Guillaume:Where not only the specific contract will be penalized for growing the state, but even those who are not this big contract, but have to suffer from a larger state growth.
Guillaume:they will see their costs rising up, so it's much more dynamic. And of course, we can modify those constants as machines get more powerful, as states, maybe if we implement state expiry.
Guillaume:We could also decrease them. So yeah, that's just an idea, but it's not part of the EIP at this moment.
Guillaume:So just wanted to also say what it's not. It doesn't tell us what the gas costs are gonna be, so, some of those EIP, like, especially AT38, AT37 maybe, and all those EIPs that focus on the gas cost itself, this is not… this is orthogonal to that.
Guillaume:It also doesn't work on limiting account creation per se, it's just the storage size. I would say 2026 addresses
Guillaume:The… the code size aspect, but yeah, there's nothing for account creation.
Guillaume:And yeah, like I said, the code bloat, yeah, that's 2026. I have one last slide, yep. It's what is left to be done, so I did implement that in Geth. It's still in draft mode because I haven't figured out the activation yet, but it doesn't really matter for testing.
Guillaume:And, what we would like to do is get the constant value, so, piggybacking on what Maria was saying, try to, try to see if, we could, use EIP, any of the EIP in 8007 to, to figure out what the values are.
Guillaume:And also, decide on the gas formula. I presented two, so pick one of the two. Yep, that's… that's it for the presentation.
Ansgar Dietrichs:Thank you. There were a few comments in chat. Specifically, one, one conversation was around.
Ansgar Dietrichs:how do you… how are you thinking about using the worst case for pricing? Is this not vulnerable for attacks, where someone can basically, like, maliciously create one really, like, deep sub-branch in a storage tree, and then forever that contract has to pay more?
Guillaume:Yeah, so, I mean, this is more explained in the EIP, so let me refer you to the EIP. But, no, you can't really do this, because the activation depth is going to be 9, so that's pretty expensive to get, to get this, this depth.
Guillaume:Voluntarily. Because it's, like, the storage slots, are stored
Guillaume:you know, the keys are hashed before, so to be… to be able to get that deep, you're going to have to create either a lot of keys, which is going to be expensive, or do a lot of proof of work to address… to reach that depth. So, no, it's not an attack.
Ansgar Dietrichs:Makes sense. And then one more conversation, but there were several different people talking about it, but I would summarize it maybe as, if you have multiple accesses, then if they're in the same storage tree, even if it's a bit deeper, then they amortize, basically, because they are in the same tree and partially share the same branch, whereas
Ansgar Dietrichs:If maybe you now incentivize, which in principle is a good thing, people to split it up into several contracts, so that in each contract it's less steep, but then they no longer basically have this amortization.
Ansgar Dietrichs:So basically, do you think this is a concern, that maybe the efficiency gain, in a way, can be less in these cases? Or that basically it's kind of… yeah.
Guillaume:I didn't quite understand the question. What is going to… what would the efficiency decrease?
Ansgar Dietrichs:So basically, there's someone, like, so suppose, for example, said, was there an explanation why one contract of size 2S is worse than two contracts of size S? And of course, this is only relevant if they're actually being accessed.
Ansgar Dietrichs:So imagine you have now someone, basically, that otherwise would have a contract of size 2S, now splits it up into two contracts of size S, and we have a block with simultaneous accesses into both contracts.
Ansgar Dietrichs:And in the old world, that would have been just one… two accesses into the same storage tree of one contract. Is this more… is this new pattern more efficient now, or is it mapped?
Guillaume:I mean, if you want to do this, it's not going to be that much more efficient, because to access your second slot, you're going to have to call the contract, so it's going to be expensive to do this. But yes, you could do this, and in fact, this is more or less what we want, and the reason for this is because you…
Guillaume:you would be able to expire, thanks. I mean, we're still counting on getting state expiry to work, so it would actually be exactly what we want, that people split their data into several contracts, but somehow.
Guillaume:Doing the union of all the contracts, that's going to be very expensive, so it's going to disincentivize state growth, this way.
Ansgar Dietrichs:Sounds good. And then, of course, lots of people can also speak up, I don't need to read all these comments, but, Matt asked, how does this ERP relate to the unification of state of the state tree?
Guillaume:Yeah, I mean, if the question is, can this still work with a unified state tree? Yes, it can.
Guillaume:And although I forgot how it was going to work, but we came up with a scheme to make it work, so that's not a problem.
Guillaume:The other, I was thinking of something else. So, if you're talking about doing the transition, this is… this has no impact, because, yeah, it's not going to change the structure of the tree, and it's not going to block the tree from being converted into a different tree.
Ansgar Dietrichs:Sounds good. Any other questions, or any questions from chat that I missed that someone would want an answer from Guillaume?
Ansgar Dietrichs:Okay, awesome. Well, thank you, Guillaume. I personally think this is a very interesting idea, although, of course, I'm supposed to be impartial.
Ansgar Dietrichs:Then, next up, we have Charles with, several EIPs that, he wanted to talk about. Just given that, I mean, we still have 25 minutes of time, but I would ideally say that, it would be nice to try to timebox it a bit below that, to not, not, because it's four EIPs, but basically, like.
Ansgar Dietrichs:keep it up by going through the intro, just so we still have a chance of ending a little bit ahead of time.
Ansgar Dietrichs:But yeah, Charles, are you on the call?
Charles:Yes, hello?
Ansgar Dietrichs:Awesome.
Charles:Can you hear me okay?
Ansgar Dietrichs:Yes, we can hear you.
Charles:Okay,
Charles:I think a couple of these aren't that new, they've been proposed in previous works, so I won't go over them that much. There's 7907 and 7903.
Charles:Which are alternative proposals.
Charles:Which were, proposed for Fusaka.
Charles:And they are about increasing the contract size, the EIP170 24 kilobyte limit.
Charles:And in Fusaka.
Charles:7907 was rejected because it makes some changes to the state, which are maybe hard to reason about.
Charles:7903 is an alternative, which doesn't touch, state.
Charles:assumptions about state at all. It increases the limit for init code.
Charles:But that is… just runs once, and then it's never a certain state, so it's not an issue, really.
Charles:5920 is pay.
Charles:which I've proposed again for Amsterdam.
Charles:And that is the ability to send Ether directly to another contract.
Charles:Without execute… without transferring execution context.
Charles:7923 is new for Amsterdam, and Maria mentioned it. It's about changing the quadratic Memory?
Charles:Actually, I didn't realize there would be this much time today.
Charles:So I prepared a presentation for 7791, which is the one I want to emphasize this call, but… so I'm just going through the other ones quickly.
Charles:Yeah, 7923 is about changing the quadratic memory pricing.
Charles:It proposes a paging model, so, like, I guess, most other computers in the modern age,
Charles:We can make… the AVM have virtual pages, and this is super helpful for users and also compiler developers.
Charles:Who can then,
Charles:use more of the memory space. So, for example, if you want to have a heap and a stack,
Charles:normally, if you have, like, with this quadratic memory, if you start from zero, then you can only have one stack or a heap, basically. Whereas in normal computers, you just allocate them in completely different areas of the memory, and then they grow
Charles:Separately.
Charles:The one kind of contentious issue that I've gotten in private feedback so far is there's…
Charles:this kind of LRU cache.
Charles:Which is, to help pricing, basically.
Charles:the 512 most recently accessed pages are cheaper to access because it reflects some reality of the underlying hardware, which is that if you have a thrash, so, like, either a cache thrash or a… what do you call it, a TLB miss.
Charles:That incurs extra, CPU time.
Charles:And it tries to model that. But I'm…
Charles:There's some discussion about this on the ETH interesting thread, and I'm a little bit open to changes.
Charles:About that particular model.
Charles:That part of the model.
Charles:But in general, I think that having,
Charles:page-based memory is… is good and important for the EVM.
Charles:So, I want to… present on 7791, which is, I guess, the ETH.
Charles:Let me share my screen.
Charles:Is this visible?
Ansgar Dietrichs:We can share his… we can see his thing.
Charles:Great.
Charles:I wonder how I can make this better.
Charles:paper.
Charles:So, making PowerPoints actually isn't one of my strengths, so this is mostly made by…
Charles:the… one of the LLMs.
Charles:But it, basically… Summarizes the IP and,
Charles:I'm gonna go into some interesting parts about it. So, the gas to ETH is actually a very, simple
Charles:Opcode. Basically, it takes…
Charles:gas amount, and it pops up from the stack, and then it sends that amount of gas from the TX origin to the target.
Charles:And the reason this is important is because… Basically.
Charles:every protocol or smart contract author runs into this issue of, like, how do I get paid?
Charles:And there's a lot of… Problems with, getting paid.
Charles:One of them… Yeah, where do I even begin? So…
Charles:And then people come up with all kinds of different ways to get around this, like they launch tokens or whatever.
Charles:So, some of the issues with, like, getting paid directly on-chain are that the payment… there's no way to pay directly from TX Origin to the contract that you want to pay.
Charles:you basically have to, like, do payment hops. So, like, if you have a deep chain of contract calls, then you have to, like, forward message.value, or forward some token down the entire chain, until it finally gets to the target.
Charles:And, that's just kind of… Bad UX?
Charles:Because you have to, like, do a bunch of calculation, you have to make sure that the right amount of message value is passed, and so on.
Charles:So what this… The AP is trying to address that problem, so basically,
Charles:it uses a concept that's familiar from UX, which is paying gas. Like, everybody kind of knows that in order to keep the network running, you have to, pay gas.
Charles:And it uses gas to, like, kind of… Pay contract creators.
Charles:So… Yeah.
Charles:There's some kind of interesting technical issues that have been brought up with this so far. So,
Charles:One thing is that… If you link it too close…
Charles:Oh, I wanted to point out there's another important thing about using gas, which is that instead of ether, which is that it's kind of actually priced in terms of block space demand.
Charles:I don't know, very opinionated.
Charles:Yes. So…
Charles:whereas Ether is kind of… has its own value, or whatever, gas is usually actually priced in basically USD, so in some ways, its price is more stable, or it's, like, kind of…
Charles:It kind of aligns
Charles:contract authors with the chain, because when gas prices go up, people who are paid with gas to ETH get paid more.
Charles:So, there's a few, interesting things about the design.
Charles:That have been brought up. So, one is that, interacting with the burn is bad. So, basically.
Charles:The gas consumed by gas is actually very different from gas that's, like, consumed by regular opcodes. So, gas consumed by regular op codes, it, like, reflects some computational complexity, whereas this actually just reflects how much somebody wants to get paid.
Charles:So, you don't want it to affect the burn, because there are kind of griefing attacks, like, you can just, like, send a bunch of gas to Ethan, and you can, like, change the base fee, or whatever.
Charles:And it shouldn't, like, double accounting for, how much is sent to Coinbase or whatever.
Charles:so, what we've done is we've created a separate gas ETH limit.
Charles:Which is tracked separately from the regular gas, and that is a slightly more complex implementation, I think, but it kind of sucks.
Charles:steps all of these issues with, like, how… Gases.
Charles:Interacts with the rest of the protocol.
Charles:Another thing is, like, how much gas are you allowed to send with gas to ETH? And, there's a problem that has been correctly pointed out, is that, like, you can…
Charles:It's like a grieving vector, like, you can… send an arbitrary…
Charles:You can spend an arbitrary, you can do all kinds of clever things to avoid that showing up when you run eSimulate.
Charles:So, the solution in this EIP is to, like, limit the amount of gas that can be spent.
Charles:Or, the amount of gas that can be spent as action in gas, and that's kind of, like, some kind of reasonable
Charles:Limit, but…
Charles:And… but I think the most natural thing to do is actually introduce a new transaction type, which…
Charles:Might be in the future, but a neutral action type by gas to use.
Charles:Maybe even by account.
Charles:But, basically we left it out of the CFP because, that could be more…
Charles:Complex in terms of, actually being able to ship the feature.
Charles:So these are just some other things that are in the AP.
Charles:That you can look up.
Charles:Yeah. So…
Charles:This is also, stuff that I already mentioned. I think the main thing is that it gets spent by TX Origin.
Charles:Which is, like, kind of the natural…
Charles:Party that should pay for, these kinds of on-chain payments.
Charles:So, here we have some examples of apps, and I won't spend too much time because, I think everybody maybe kind of gets the point, and the time is limited, but…
Charles:These are just some examples.
Charles:So that you can, like, imagine what it can be used for. So one is, like, you have a DEX, you need to pay the protocol for the swap, and then you use gas to ETH, and then it pays the fee collector contract.
Charles:And these are…
Charles:all kind of, like, actually in the same vein, which is, like, somebody created a smart contract, and you want to use it, and they get paid. This is another one. So, the Oracle Bridge callback, so you, like.
Charles:pay in Oracle, or you pay a bridge, and then…
Charles:sorry, you call an order call or a bridge, and then when you call it, the bridge or the Oracle operator gets paid.
Charles:something kind of like a SaaS contract, so these are, like, pay-per-function, so you want to use some kind of functionality of this contract, and in this particular one, then…
Charles:It does some… Whatever calculation, and then…
Charles:Pays the maintainer address, and then… Finishes the computation and returns.
Charles:And so this allows for, like, very…
Charles:What is it like? Like, micro service, like, super micropayments.
Charles:Like, you can… Like, account for, like, how much should be paid at a very granular level.
Charles:The gas cost model is kind of what you expect. It should, like, basically be the same as pay opcode.
Charles:Yeah, I think this is a good place to end and take questions. There has actually been an…
Charles:a draft implementation for REVM that was based on a previous, version of the EIP, which several of these issues came up that I discussed.
Charles:And there's also an RIP, the 7767, which is…
Charles:has been proposed by Vectra for, L2s to use.
Charles:And that is something that operates in a kind of similar way.
Charles:Okay, let me take a look at some of these.
Charles:questions.
Charles:Interesting.
Ansgar Dietrichs:Yeah, totally.
Charles:Pretty, absolutely, yeah.
Ansgar Dietrichs:chat's very mixed now, because we still have also some conversation from the previous presentations mixed in between. Yeah, first of all, thank you for the presentation. Like, just a quick side mention, one of the other, the ones, not this ERP that you presented, but one of the ones you mentioned, the memory pricing one is also tracked by this
Ansgar Dietrichs:repricing candidates' informational EIP. So this is kind of part of that broader set of
Ansgar Dietrichs:potentially doing some repricings. Concretely on this, on this specific EIP, the gas to ETH, one, do we have questions?
Ansgar Dietrichs:I personally… I voiced some… some… not concerned, the concern is maybe just strong. I'm actually… I think it's interesting, but, like, it definitely feels like it's a… it's one of those i.e. subtle implication changes, so I… for me, it would basically, like, require, like, a high threshold of
Ansgar Dietrichs:And really understanding and thinking through the implications. But yeah, I'd be curious if there's comments. Ben, you have your hand up?
Ben Adams:Yeah, I think it's… I think it's quite interesting, Gasteeth, because people do try and do it in practice, say with tokens.
Ben Adams:In the end, I would like undesirable side effects where…
Ben Adams:you'll take a fee in ETH if it's one side of the trade, or you take a fee in tokens if it's the other side of a trade, for instance. But then, as a result of that, you have to dump the tokens, which, you know.
Ben Adams:People who hold the tokens, they're like,
Ben Adams:And then it also deals with the fact that if it's not something like a token swap where there's transfer of value.
Ben Adams:There are other contracts that… That's simply…
Ben Adams:Can't factor in some kind of payment.
Ben Adams:In an easy way. And also, like, what is it? The… The royalty thing on,
Ben Adams:NFTs, that's like a… A sort of, trust me, bro, we will pay you, but you could, like.
Ben Adams:Bill Diane.
Ben Adams:This kind of mechanism.
Ben Adams:And then it sort of worked with Ether's money, I suppose.
Ansgar Dietrichs:That's a… that's a good point. Yeah, no, but I… I agree, definitely also, and that's why, yeah, it's definitely also very interesting.
Ansgar Dietrichs:Yeah, anyone else also with any feedback on this ERP in particular?
Marius van der Wijden:Yeah, yeah.
Ansgar Dietrichs:assistant.
Ansgar Dietrichs:I know.
Marius van der Wijden:Yeah, I had… I had two questions that I put into the chat.
Marius van der Wijden:One is, what would the interaction with the current AA stuff look like?
Marius van der Wijden:And the other one is, how would the… Transaction format need to change?
Charles:So the transaction format, it doesn't need to change, so it's not in the CIP, it could be added in the future, but basically, it would describe how much gas can be spent by the gas to ETH opcode in this transaction.
Charles:And it's a way for the user to avoid being, griefed.
Charles:But instead, in this version of the IP, it's just, there's a kind of a…
Charles:a constant, I guess, a global thing, which is, like, it's just set to the transaction gas limit that's, normal gas, if that makes sense.
Charles:I don't know if there's any interaction with… Any AA things?
Charles:I don't… I don't think so, really.
Ben Adams:I suppose the issue would be if you bundled lots of transactions together, then…
Ben Adams:One of the transactions could take more gas than…
Ben Adams:You know, if it's saying, here's the gas for 5 transactions, and one of them Takes all of it.
Ben Adams:So it could be… that could be a bundling issue.
Charles:I'm not sure I understand about the bundling issue.
Ben Adams:Well, cause you're saying, I want to send this…
Ben Adams:My first transactions allowed to have one ETH, the second one, one ETH, third one, one ETH.
Ben Adams:But… The first transaction would take all of these, because the transaction as a whole
Ben Adams:This is something you could do in a gas fee.
Charles:Oh, I see. You mean how it interacts with the transaction limit?
Ben Adams:Or how it would interact with bundled transactions.
Ben Adams:Which, like, AI would discuss.
Charles:And…
Charles:I'm not sure I see the issue. Like, that can be true for any kind of thing you do with bundling, right? Like, you might not have enough
Charles:Gas to pay for all the transactions in the bundle.
Charles:That isn't the same as, like…
Ben Adams:Yeah, it's because you're specifying the griefing limit.
Ben Adams:Per transaction.
Charles:Okay.
Ben Adams:But the transaction's composed of multiple transactions. So the first one.
Charles:Alright.
Ben Adams:can go up to the.
Ansgar Dietrichs:Yeah, and I would also say maybe.
Charles:I think that would be, like, a problem of simulation.
Ansgar Dietrichs:you know, one related concern that I would have is that I think we very specifically discourage these days the pattern of sending
Ansgar Dietrichs:bounded gas into subcalls, because that makes assumptions… there's assumptions about details of pricing that we want to obstruct away with.
Ansgar Dietrichs:That's abstraction,
Ansgar Dietrichs:Which means that, in principle, kind of any, any transaction now is fully vulnerable to, to, to basically all the, like, like, like the gas being, being, being consumed for payment, like this.
Ansgar Dietrichs:which…
Charles:Yes, yes.
Ansgar Dietrichs:You can already… oh, yeah.
Charles:It's a separate budget.
Charles:So that's one of the more recent changes to the EIP, which is that it doesn't interact with the gas used by the contract.
Ansgar Dietrichs:But then how can…
Marius van der Wijden:If it's a separate budget, it wouldn't need the transaction type.
Marius van der Wijden:Right.
Charles:The new transaction type would set the limit for the separate budget.
Charles:But, like, let's say that you have a contract column that, needs 100,000 gas, but the gas ETH budget is separate. Like, gas ETH can separately consume 100,000 gas.
Ansgar Dietrichs:Yeah, I think we're getting now pretty into the weeds for the CIP, so we should probably take it offline here.
Ansgar Dietrichs:But yeah, it's definitely… it's definitely an interesting concept. And again, there's probably a lot of skepticism you have to push through first, but it's very interesting, so yeah.
Ansgar Dietrichs:Yeah.
Charles:Marius just said it breaks all gas estimation, but it doesn't. I'm happy to chat with you offline about this.
Charles:What's the best way to…
Ansgar Dietrichs:Like, how… what's the best kind of venue for discussion on this EFP specifically?
Charles:I can make a Telegram group.
Ansgar Dietrichs:That's good. There's also, I think there's here on screen, there's a Minis Magicians, thread as well, on this API, as well.
Charles:and youth nutrition store.
Ansgar Dietrichs:Perfect. Maybe someone's gonna somehow find this and put us into the chat? That would be…
Ansgar Dietrichs:Ideal, I'll also try to find it.
Ansgar Dietrichs:Brownie finds for the first person to do it.
Ansgar Dietrichs:Perfect. Charles, you've got your own brownie points.
Ansgar Dietrichs:M…
Ansgar Dietrichs:Perfect. Then, yeah. Thank you, Chadz, and I would, I would, kind of end that section for now, for here.
Ansgar Dietrichs:Do we have, we have, in principle, 3 minutes left, do we have any last topics that were not on the agenda? Anything someone would want to briefly bring up? Otherwise, you can wrap here.
Ansgar Dietrichs:Yes?
wolovim:Briefly, just a housekeeping item, for…
wolovim:PFI'd EIP is going into Glamsterdam.
wolovim:We've recently agreed to collect a primary point of contact for those, so if we, the protocol support team, will
wolovim:default to selecting whoever opened the PR to PFI that EIP, but we'll ping each of those parties for confirmation. So those names and Discord handles will be…
wolovim:Likely displayed on… on forecast for the benefit of testing teams and Pandops and so on.
Ansgar Dietrichs:Sounds good. Yeah, that's a really good initiative. And Forecast in general, like, I said it off the air already, but, like, also for anyone listening, like, go check out Forecast, it's… it's amazing.
Ansgar Dietrichs:Awesome.
Ansgar Dietrichs:Then if there's nothing else, then thank you all. We ended up taking the full 90 minutes after all.
Ansgar Dietrichs:As I said, in two weeks, we can start the Amsterdam discussion properly, and until then, have a good time. See you all then. Bye.
Justin Florentine (Besu):Nice debut, Nsgar!
Ansgar Dietrichs:Thank you.
Ansgar Dietrichs:Bye, man.
Chat Logs
00:03:52
Parithosh Jayanthi:https://dora.fusaka-sepsf-0.ethpandaops.io/
00:05:48
Marius van der Wijden:Why can they not adjust blobs onf named forks anymore?
00:05:56
Marius van der Wijden:That seems like a weird decision
00:05:58
Barnabas:https://discord.com/channels/595666850260713488/688075293562503241/1425748011438575719
00:06:29
Raúl Kripalani:agree with Marius
00:06:54
Raúl Kripalani:the bpo schedule should be the only place where blob parameters are managed
00:07:14
Raúl Kripalani:otherwise implementations get really dirty
00:07:15
Parithosh Jayanthi:^ that’s disagreeing with Marius tho, its agreeing with pandaops 🙂
00:07:22
Parithosh Jayanthi:He’s saying the oposite
00:07:51
Raúl Kripalani:oh right, apologies
00:08:08
Dustin:this would need to be tested specifically
00:08:45
Dustin:(same epoch for non-BPO and BPO)
00:09:20
FLCL:it's simpler
00:09:25
Raúl Kripalani:right, agree with Pari, that was the original intention
00:09:51
Dustin:Nimbus does some sanity checking because usually, forks cannot be on the same epochs (technically, yes, but the protocol breaks re attestation stuff, I raised an issue years ago on cl-specs on this, anyway, Nimbus prohibits this)
00:10:00
Justin Florentine (Besu):is there a pr with the proposed new el genesis file?
00:10:14
Dustin:I'm not certain what it does with same BPO + non-BPO though
00:10:17
Raúl Kripalani:the EIP already states:
There exists one entry per fork that changes blob parameters, whether it is a regular or a Blob-Parameter-Only fork.
00:11:37
Enrico Del Fante (tbenr):I think we should have some config examples we should support, with various combination across forks so that we can be sure all CLs support that
00:12:27
Justin Florentine (Besu):i proposed an EIP ages ago to standardize el genesis, might be worth revisiting
00:12:41
Raúl Kripalani:Replying to "the EIP already stat..."
also in an earlier section:
To ensure consistency, when a regular hardfork changes any of these parameters, it MUST do so by adding an entry to the blob schedule configuration.
00:13:05
Marcos A. Maceo:Replying to "i proposed an EIP ag..."
that would simplify a lot of things
00:13:07
Barnabas:reminder: we plan to deprecate holesky by end of the month
00:13:32
Justin Florentine (Besu):Replying to "i proposed an EIP ag..."
https://eips.ethereum.org/EIPS/eip-7949
00:14:52
Justin Traglia:How many cores do the holesky nodes have?
00:15:16
Ansgar Dietrichs:did I move on from Holesky too quickly? can return if there was more to discuss
00:15:32
Justin Traglia:Replying to "did I move on from H..."
No, not necessary.
00:15:45
Justin Florentine (Besu):Replying to "did I move on from H..."
you're doin terrific bud
00:15:50
Lumi | Offchain Labs:GETH will
00:16:03
Barnabas:Replying to "i proposed an EIP ag..."
Could we not do “decimal or hex” but rather do one or the other. And stick to one. That way we can compare chickens with chickens
00:16:10
Dustin:Replying to "How many cores do ..."
8 but each runs 4CL/EL pairs
00:16:25
Dustin:Replying to "How many cores do ..."
so effectively each CL has maybe 1.5 cores to work with
00:17:05
Barnabas:Replying to "i proposed an EIP ag..."
also I’d really like if all fields would specify what data type the values supposed to be. Like the blob schedule should be in int
00:17:28
Justin Traglia:Replying to "How many cores do th..."
Hmm I see. Yeah reconstruction on those nodes will be quite slow.
00:17:53
Dustin:Replying to "How many cores do ..."
it's quite a big change, and quite serious for us. Nimbus has never needed even really 2 cores
00:18:35
Dustin:Replying to "How many cores do ..."
it scales up linearly, using recover_matrix, etc, so BPO2 should push this up to 6+ seconds in those conditions
00:19:11
Dustin:Replying to "How many cores do ..."
we of course have parallel reconstruction but it can't be that useful without multiple available cores
00:19:22
Justin Traglia:Replying to "How many cores do th..."
This is for supernodes only though. But yes, it will. Is it possible for ethpandaops to bump system resources?
00:19:51
Dustin:Replying to "How many cores do ..."
it's fine on ethpandaops-run systems, they're not packing CL/EL pairs this tightly
00:20:09
Dustin:Replying to "How many cores do ..."
this is our own testnet deployment setup
00:20:24
Toni Wahrstätter:Felix had a comment about this here: https://discord.com/channels/595666850260713488/688075293562503241/1425142956737695755
00:20:56
Justin Traglia:Replying to "How many cores do th..."
Ah okay. Yeah y'all might need to make some changes then 😅
00:21:10
Dustin:Replying to "How many cores do ..."
exactly, yeah, it's something we're discussing
00:22:23
Dustin:Replying to "How many cores do ..."
but I thought it was worth noting publicly as a Fusaka novelty, that it really just does rule out certain setups or systems as being viable from a CPU perspective. There's some optimization scope here but limited -- at some point even if one spreads this out across an entire slot, etc, it's just not possible to run a supernode with less than about 4 cores free
00:22:43
Dustin:Replying to "How many cores do ..."
exactly because this is mostly a function of how the kzg libraries work
00:24:07
Parithosh Jayanthi:Replying to "How many cores do th..."
But is there value in running a super node on such few resources? A super node represents ~18M USD as of today
00:24:21
Barnabas:Replying to "How many cores do th..."
just consolidate all your validators? That way you total system load would reduce and you could run less El/CL pairs
00:24:22
Dustin:Replying to "How many cores do ..."
for a testnet it represents ~0 USD
00:24:46
Dustin:Replying to "How many cores do ..."
but I take the point, on mainnet it wouldn't make sense
00:25:25
Dustin:Replying to "How many cores do ..."
Barnabus: part of the point is to test large numbers of validators
00:26:39
Ameziane Hamlat:Are you running the block on the same hardware specs, especially disk ?
00:32:24
Parithosh Jayanthi:Stefan is the newest member of ethPandaOps 🙂 expect to see him around glamsterdam topics!
00:32:55
potuz:Wellcome Stefan, a loss to Beaconcha.in
00:33:01
potuz:Welcome
00:33:09
Parithosh Jayanthi:Shh, butta is already asking for a HR fee
00:33:11
Stefan Starflinger:Thanks and hello :)
00:35:46
stokes:breakout tomorrow
00:35:55
Justin Traglia:Nothing EL side that I’m aware of
00:36:02
Justin Florentine (Besu):we kinda rock for moving this fast on BALs, great work all
00:36:26
Parithosh Jayanthi:"BAL-er dev work”
00:36:49
Toni Wahrstätter:BAL implementers, please check out katya's message on the metrics here: https://discord.com/channels/595666850260713488/1364000387195076608/1425488151451013150
00:41:34
Guillaume:8007 is missing 2926
00:42:10
wolovim:https://eips.ethereum.org/EIPS/eip-8007
00:43:16
Ansgar Dietrichs:Replying to "8007 is missing 2926"
ah, do you consider that a reprlcing EIP? I feel like it is more than that, given the tree changes
00:43:33
Guillaume:Replying to "8007 is missing 29..."
it does a lot, but yes it's a repricing eip
00:44:26
Ansgar Dietrichs:Replying to "8007 is missing 2926"
to me “repricing EIPs” are more EIPs that mostly only do repricings. But we can discuss adding 2926 with Maria!
00:45:14
lightclient:have you looked into how these EIPs affect existing txs / contracts?
00:46:27
Toni Wahrstätter:Replying to "have you looked into..."
I did for 7976 and 7981. It's negligible and compared to the block size reduction a quite good trade-off
00:46:46
Charles:maria what is the best way to reach out to you?
00:47:14
Marius van der Wijden:Replying to "have you looked in..."
Some of the others have not yet, since the numbers are not final yet, but we are looking into doing more analysis and outreach
00:47:58
Ben Adams:Replying to "have you looked into..."
This one seems very heavy https://eips.ethereum.org/EIPS/eip-8037
00:48:22
Toni Wahrstätter:Replying to "have you looked into..."
For calldata it's a 33% block size reduction for 1.5% of txs affected (of which most were already affected by 7623)
00:49:43
lightclient:Replying to "have you looked into..."
yeah 8037 is 6-8x’ing everything
00:50:20
Toni Wahrstätter:When would we go through each and decide which ones to ship and which ones not?
00:50:51
Derek Lee:@Maria Silva how can we get in touch with you again? I don’t see you in some of the EF<>Arbitrum chats on telegram. Mind dropping your telegram handle?
00:51:17
Katya:Or Discord
00:51:57
Ameziane Hamlat:Replying to "have you looked into..."
This EIP https://eips.ethereum.org/EIPS/eip-7904 looks also heavy. I wonder how this will work with existing gas limit, as it reduces the cost of most of the opcodes.
00:52:49
Ansgar Dietrichs:note on EIP-8037: The pricing is currently based on very conservative assumptions. That’s a good starting point, but I would expect significant pricing adjustments to the EIP before inclusion (e.g. I would favor lesser pricing increases)
00:52:55
Maria Silva:Replying to "@Maria Silva how can..."
@misilva73
00:53:16
Marius van der Wijden:Replying to "have you looked in..."
Gas will not really mean the same thing after these repricings, but yeah in general compute will get cheaper and persistent state more expensive
00:53:32
Ben Adams:Replying to "note on EIP-8037: Th..."
It would reduce the number of tx per block very significantly
00:54:01
Justin Florentine (Besu):attention everyone interested in genesis.json from earlier: https://github.com/ethereum/EIPs/pull/10502
I can present next ACDE.
00:54:08
jochem-brouwer:Antwoord verzenden naar "@Maria Silva how c..."
@Charles ^ 😃👍
00:57:21
Ansgar Dietrichs:Replying to "note on EIP-8037: Th..."
well it is meant to eventually enable say ~300M gas, which would get us back to the same state growth rate, so at least same tx count
00:57:57
Ansgar Dietrichs:Replying to "note on EIP-8037: Th..."
plus then significantly (up to 10x) more room for any use cases that don’t grow the state
00:58:13
Ahmad Bitar | Nethermind:what if contracts start fractionalizing their storage into multiple deployed contracts just for storage facilitation?
00:58:28
Justin Florentine (Besu):Replying to "what if contracts st..."
might be a feature, not a bug
00:58:33
Ansgar Dietrichs:Replying to "note on EIP-8037: Th..."
but yes, I think already pricing with a 300M throughput level in mind is a bit too cautious imo
00:58:42
Ahmad Bitar | Nethermind:Replying to "what if contracts st..."
yeah, asking if this is a desired outcome
00:59:03
Justin Florentine (Besu):Replying to "what if contracts st..."
i interpreted it as desired
00:59:07
ignacio:Using the worst-case depth of a storage trie means somebody can attack a storage trie to create a long branch and make all writes very expensive? (even if the contract is somewhat empty)
00:59:07
Ansgar Dietrichs:Replying to "what if contracts st..."
yes, that would mean that any state access would be more shallow, so more efficient
00:59:35
jochem-brouwer:Antwoord verzenden naar "Using the worst-ca..."
the keys in the storage trie are hashed, so this needs a lot of trail-and-error (and is thus not trivial)
00:59:39
potuz:Was there an explanation why 1 contract of size 2S is worse than 2 contracts of size S?
00:59:59
ignacio:Replying to "Using the worst-case..."
Yes, but sounds practically doable since you have time
01:00:14
Marius van der Wijden:Replying to "Was there an expla..."
contract tries can be computed in parallel during state root computation
01:00:54
Ansgar Dietrichs:Replying to "Using the worst-case..."
we could also consider variants, where for the block gas limit (and tx gas limit) we consider the worst case, but for pricing we have a more forgiving logic (e.g. just based on total storage item count)
01:02:07
jochem-brouwer:Antwoord verzenden naar "Using the worst-ca..."
right it is indeed practically doable, not sure here. also if it is solved once (for a set of storage keys to write to) it is thus solved for other contracts also (just write to those keys, given there is thus an exectution path to do so - for ERC20 contracts which have approvals laid out at the same slot one could "mine" a generic set to attack the depth)
01:02:24
jochem-brouwer:Antwoord verzenden naar "Using the worst-ca..."
(and thus could attack all erc20s with that storage layout to increase depth)
01:02:57
Mario Vega:The gamma variant of this EIP seems to me that would hurt the parallism gains that BAL would introduce or am I missing something?
01:03:37
Ben Adams:Wouldn't be able to do async Sstore; as prior sstores would effect cost of next?
01:03:58
Marius van der Wijden:Replying to "Wouldn't be able t..."
Updates only happen at the end of the block
01:04:00
Wei Han Ng:Replying to "Wouldn't be able to ..."
the cost of new sstore is determined in the next block
01:04:31
Mario Vega:Replying to "Wouldn't be able to ..."
That makes a lot of sense, thanks
01:04:31
lightclient:how does this EIP relate to unification of state tree?
01:04:46
Toni Wahrstätter:Replying to "The gamma variant of..."
I was thinking the same but the pricing i uupdated on the block-level I think
01:05:06
potuz:Still didn't get it lol
01:06:07
Guillaume:Replying to "Still didn't get i..."
write me :)
01:06:18
Wei Han Ng:Replying to "Still didn't get it ..."
basically:
accounts add new depth field
at the end of block, calculate the deepest depth, update if needed
sstore cost changes
01:06:50
Karim T.:Replying to "Still didn't get it ..."
Next sstore in a future block. Not the current one
01:07:53
Guillaume:Replying to "The gamma variant ..."
yes it's orthogonal because any update to the costs is only activated at the start of the following block
01:07:56
Marius van der Wijden:can someone link the eips
01:08:26
Toni Wahrstätter:Replying to "Still didn't get it ..."
I guess we wouldn't need the depth in the BAL as it's not changing during the block. Just thinking out loud..
01:08:31
jochem-brouwer:https://eips.ethereum.org/EIPS/eip-7907
https://eips.ethereum.org/EIPS/eip-7903
https://eips.ethereum.org/EIPS/eip-5920
https://eips.ethereum.org/EIPS/eip-7923
https://eips.ethereum.org/EIPS/eip-7791
01:08:50
draganrakita:Replying to "Wouldn't be able to ..."
Am I saying correctly that depth for storage would depend on 16^N, that means that barriers for sstore bump are, 16, 256, 4096, 65536, 1048576 items
01:08:57
Guillaume:Replying to "Still didn't get i..."
it's part of the account, so if you have account data in the bal, you need to have that as well
01:09:11
Ansgar Dietrichs:Replying to "Still didn't get it ..."
I do think this discussion hinted at an aspect that should be studied more:
For a single access, state split across several shallow contracts instead of one deep is indeed more efficient.
but for multiple accesses, that is not so clear, because we are now losing the amortization effect of shared partial branches of the deep tree of the single contract
01:09:32
Guillaume:Replying to "Still didn't get i..."
but yeah, you don't need diffs because it only updates for the next block
01:10:25
Wei Han Ng:Replying to "Still didn't get it ..."
we wouldn't need the depth in the BAL
for parallel execution maybe not, but something else that relies on the state diffs from BALs then yes
01:10:26
draganrakita:Replying to "Still didn't get it ..."
Depth of 4 would have 65536 items, trie is not that deep
01:11:25
potuz:Replying to "Still didn't get it ..."
@Guillaume What I don't understand is the justification of the change, not the change itself, that was clear. What's not clear to me is why would it make it better to force people to spread large amounts of data across different contracts. I kinda buy the argument that expiring parts would be easier, but that can't solely be the reason right?
01:13:39
potuz:Replying to "Wouldn't be able to ..."
multiplied by K, wasn't clear if K was forced to be integer
01:13:55
Ansgar Dietrichs:I haven’t thought the implications of gas2eth through yet, but it seems very opinionated / possibly dangerous
01:14:03
Toni Wahrstätter:Replying to "Still didn't get it ..."
Right yeah, we'd still need it in the BAL to maintain a conplete state diff
01:14:03
Ansgar Dietrichs:Replying to "I haven’t thought th..."
to ship it to an existing chain
01:14:14
Toni Wahrstätter:Replying to "Still didn't get it ..."
Would be an easy add though.
01:14:16
potuz:Replying to "Wouldn't be able to ..."
just that the behavior be exponential
01:14:33
Ansgar Dietrichs:Replying to "I haven’t thought th..."
not saying that it’s necessarily a bad idea, I would just really want to be certain it’s a good idea
01:14:41
Marius van der Wijden:Replying to "I haven’t thought..."
Also would like to hear more about the interaction with current AA flavors
01:15:17
Guillaume:Replying to "Still didn't get i..."
@potuz the reason is that when a contract's storage becomes deep enough, that becomes a bottleneck. There's only one contract in the state that this is a problem for, but we want to disincentivize that.
01:16:35
potuz:Replying to "Still didn't get it ..."
ok so assuming you are referring about the XEN issue, am I reading correctly that the issue is only depth and it's independent of the contract logic?
01:17:07
Ansgar Dietrichs:I have minor audio issues, not sure if on my end or Charles’
01:17:12
Justin Florentine (Besu):same
01:17:15
Ansgar Dietrichs:Replying to "I have minor audio i..."
mostly fine though
01:17:27
potuz:Replying to "Still didn't get it ..."
This sounds to me that it's an implementation issue and not a fundamental issue of resource utilization which is what gas should account for
01:19:38
Ben Adams:Replying to "I haven’t thought th..."
Is interesting; as people try to do it in practice but very hacky and with undesirable side effects
01:21:02
jochem-brouwer:the eth from this payment comes from the eth what would normally get burned if i understand it correctly.
a problem i would see here is that one can now fill a block for free? so you dont burn eth, you pay yourself back, but you would fill the block against the gas limit. even though this would not change base fee (?) it would immediately fill the block? so no other txs can hop in?
01:21:33
Luis Pinto | Besu:How would GAS2ETH differ from the PAY opcode? What advantages are there? Maybe I didn’t understand it fully
01:21:45
Wei Han Ng:Replying to "Still didn't get it ..."
If trie depth of a contract storage increases, then resource utilization (disk IO) will also increase, so the gas cost changes does account for that
01:22:06
Marius van der Wijden:Whats the change to the transaction format look like? do we need a new transaction type?
01:22:50
Charles:Replying to "How would GAS2ETH ..."
gas2eth uses gas, it also spends from tx.origin
01:22:59
Charles:Replying to "Whats the change t..."
it's not needed, can be added in the future
01:22:59
potuz:Replying to "Still didn't get it ..."
yes, but I fail to see why storage split across contracts is better than the same data in a single one from this perspective. The node is not forced to have a disk representation that mimics what the state has in a paper representation
01:23:15
potuz:Replying to "Still didn't get it ..."
That's what I mean by an "implementation detail" and not a resource allocation issue
01:25:11
Guillaume:Replying to "Using the worst-ca..."
it's not practically doable. For one thing, you'd have to do a 9 byte collision, which is still hugely expensive, and for a 2nd thing, you attack would be thwarted at the next fork by increasing the max depth.
01:25:29
jochem-brouwer:Antwoord verzenden naar "the eth from this ..."
nvm, should read the eip better first
01:26:16
Marius van der Wijden:Would break all gas estimation :(
01:27:26
Guillaume:Replying to "Still didn't get i..."
it's independent of the contract logic, yes. It is a resource utilization issue though, because more depths means more hashes, and these are sequential operations (per branch).
01:27:40
Charles:Replying to "Would break all ga..."
it doesn't
01:28:24
Charles:https://ethereum-magicians.org/t/eip-7791-gas2eth-opcode/21418
01:28:25
potuz:Replying to "Still didn't get it ..."
ah thanks, this explains it to me
01:28:47
jochem-brouwer:Can this PR which PFI's an EIP for Glamsterdam be merged? https://github.com/ethereum/EIPs/pull/10452
And these also :) (also PFI PRs)
https://github.com/ethereum/EIPs/pull/10453
https://github.com/ethereum/EIPs/pull/10494
01:30:07
Christine Kim:woo!
Summary
18 highlights
· 1 decisions · 3 action itemsExperimental
Summary
18 highlights · 1 decisions · 3 action itemsExperimentalfork status and schedule
client updates
testing progress
repricing updates
- EIP-8007 bundles all Glamsterdam repricing proposals for tracking (informational only)00:39:23
- EIP-7904: Major compute repricing making most operations cheaper; harmonizing costs00:40:16
- EIP-8037: ~10x increase on state creation costs; independent co-deposit metering00:43:48
- EIP-8032: Dynamic S-Store pricing based on contract storage depth (exponential scaling)00:55:49
- EIP-8032 uses separate gas budget to avoid burn/coinbase accounting conflicts00:58:04
organizational
Decisions
- BPO schedule updates decoupled from named forks; only BPO numbers in Genesis00:09:11
Action Items
- EL client teams: Review EIP BPO schedule changes: remove named fork fields from Genesis00:05:12
- Maria Silva + community: Investigate backwards compatibility for repricing EIPs; gather breaking change feedback00:48:46
- Interested parties: Discuss EIP-7791 implications in Ethereum Magicians thread01:28:24