Block-Level Access Lists Breakout #13

Transcript

Akash | ECH: Hey, Tuni.

Toni Wahrstätter: Hello?

Akash | ECH: I'm helping with the stream today, so let me know whenever you are ready.

Toni Wahrstätter: Perfect, amazing. Thank you very much.

Akash | ECH: Yeah, it's alright.

Toni Wahrstätter: Hello, everyone! Let's give people one or two more minutes to join, and then we can get started.

Okay, I think we're ready to go.

Akash | ECH: Yeah, we are live.

Toni Wahrstätter: Awesome, thank you very much. Welcome, everyone! Today is the 13th EIP-7628 breakout call. It's February 25th… 25th? And we have quite a… some items on the agenda, nothing, 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. just as a… to recall, we need the client optimizations for the repricing, benchmarking required for the Glamsterdam repricing EIPs. And it would be great if we get some updates from clients, about progress within the last two weeks on parallel I.O, especially. So, feel free, any, anyone from my client team, to provide us an update.

Karim Taam: I can't start on Besu, so… We still have the different optimization already implemented, so we had time to do some… Optimization… Hmm, on Zoom. pRethetch, and also on some other stuff in the block access list branch. 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. And, we asked… we started to work on IT71, and, I think it's mainly that, yeah. Yeah, it's all on Besu.

Toni Wahrstätter: Great, thank you very much. Do you already have, like, first numbers? Did you already look into benchmarking, especially the batch I.O?

Karim Taam: Not really. We are using, for the moment, the devnet 2, so it's not really interesting, regarding the number we have. We didn't see a lot of differences, because, It's not similar to mainnet, so… 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. or state rights? And, yeah, thank you very much. Let's continue maybe with, do we have someone from Geth on the call? Okay, don't think Jared is on the call… yet. Let's skip Geth for now. Let's continue with Nethermind, then. I just see Mark is also not on the call. Then we continue with Reth.

Okay, I would just assume there are no updates on the optimizations there. Does Erigon have updates on the free-to-friend optimizations? Okay, yeah. Seems like not much changed since the last two weeks, so we are still at, having Geth and Beso ready to be benchmark, especially on a shadow fork. 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 does not yet, support the Glamstadem, EIPs. 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. 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 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. 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. And this is currently not yet implemented in any client, so we need one client. 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. I saw Jared from GEF joins in the meantime. Jared, would you be willing to provide us an update on The bul optimizations, if there are any. Especially the batch I.O.

Jared Wasinger: Yeah, I mean, so it's… like I mentioned on the, on the channel, there's… Really, not much has changed since the last meeting. Or, Maybe it has, I just can't remember. So there's… there's a few, like, execution option presets. that I've implemented for Geth, 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… made… 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. 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… 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. So, that's why we originally said, like, yeah, let's optimize the batch.io optimizations first, and, like.

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. as soon as other clients get ready, just please post it into the… into the BlockFlive Access List Discord, and then we can start, benchmarking more clients on… on a shadow fork, or on devnet Free. Great. Is there anything else before we move on on the agenda regarding the optimizations that we should discuss now? Seems like not the case. 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.

The first one was a clarification to the EIP how the ball is used in the state transition function. 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. And then you would start exec- executing, and… You would… 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. 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.

Which doesn't affect, like, correctness at all, but more like to have that clarified in the EIP. Let me actually post the PR in the chat, such that everyone can have a look. While we're talking… One second… Someone did already, thank you very much, Radipa. Perfect. Is there anything… Someone wants to discuss regarding that topic. Perfect. Yeah, this is more like a clarification than actual change. 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

Brought up that, We might also want to account for bul items that get into the ball for free. And those items that enter the ball for free are basically all connected with system contract calls, because every other item in the bell 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. But this is not the case, for example, for everything system contract related, because no one actually pays for it. And this affects, withdrawals, execution requests. Our execution layer triggered, exits and consolidations. And also the pre-execution, system contract calls, like the historical state route. Historical block root hashes, and the…

The 4788 beacon block route in the, in the block. So, what we wanted to do with this check, it should only be a safeguard against invalid blocks. 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 Not yet accessed dollar items with the remaining gas. 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. But still, we must make sure that even invalid blocks don't take longer to invalidate than a valid block takes to validate.

Let me post the, link of this PR into the chat. This was just a, clarification of the EIP. 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 Any more to add regarding that topic, so we… clarify something in EALS, or is everything good to go?

Felipe Selmo: Yeah, so… As I was reviewing the max item check PR, 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 Let me see if I can pull up the actual, Comment and post it, but, this part here… Basically, the words should, in the PR, for the spec change? It feels a little, underspecified, whether, you know, this constraint needs to… Actually be there for clients, and whether… It basically… Here, this is the link for Mario's comment. It's basically hard to draw a very clear line on whether

We can test this for clients. And so, I think we… you know, I think a better explanation of whether this is required, 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… I wanted to know how you feel about, like. 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. 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. We can… 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. 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 And the thing is, you know. Theoretically, you don't need that check, because it only allows you to invalidate the ball quicker.

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. 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. it's two things. It's first the max item check, and then the other check where we basically determine, is there enough gas available to access the remaining not-yet-accessed bulb items?

So I'm curious, what… how do you think? Because I think we haven't really specified this code path between the engine API and the state transition function in ELS. So basically, what happens in between there.

