Toni Wahrstätter:Awesome, thank you very much.
Transcript
Toni Wahrstätter:Welcome, everyone! Today is the 13th EIP-7628 breakout call. It's February 25th… 25th?
Toni Wahrstätter:And we have quite a… some items on the agenda, nothing,
Toni Wahrstätter:Nothing super new, nothing surprising. As usual, the first thing we have on the agenda, I just posted it into the chat, by the way, the first thing we have on the agenda is updates on client optimizations.
Toni Wahrstätter:just as a… to recall, we need the client optimizations for the repricing, benchmarking required for the Glamsterdam repricing EIPs.
Toni Wahrstätter:And it would be great if we get some updates from clients,
Toni Wahrstätter:about progress within the last two weeks on parallel I.O, especially.
Toni Wahrstätter:So, feel free, any, anyone from my client team, to provide us an update.
Karim T. (matkt):I can't start on Besu, so…
Karim T. (matkt):We still have the different optimization already implemented, so we had time to do some… Optimization… Hmm, on Zoom.
Karim T. (matkt):pRethetch, and also on some other stuff in the block access list branch.
Karim T. (matkt):We also implemented the max attempt check and the uniqueity of the validemp, so we are waiting for the test when they will be available.
Karim T. (matkt):And, we asked… we started to work on IT71, and, I think it's mainly that, yeah.
Karim T. (matkt):Yeah, it's all on Besu.
Toni Wahrstätter:Great, thank you very much. Do you already have, like, first numbers?
Toni Wahrstätter:Did you already look into benchmarking, especially the batch I.O?
Karim T. (matkt):Not really. We are using, for the moment, the devnet 2, so it's not really interesting, regarding the number we have.
Karim T. (matkt):We didn't see a lot of differences, because,
Karim T. (matkt):It's not similar to mainnet, so…
Karim T. (matkt):We are mainly working for the Shadow Fork of mainnet to have really good numbers.
Toni Wahrstätter:Right, yeah, that's a good point, because of course we need, like, realistic state to actually benchmark the batch I.O. We can benchmark the parallelization, that's something we can do, especially with execution parallelization, not involving any I.O.
Toni Wahrstätter:or state rights?
Toni Wahrstätter:And, yeah, thank you very much.
Toni Wahrstätter:Let's continue maybe with, do we have someone from Geth on the call?
Toni Wahrstätter:Okay, don't think Jared is on the call… yet. Let's skip Geth for now.
Toni Wahrstätter:Let's continue with Nethermind, then.
Toni Wahrstätter:I just see Mark is also not on the call. Then we continue with Reth.
Toni Wahrstätter:Okay, I would just assume there are no updates on the optimizations there.
Toni Wahrstätter:Does Erigon have updates on the free-to-friend optimizations?
Toni Wahrstätter:Okay, yeah. Seems like not much changed since the last two weeks, so we are still at, having Geth and Beso ready to be
Toni Wahrstätter:benchmark, especially on a shadow fork.
Toni Wahrstätter:I would then pass the word. I see Jochman has your… has his hand up anyway. I would have passed the word to you anyway, because I know that you guys have already looked into, benchmarking Bezo and Geth on top of the Shadow Fork, and on top of devnet2. So, yeah, please provide us an update there.
jochem-brouwer:Yes, so, for the benchmarks, we are writing these benchmarks, and as you said, we indeed need to run these on top of, like, states, like, mainnet state or roadnet state. The problem is that we have to fill these tests, and for this, we have this testing endpoint, this new testing RPC endpoint, and that
jochem-brouwer:does not yet, support the Glamstadem, EIPs.
jochem-brouwer:The problem here is that we need one client which can support this endpoint, because then we can actually fill these benchmarks on top of state, because it does not make sense to run, like, batch I.O. tests on top of, like, empty state.
jochem-brouwer:So we are waiting for this. If we have this testing endpoint, then we can start to fill these benchmark tests and actually win those. So that's the update on the benchmark side.
Toni Wahrstätter:Thank you very much. Just to clarify, this means we… we would need a client that has block of accesses implemented, but not any other EIP that we already have on devnet 1 and 2, is that right?
jochem-brouwer:It depends on what we actually want to test, because, so this testing endpoint, what it needs to do is it has to build blocks
jochem-brouwer:with the supported EIPs which we want to test, I would think that we want to target devnet 2 or devnet 3, so, like, multiple EIPs, and this is the part which needs to be supported on, like, the block building part.
jochem-brouwer:So if the client can win these blocks, then that's, of course, very nice. But the thing is, we need to just fill these tests once, so we can generate the payloads to benchmark these EIPs.
jochem-brouwer:And this is currently not yet implemented in any client, so we need one client.
jochem-brouwer:which implements this endpoint to support, like, these EIPs which we want to test. And just one client is fine, like, not all the clients need this. One client to fill, and then we can actually start filling the benchmarks and also running those.
Toni Wahrstätter:Awesome, thank you.
Toni Wahrstätter:I saw Jared from GEF joins in the meantime. Jared, would you be willing to provide us an update on
Toni Wahrstätter:The bul optimizations, if there are any.
Toni Wahrstätter:Especially the batch I.O.
Jared Wasinger:Yeah, I mean, so it's…
Jared Wasinger:like I mentioned on the, on the channel, there's…
Jared Wasinger:Really, not much has changed since the last meeting.
Jared Wasinger:Or,
Jared Wasinger:Maybe it has, I just can't remember. So there's… there's a few, like, execution option presets.
Jared Wasinger:that I've implemented for Geth,
Jared Wasinger:Yeah, I mean, the batch I.O. is able to be toggled, the parallel execution and state route is also able to be toggled. I haven't…
Jared Wasinger:made…
Jared Wasinger:I haven't really worked on that, since I implemented it. I've been busy with other stuff, so there's not really an update in the last week or two.
Toni Wahrstätter:Okay, thank you very much. Yeah, it seems like GEF and Bezo are ready for being benchmarked in that case. I saw both clients have already provided us with the necessary flags, such that we can turn the optimizations on and off, which is great, so thank you very much for that.
Toni Wahrstätter:And yeah, as soon as other clients are ready, especially since we agreed on focusing more on the batch I.O, because we still need to…
Toni Wahrstätter:we not only need the batch.io to determine the final prices for the repricing changes in Glamsterdam, but we also need it to determine if we want to keep the state locations in the ball in first place.
Toni Wahrstätter:So, that's why we originally said, like, yeah, let's optimize the batch.io optimizations first, and, like.
Toni Wahrstätter:If that means we delay, for example, the powerless debut root computation, then this is fine. But this is great to hear. This means, okay, we still have, like, two clients being basically ready, and yeah.
Toni Wahrstätter:as soon as other clients get ready, just please post it into the… into the BlockFlive Access List Discord, and then we can start,
Toni Wahrstätter:benchmarking more clients on… on a shadow fork, or on devnet Free.
Toni Wahrstätter:Great.
Toni Wahrstätter:Is there anything else before we move on on the agenda regarding the optimizations that we should discuss now?
Toni Wahrstätter:Seems like not the case.
Toni Wahrstätter:then we can move on on the agenda. So, the next agenda item we have is specs updates slash clarifications, and nothing major changed within the recent two weeks. It was more like we had two EIPs merged, two PRs merged.
Toni Wahrstätter:The first one was a clarification to the EIP how the ball is used in the state transition function.
Toni Wahrstätter:And this is more like a clarification, because some clients will pass the ball in the state transition function, and in the specs, for example, we don't do that. In the specs, you receive the bul over the engine API, you would calculate the ball hash.
Toni Wahrstätter:And then you would start exec- executing, and… You would…
Toni Wahrstätter:Generate a virtual ball during execution, and in the end, compare the ball hash of this virtual ball that you created during execution with the bul hash in the header.
Toni Wahrstätter:That was derived from hashing that BAL received over the engine API. And this is just a clarification, because I know, for example, comparing GEF with the specs, this is a little bit of a different implementation.
Toni Wahrstätter:Which doesn't affect, like, correctness at all, but more like to have that clarified in the EIP.
Toni Wahrstätter:Let me actually post the PR in the chat, such that everyone can have a look.
Toni Wahrstätter:While we're talking… One second… Someone did already, thank you very much, Radipa.
Toni Wahrstätter:Perfect.
Toni Wahrstätter:Is there anything… Someone wants to discuss regarding that topic.
Toni Wahrstätter:Perfect. Yeah, this is more like a clarification than actual change.
Toni Wahrstätter:Then let's move on with the next item, which is the simplified file max item check. So, we had that already before the last breakout call, but in the last breakout call, I remember Mark
Toni Wahrstätter:Brought up that,
Toni Wahrstätter:We might also want to account for bul items that get into the ball for free.
Toni Wahrstätter:And those items that enter the ball for free are basically all connected with system contract calls, because every other item in the bell
Toni Wahrstätter:has actually some gas attached to it, so you cannot just put something into the bulb without accessing it, which means there's always some gas cost, attached.
Toni Wahrstätter:But this is not the case, for example, for everything system contract related, because no one actually pays for it.
Toni Wahrstätter:And this affects, withdrawals, execution requests.
Toni Wahrstätter:Our execution layer triggered, exits and consolidations.
Toni Wahrstätter:And also the pre-execution, system contract calls, like the historical state route.
Toni Wahrstätter:Historical block root hashes, and the…
Toni Wahrstätter:The 4788 beacon block route in the, in the block.
Toni Wahrstätter:So, what we wanted to do with this check, it should only be a safeguard against invalid blocks.
Toni Wahrstätter:that takes longer to execute than any valid block would do. And with this max item check, together with the other check we introduced, like, 2 weeks ago, where we compared
Toni Wahrstätter:Not yet accessed dollar items with the remaining gas.
Toni Wahrstätter:clients should be safe against those type of attacks. It's not a super dangerous attack, I would say, because, of course, it would also require the proposer to sacrifice its block.
Toni Wahrstätter:But still, we must make sure that even invalid blocks don't take longer to invalidate than a valid block takes to validate.
Toni Wahrstätter:Let me post the, link of this PR into the chat. This was just a, clarification of the EIP.
Toni Wahrstätter:And I know the EU's specs PR on that topic is still open, and there's still some discussion. So I'm curious. Maybe, Felipe, do you have
Toni Wahrstätter:Any more to add regarding that topic, so we…
Toni Wahrstätter:clarify something in EALS, or is everything good to go?
felipe:Yeah, so… As I was reviewing the max item check PR,
felipe:It looks good there. I think, you know, between Mario and I, we were discussing that the… the fact that it's under security considerations and
felipe:Let me see if I can pull up the actual,
felipe:Comment and post it, but, this part here… Basically, the words should,
felipe:in the PR, for the spec change?
felipe:It feels a little, underspecified, whether, you know, this constraint needs to…
felipe:Actually be there for clients, and whether… It basically…
felipe:Here, this is the link for Mario's comment.
felipe:It's basically hard to draw a very clear line on whether
felipe:We can test this for clients.
felipe:And so, I think we… you know, I think a better explanation of whether this is required,
felipe:or not is… would make this clearer, and it would allow us to, like, actually put this in the EALS implementation and write tests for it. And I know clients are expecting tests for this, so…
felipe:I wanted to know how you feel about, like.
felipe:Making this a little bit more, concrete and more explicit.
Toni Wahrstätter:Yeah, it's a good… it's a good point, because I was… I was thinking about this.
Toni Wahrstätter:The thing is, we don't put the bul that you receive over the engine API, we don't have it as an argument in the state transition function. So, for example.
Toni Wahrstätter:We can…
Toni Wahrstätter:We cannot do the… the check where we do… where we look at the not-yet-accessed bul items and compare them with the remaining gas.
Toni Wahrstätter:Because we don't have the block lab access list within the state transition function in the block lab access list. So this is more something that would be done outside
Toni Wahrstätter:And the thing is, you know.
Toni Wahrstätter:Theoretically, you don't need that check, because it only allows you to invalidate the ball quicker.
Toni Wahrstätter:So clients may need that, just to make sure that they can invalidate files quicker than executing the whole block, but in the end, you would arrive at the same result. So the block is invalid, it's just a matter of when would you realize that the block is invalid.
Toni Wahrstätter:So I'm not sure what is the best, the cleanest way to implement that in EOS. One way would, of course, be to just throw the ball into the state transition fraction, but I think we don't do that. And then the question is.
Toni Wahrstätter:it's two things. It's first the max item check, and then the other check where we
Toni Wahrstätter:basically determine, is there enough gas available to access the remaining not-yet-accessed bulb items?
Toni Wahrstätter:So I'm curious, what… how do you think? Because I think we haven't really specified
Toni Wahrstätter:this code path between the engine API and the state transition function in ELS. So basically, what happens in between there.
felipe:Yeah, yeah, no, I see what you mean.
felipe:It feels like if this is… if this is some early check for clients, then maybe this could be some sort of a benchmark test for clients, where
felipe:You know, let's say there's some worst-case malicious bowel test.
felipe:And from the… from the spec side, we could… we could have some benchmark tests that benchmarks how quickly clients can invalidate this.
felipe:If it feels like this is the end goal.
felipe:But as far as, you know.
felipe:Adding this to the spec, yeah, it's a little tricky, and having tests for something that isn't,
felipe:There's an S clear in this back.
felipe:I'll have to think on this some more.
Toni Wahrstätter:Okay.
Toni Wahrstätter:Yeah, we can also… we can also chat async, because the first thing that Max, I can check, we can do it in the specs. This is nice, because we generate the virtual ball, and we can then just validate the block level access list after execution, making sure that
Toni Wahrstätter:those, that there is not, like, the maximum item limit is not exceeded. Like, we can do that.
Toni Wahrstätter:But for the other check, that's why… that was my rationale, why I put, like, the remaining gas check in the security consideration section, and the other one into the specs. But yeah, let's… let's talk, async about that, and… and yeah, clarify that.
felipe:Okay, Yam, that sounds good.
Toni Wahrstätter:Perfect, yeah, and this is… this already brings us directly to the next topic, basically the uniqueness of PAL items. This was also, like, recently added to the EIP.
Toni Wahrstätter:I think we are good there, because many of our tests already assumed, like, the ball is built correctly, meaning there are no duplicated entries, for example, duplicated addresses or duplicated.
Toni Wahrstätter:storage changes or anything, so I think we're good on that.
Toni Wahrstätter:But yeah, I think we still added some new tests there, right?
felipe:Yeah, yeah, from some comments on the, on the ETH R&D,
felipe:We didn't really have a whole lot of invalid tests based around
felipe:duplicates and things like this, so yeah, there was a PR merged. It's not on any of the releases yet, but it should be out on the next one.
Toni Wahrstätter:Perfect. Thank you very much for the update.
Toni Wahrstätter:Is there anything… People want to discuss regarding those two topics?
Toni Wahrstätter:I see Karim is also saying in the chat that Baseway is also checking the order of the keys.
Toni Wahrstätter:Do we have a test for, the ordering of the ball items being correct?
Toni Wahrstätter:I'm not sure anymore, actually. Do you know Felipe, or maybe Rahul is on the call? Can someone?
raxhvl:Yep.
raxhvl:They do have…
Toni Wahrstätter:We do have, okay, perfect.
Toni Wahrstätter:Amazing, thank you.
felipe:What is the… R-ruh.
Toni Wahrstätter:Go ahead.
felipe:Do you know which test this is, Rahul?
raxhvl:I think it's in the invalid test, where we,
raxhvl:we have those bound modifiers that change the order, right? You made those API.
felipe:Yeah, yeah, I believe there… we have some, and I'll double check.
Toni Wahrstätter:Awesome, thank you very much.
Toni Wahrstätter:Great. Is there anything the clients would like to add regarding those
Toni Wahrstätter:Three topics that we discussed now, basically the max item check on the barrel, then also the check of
Toni Wahrstätter:Remaining gas versus not-yet-touchable items, and…
Toni Wahrstätter:the uniqueness of ball items, is there anything people want to discuss on that topic?
Toni Wahrstätter:Great.
Toni Wahrstätter:Looks like things are clear.
Toni Wahrstätter:Awesome. Then we can… proceed with the next agenda item, which would be the Chase and RPC PR.
Toni Wahrstätter:I saw that, I saw that some clients had already implemented the JSON RPC for devnet2,
Toni Wahrstätter:there were some recent changes with not returning, like, the hex string, but instead returning the JSON object.
Toni Wahrstätter:And I would love to hear if clients have updates on that, if this is, like, ready for definite free.
Toni Wahrstätter:Or remind me if I'm wrong, I think we said we wanted to have that definite free already, but please correct me if I'm wrong, but I think we did.
Toni Wahrstätter:So, I would just assume, clients will have that implemented.
Toni Wahrstätter:What would be great if someone from the client team could confirm?
Karim T. (matkt):Yeah, on PZU, it's already implemented, yeah.
Karim T. (matkt):So API is implemented.
Toni Wahrstätter:Awesome, thank you very much. I just posted the PR in the chat, such that everyone can follow along.
Toni Wahrstätter:Yeah, it's nothing that blocks us from devnetly or anything, but yeah, would be great if we can have that implemented and then get it merged.
Toni Wahrstätter:I mean, usually we should get it merged, before clients implement it, so I will… I will double-check why this is, not yet merged. I have to…
Toni Wahrstätter:I have to double-check that. I think this will also be brought up in the RPC standards call.
Toni Wahrstätter:So, I will also have to double-check with, Omar if she has any updates on that,
Toni Wahrstätter:Because, of course, yeah.
Toni Wahrstätter:double-checking with the experts on our PC is definitely the right way to go there before we merge it.
Toni Wahrstätter:Great.
Toni Wahrstätter:This was…
Toni Wahrstätter:everything we had around the specs. Is there anything we should discuss this week regarding specs or tests? Any updates?
Toni Wahrstätter:Looks like that's not the case, which is good.
Toni Wahrstätter:And then we have a last agenda item by, Goron, Dan.
Toni Wahrstätter:I hope I pronounce your, GitHub handle right here.
Toni Wahrstätter:who wants to talk a little bit about the feasibility of using BAL
Toni Wahrstätter:For the payload needed by partial stateful nodes.
Toni Wahrstätter:So, could you give us a quick intro into what are you looking into there, and…
Toni Wahrstätter:Yeah, anything you would like to know.
Dan Goron:What about the…
Toni Wahrstätter:progress here.
Dan Goron:Hi, Tony. Hi, everyone. Nice to be… Participating in your call.
Dan Goron:Yes, Don… then go on its, right? Enough.
Dan Goron:together with, with Carlos, Perez from, this, Ethereum stay close team. We're…
Dan Goron:Pushing a bit the concept of,
Dan Goron:Of partial, statefulness, and we were looking to get, your…
Dan Goron:people, you know, the opinion of people that work on… on BAL about If we could use
Dan Goron:ball as a vehicle for.
Dan Goron:For the account, hash diffs, which are basically, the… The payload that you mentioned.
Dan Goron:I left… I left, a TLBR on partial statefulness, on the…
Dan Goron:On the comment, and on the call's comment.
Dan Goron:I can reiterate, very quickly.
Dan Goron:The idea that, That's behind the partial statefulness, and that's…
Dan Goron:That if we get nodes to store a minimum data set,
Dan Goron:From… from the, you know, to persist locally a minimum part of the state.
Dan Goron:Then we could get them to be…
Dan Goron:Coherent under the state route.
Dan Goron:And basically keep up with the… Duh.
Dan Goron:Canonical state root, or the global state root, and then be able to store only certain parts of the state.
Dan Goron:But those parts, if we can look at them From the topological, from a topology-based view.
Dan Goron:Meaning, for EL account state, and then contracts, contract storage, and code. And there's also part of CL, which is… I didn't add, it's not the scope of this call, but also CL state can be viewed.
Dan Goron:you know, from the perspective of functional, state subtrees, so to call them. So, to go in, straight into the… into the point why I wanted to… why we wanted to, to talk to you guys.
Dan Goron:Is that we can boil our, proposal into three…
Dan Goron:main points. So if we can get every node to store the 32-byte commitment, that constitutes the count leaf.
Dan Goron:which is account hash. Then, this is a dataset of approximately 10 gigs for 300 million accounts.
Dan Goron:Then the nodes would, become globally root-aware, so to speak.
Dan Goron:Ball already provides Full state diffs.
Dan Goron:Which are,
Dan Goron:which take care of update… of nodes updating state values. If… if we can add to ball or to…
Dan Goron:Another vehicle, the hash diffs.
Dan Goron:Which are structural, state.
Dan Goron:I don't know.
Dan Goron:Mom.
Dan Goron:Which is a structured state.
Dan Goron:Yeah, correctly, correct me if I'm wrong.
Dan Goron:Then… Nodes would be able to update those stored account hashes without re-execution, and that basically unlocks
Dan Goron:The first level of partial statefulness, functionality.
Dan Goron:by…
Dan Goron:nodes being able to update old account hash into new account hash for every address that has been touched by the block's transaction. Then rehash everything up to
Dan Goron:To straight root and match, you know, the, the result with the, with the…
Dan Goron:State root… with the root that's in the blocks.
Dan Goron:Heather.
Dan Goron:I also added some high-level specs change proposal, and I would be very grateful if I would get some
Dan Goron:opinion on that. If… if my assumptions were, correct.
Dan Goron:Meaning that we can get the pre-state captures from the… from the transaction frame level.
Dan Goron:And that we can get the post state.
Dan Goron:values, you know, from building Ball, from actually building Ball.
Dan Goron:That's it. Please let me know if…
Dan Goron:I should continue or have an open discussion.
Toni Wahrstätter:Yeah, thanks a lot for this intro. Very interesting topic. Let me just ask a quick question regarding partial statelessness. What would those nodes actually store? I assume they store, like, nonsense and balances, maybe code? Is there anything from storage they would also store?
Dan Goron:So,
Dan Goron:Let's clear the name first. It's partial statefulness. So, basically, it's not statelessness, it's not strong statelessness, as in stateless…
Dan Goron:notes, as we are… as we already heard it a lot of, you know, in the… in the community and in the development, in the R&D, discourse.
Dan Goron:So it's partial statefulness, so they would store something, and that would be, as a minimal requirement, that would be the mapping between
Dan Goron:each address.
Dan Goron:For all accounts, and their account hash, which is the commitment of balance, nouns, code hash, and, contract,
Dan Goron:Hash. What's the correct expression here?
Dan Goron:I see. The nouns, balance, storage root, and code hashing.
Toni Wahrstätter:Okay, and you would basically, for this to work, you would also need the account hashes to be part of the ball, is that correct?
Dan Goron:Yes, the account hash diffs, meaning a pre-state account hash, which basically would have to match the existing locally persisted account hash, and the new account hash, which is
Dan Goron:Post.
Dan Goron:post-execution, or executing the transaction, and then we get a new, the blocks transaction, and then we get a new account.
Dan Goron:Hash.
Toni Wahrstätter:Okay.
Dan Goron:Both these values should be in the payload, yeah.
Toni Wahrstätter:And both of those values would be 32 bytes per account.
Dan Goron:Yep.
Toni Wahrstätter:Okay, perfect. Yeah, it's a very interesting topic. This is definitely relevant for the future. We already talked about that a bit ASIC. Of course, this… I mean, yeah, this will not happen for Glamsterdam.
Toni Wahrstätter:But this is definitely something relevant for the future that we should keep discussing. So I would say we can take this async, and it's great that we have now many of the clients also being aware of that topic.
Toni Wahrstätter:One thing I would initially say we have to, of course, find out, well, like, what is the worst case? Like, could the ball be inflated with, or bloated with many of those 32 byte values?
Toni Wahrstätter:Initially, I would say no, of course. For each touched account, or for each changed account, you would then add
Toni Wahrstätter:64 bytes in addition to the ball, so we should definitely, determine, like, what is the worst case ball size with adding those additional bytes. But apart from that, I don't see, like, any issue right now.
Toni Wahrstätter:Jochen, do you want to add something to that?
jochem-brouwer:Yes, so currently what you store is an address to the account hash, so that's 32 bytes, and this account hash is, I think, the hash of, like, the balance that wants the coder root and the state root. Is that correct, Dan?
Dan Goron:Yes, I think, if I understood correctly what you asked, I think, yes, the answer is.
jochem-brouwer:Yes. So, what I would propose to change this, actually, is to store, not the account hash, but actually the code hash and the state root into your partial, stateful node.
jochem-brouwer:doubles the size, so 64 bytes, it's now not 32 bytes, but what you can now do from the bulk access list, you now know the changes in the months and the balance, so you can actually reconstruct the new account tree, because you already have the code hash and the state root. Oh, wait, no, there's a problem with that.
Dan Goron:But I think for post-state, that would be correct, what you say, but I don't think for priest… would it be correct for pre-state?
Dan Goron:What do you mean?
jochem-brouwer:I am.
Dan Goron:measurable.
jochem-brouwer:Yeah, no, I need to think about this a little bit longer. Yeah, let's take this async.
Toni Wahrstätter:Yeah, that's students.
Dan Goron:Okay, thanks.
Toni Wahrstätter:Let's have a discussion. I can set up a Discord group between the three of us first, and then we can hash that out a bit.
Toni Wahrstätter:And, yeah, it's great that we have brought it up. Thanks a lot, Dan.
Dan Goron:Perfect, guys, thank you for listening.
Toni Wahrstätter:Of course, thank you very much.
Toni Wahrstätter:Yeah, this is then already the last agenda item that we had for today's call. Is there anything else that clients would like to bring up that we should discuss today, especially focusing on devnet coming up?
Toni Wahrstätter:Awesome.
Toni Wahrstätter:Looks like everything is clear.
Toni Wahrstätter:Dan, thank you very much, everyone, for attending the call, and see you in two weeks.
Dan Goron:My blank.
felipe:Thank you. Bye.
Chat Logs
00:04:10
Toni Wahrstätter:https://github.com/ethereum/pm/issues/1944
00:07:45
Karim T. (matkt):It’s not a good day for client updates ^^
00:08:31
Stefan Starflinger:Im back from my holiday where did everyone go 😂
00:10:34
Karim T. (matkt):Why not creating a shadow fork and build new blocks with transactions of the mainnet transaction pool ?
00:11:14
felipe:which endpoint is this @jochem-brouwer? `testing_buildBlockV1`?
00:11:52
jochem-brouwer:Replying to "Why not creating a..."
If this is related to benchmarks, we want to really stress test the client. So "normal" mainnet texs are not sufficient here because they are not stressing the client enough. We want to generate "worst case blocks" and try to also abuse the BAL to generate worst cases there (for instance batch I/O where the storage is being loaded in reverse order than they are ordered in the BAL)
00:12:15
Stefan Starflinger:Its not very cheap to setup a shadow fork and we generally prefer to have multiple clients ready before taking this on
00:12:30
jochem-brouwer:Replying to "which endpoint is ..."
Yup! Nethermind is working on this to support Glamsterdam (already supports Osaka)
00:12:49
Stefan Starflinger:Whats the status on the benchmarkoor integration
00:12:56
felipe:Replying to "which endpoint is ..."
Ah yep. We now support this in STEEL as well 👍
00:13:01
Karim T. (matkt):Replying to "Why not creating a s..."
Ok I think it’s also important to have the two kind of tests
00:13:26
jochem-brouwer:Replying to "Whats the status o..."
Benchmarkoor should be able to run this, the problem is we cannot fill the benchmarks to plug those into benchmarkoor (this is this testing_endpointV1)
00:13:41
Stefan Starflinger:Replying to "Whats the status on …"
I see
00:14:22
jochem-brouwer:Replying to "Whats the status o..."
So need one client to use as benchmark filler. It is not the same as "normal test filling", because for the benchmarks to make sense we need to run it on top of state and not on top on empty or super small state (because the operations are extremely fast there anyways)
00:15:02
felipe:https://github.com/ethereum/EIPs/pull/11227/changes
00:15:51
Karim T. (matkt):Replying to "which endpoint is th..."
We have a PR in Besu for that not sure how close we are to merge it
00:17:49
Toni Wahrstätter:https://github.com/ethereum/EIPs/pull/11323
00:19:06
felipe:https://github.com/ethereum/EIPs/pull/11223#discussion_r2849777995
00:24:25
Karim T. (matkt):In Besu we are also checking the order of the keys
00:26:38
felipe:swap tx index order test: https://github.com/ethereum/execution-specs/blob/forks/amsterdam/tests/amsterdam/eip7928_block_level_access_lists/test_block_access_lists_invalid.py#L296
00:27:15
felipe:Replying to "swap tx index orde..."
also swapping address ordering... yeah we have these
00:27:49
Toni Wahrstätter:This is the PR on the json rpc:
https://github.com/ethereum/pm/issues/1944
00:28:29
Karim T. (matkt):Already merged in besu
00:28:51
Karim T. (matkt):Replying to "swap tx index order ..."
Talking about checking before block processing
00:35:44
Jared Wasinger:I have a conflicting call. gotta go 🙁
Summary
12 highlights
· 3 action itemsExperimental
Summary
12 highlights · 3 action itemsExperimentalclient updates
testing progress
fork status and schedule
- Batch I/O benchmarks prioritized: needed for both Glamsterdam repricing and BAL state location decision00:12:44
specifications
Action Items
- One client team (preferably Nethermind or EELS): Implement testing_buildBlockV1 endpoint supporting Glamsterdam EIPs for benchmark filling00:09:48
- Toni and Felipe: Clarify EELS specs placement of max item check and remaining gas validation00:22:10
- Toni, Jochem, Dan (async Discord): Evaluate BAL bloat impact from adding 64-byte account hash diffs for partial statefulness00:37:54