Felipe Selmo: Yeah, yeah, no, I see what you mean. 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 You know, let's say there's some worst-case malicious bowel test. And from the… from the spec side, we could… we could have some benchmark tests that benchmarks how quickly clients can invalidate this. If it feels like this is the end goal. But as far as, you know. Adding this to the spec, yeah, it's a little tricky, and having tests for something that isn't, There's an S clear in this back. I'll have to think on this some more.

Toni Wahrstätter: Okay. 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 those, that there is not, like, the maximum item limit is not exceeded. Like, we can do that. 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 Selmo: 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. 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. storage changes or anything, so I think we're good on that. But yeah, I think we still added some new tests there, right?

Felipe Selmo: Yeah, yeah, from some comments on the, on the ETH R&D, We didn't really have a whole lot of invalid tests based around 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. Is there anything… People want to discuss regarding those two topics? I see Karim is also saying in the chat that Baseway is also checking the order of the keys. Do we have a test for, the ordering of the ball items being correct? I'm not sure anymore, actually. Do you know Felipe, or maybe Rahul is on the call? Can someone?

raxhvl: Yep. They do have…

Toni Wahrstätter: We do have, okay, perfect. Amazing, thank you.

Felipe Selmo: What is the… R-ruh.

Toni Wahrstätter: Go ahead.

Felipe Selmo: Do you know which test this is, Rahul?

raxhvl: I think it's in the invalid test, where we, we have those bound modifiers that change the order, right? You made those API.

Felipe Selmo: Yeah, yeah, I believe there… we have some, and I'll double check.

Toni Wahrstätter: Awesome, thank you very much. Great. Is there anything the clients would like to add regarding those Three topics that we discussed now, basically the max item check on the barrel, then also the check of Remaining gas versus not-yet-touchable items, and… the uniqueness of ball items, is there anything people want to discuss on that topic? Great. Looks like things are clear. Awesome. Then we can… proceed with the next agenda item, which would be the Chase and RPC PR. I saw that, I saw that some clients had already implemented the JSON RPC for devnet2,

there were some recent changes with not returning, like, the hex string, but instead returning the JSON object. And I would love to hear if clients have updates on that, if this is, like, ready for definite free. 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. So, I would just assume, clients will have that implemented. What would be great if someone from the client team could confirm?

Karim Taam: Yeah, on PZU, it's already implemented, yeah. 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. 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. 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… I have to double-check that. I think this will also be brought up in the RPC standards call. So, I will also have to double-check with, Omar if she has any updates on that, Because, of course, yeah. double-checking with the experts on our PC is definitely the right way to go there before we merge it.

Great. This was… everything we had around the specs. Is there anything we should discuss this week regarding specs or tests? Any updates? Looks like that's not the case, which is good. And then we have a last agenda item by, Goron, Dan. I hope I pronounce your, GitHub handle right here. who wants to talk a little bit about the feasibility of using BAL For the payload needed by partial stateful nodes. So, could you give us a quick intro into what are you looking into there, and…

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. Yes, Don… then go on its, right? Enough. together with, with Carlos, Perez from, this, Ethereum stay close team. We're… Pushing a bit the concept of, Of partial, statefulness, and we were looking to get, your… people, you know, the opinion of people that work on… on BAL about If we could use ball as a vehicle for. For the account, hash diffs, which are basically, the… The payload that you mentioned. I left… I left, a TLBR on partial statefulness, on the…

On the comment, and on the call's comment. I can reiterate, very quickly. The idea that, That's behind the partial statefulness, and that's… That if we get nodes to store a minimum data set, From… from the, you know, to persist locally a minimum part of the state. Then we could get them to be… Coherent under the state route. And basically keep up with the… Duh. Canonical state root, or the global state root, and then be able to store only certain parts of the state. But those parts, if we can look at them From the topological, from a topology-based view. 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.

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. Is that we can boil our, proposal into three… main points. So if we can get every node to store the 32-byte commitment, that constitutes the count leaf. which is account hash. Then, this is a dataset of approximately 10 gigs for 300 million accounts. Then the nodes would, become globally root-aware, so to speak. Ball already provides Full state diffs. Which are, which take care of update… of nodes updating state values. If… if we can add to ball or to…

Another vehicle, the hash diffs. Which are structural, state. I don't know. Mom. Which is a structured state. Yeah, correctly, correct me if I'm wrong. Then… Nodes would be able to update those stored account hashes without re-execution, and that basically unlocks The first level of partial statefulness, functionality. by… 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 To straight root and match, you know, the, the result with the, with the… State root… with the root that's in the blocks.

Heather. I also added some high-level specs change proposal, and I would be very grateful if I would get some opinion on that. If… if my assumptions were, correct. Meaning that we can get the pre-state captures from the… from the transaction frame level. And that we can get the post state. values, you know, from building Ball, from actually building Ball. That's it. Please let me know if… 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, Let's clear the name first. It's partial statefulness. So, basically, it's not statelessness, it's not strong statelessness, as in stateless… 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. So it's partial statefulness, so they would store something, and that would be, as a minimal requirement, that would be the mapping between each address. For all accounts, and their account hash, which is the commitment of balance, nouns, code hash, and, contract, Hash. What's the correct expression here? 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 Post. post-execution, or executing the transaction, and then we get a new, the blocks transaction, and then we get a new account. 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. 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. 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? Initially, I would say no, of course. For each touched account, or for each changed account, you would then add

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. 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. 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? 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. 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. 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? Awesome. Looks like everything is clear. Dan, thank you very much, everyone, for attending the call, and see you in two weeks.

Dan Goron: My blank.

Felipe Selmo: Thank you. Bye.

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