Block-Level Access Lists Breakout #2

Transcript

Pooja Ranjan: Like the windows… Can we just wait for one more minute? I think we're all in.

Toni Wahrstätter: Perfect, yeah, let's wait for one more minute, then the stream is ready.

Pooja Ranjan: We can move over the stream.

Toni Wahrstätter: Awesome. Then, let's start. Great! Welcome, everyone, to the second… EIP7928 breakout call. I will post today's agenda in the chat, it's rather short. We have two agenda items, today. First of all, we have to discuss about, do we want to include transaction indices, or how we call them now, block lab access indices for reads. So for everything that is not touched, or for everything that is touched but not modified. And the second item is basically just client updates and seeing where we're at and how close we are to a definite. Right, there was a short discussion on the Discord, Some brought it up that we should include the block level access indices, for S loads and for all the opcodes, like call, static call, X code size, and so on, that touch an account without modifying it.

And the question is, should we include block-level access list indices for it? So I would just, yeah, pass that question to clients. What do you guys think? Maybe you can start some by… Telling us the motivation behind it.

Somnath Banerjee: All right, thanks, Tony, am I wonderful.

Toni Wahrstätter: Yeah, I can hear you.

Somnath Banerjee: Got it. Okay, so the motivation is, The way I envision block-level access list to servers in the post-Clamsterdam world is… One of the aspects is parallel, execution, of course. And I suppose that is, something that most of the clients including Aragon, I would be looking into and implementing, because, you know, why not? That should speed up, execution to some extent. By that, I mean, like, it's… From our initial results with parallel execution, we've seen that something like a… Mark and Patricia try might slow you down, so you need, like. Quite a bit of parallelization, in order to benefit from that. That's, like, a day-to-day, but another, possibly, potentially big thing that might happen is…

that you include, ZK EVMs, And create proofs for transactions and blocks. So, when I sort of, dived into this, with our… work for a prover. It is apparent that in order to create a proof, with the current set of ZKVMs, that sort of Simulate the running of a bare metal, you know, cut-down version of RISC-V, Runner, you sort of don't want it to… talk back and forth, with BB, as you would allow your regular execution clients to do. So that would mean, do you like to have that fully stateless. But in order for something to be fully stateless, of course, you need, the whole state

Before and after in a block, and the execution as well, but block level access list, actually sits in a convenient spot to optimize maximum benefit with the least amount of space. So, you would expect this kind of a setup to run alongside Something that can read the bells and give you the pre-state. Of execution, which you would then pass through the risk 5 runner that you've got, inside of your prover. And, that will just one shot give you the proof. Offer execution… Trace generation? So, in order for you to know which state to give it, because you don't want to give unnecessary state, really, because Every, every byte of data that you've passed into, this

very, performance-sensitive kind of a, setup. It's very costly, so you'd rather just give it Only the bits and pieces necessary for that, tiny bit of execution that happens. One way to analyze the proving itself would be to… Generate the prices, and then… try to stitch those traces in a GPU. That's beyond the scope of the actual execution client, but on a protocol level, you can at least say that you can create Transaction level granularity, for… Parallelization, both in regular execution and for proving. So in order to do that, you would need the transaction-free states for all the transactions, because your client is, you know, stateless. And in order to do that, block-level access lists can sort of help you by already telling you

Which all accounts perform reads, so you can just exactly parcel, your runner with that exact, read state needed. So that is the, overall motivation.

Toni Wahrstätter: Let's see, thanks. Yeah, to me, it feels like there is a trade-off between, the information we add in addition to what we currently have in the block access list. So, of course, this would make the block access list a little bit, larger. But on the other hand, we allow people who generate proofs we don't need to pass them that much data. Because, of course, today, if you want to, execute a certain transaction, what you need is everything, So all the pre-state that that transaction touches, but also the pre-state that that transaction reads. And because we don't have transaction indices mapped to what is red in the block of access list? you would have to pass everything, right? So you would have to pass everything that this certain transaction is going to modify, but in addition to that, you would also have to

pass, yeah, all the values that are only red. Is that kind of correct?

Somnath Banerjee: Yep.

Toni Wahrstätter: And then it's kind of the trade-off, right? Like, do we want to include more information in the block access list, or are we fine with passing, like, a few kilobytes? Because here we are talking about kilobytes of data? To the provers.

Sophia Gold: So, I'm not sure if the, Like, stateless execution matters so much for the provers when you look at how high the hardware requirements for proving are, I think that more of the benefits are the worst-case parallelism you get, right? There are some ZKVMs that are already, chunking, traces, rather than waiting For full execution, before starting proven. But that's, of course, like, optimistic, so, If you can fully parallelize everything, along with having, you know, transaction gas limit, I think that's where you get most of the benefit.

Toni Wahrstätter: Thank you. Do other clients have an opinion on that, especially when it comes to proving or parallelization? Like, how do you envision, parallelization to be implemented? Would it also matter for, parallelization, kind of, how much data you would need to pass to each process?

Jared Wasinger: So, based on the benchmarks I've run on GET, on just… Very… Standard hardware, akin to, I forget the EIP number, but there's an EIP that… specifies a… sort of a standard node specs. I've been running benchmarks against against a VM that's roughly equivalent to those. I… And I haven't implemented these indices yet, but I just… I… I don't really expect them to… to… I don't expect it to speed up block processing in the general case, and also, based on what we've seen so far, the state root computation is still, dominant, so unless…

that can be brought down below execution. Any savings we would gain in execution don't… really have a practical effect. But, yeah, that's… My impression.

Toni Wahrstätter: Okay, thanks. Maybe one follow-up question? Like, it wouldn't really… improve execution time. It would more be like, okay, you need to pass less data to execution, which in turn might improve execution again. But it's more like, when you parallelize using the block access list today, what data do you pass to this process? Is it, like, the entire CAF?

Jared Wasinger: we don't pass… well, in my implementation, we don't… we pass… Actually, we don't pass anything, so each… each parallel executor will reach out to the database to instantiate whatever state it needs, and because the database maintains a cache that is shared between between con… between requests, a staple cache, it just exists in that cache, so it's pretty opaque. to us. Like, there's no, like, shuffling around of data. to the executing Go routines or threads in my implementation.

Karim Taam: You don't need to pass the right of the previous execution? To the…

Jared Wasinger: No, no, oh, sorry, I… well, you… yeah, I passed the, the… the… the BAL is… is available to these, go… to these separate, threads, but they can just recompute the… the state they need based on the pre-state and applying the changes in the BAL. So yeah, the BAL is the only thing that's passed.

Karim Taam: as you said, I think if we… Sorry?

Toni Wahrstätter: No, go ahead, please.

Karim Taam: I just wanted to say, in basis size, I see. If you want to implement. the full polarization. I think what we will use is for the one on the right, on the right. something similar to what Jared did, I think, so… Just passing the write of the previous transaction to each transaction, and run in parallel, and do the read. On each shred, in parallel, and see… And compute and merge the results at the end, but… At the moment, I don't really see the need of the grid. And the same for Bezos, the compute, or the state computation is still king, Big part of the block execution, so… Block access is only with the right will improve a big part.

Processing.

Toni Wahrstätter: Thank you, so just, so if I understood that right, then you say that you would also kind of not include the transaction index, for everything that is not modified in the PAL, just because we don't… we might not need it, and we can just Or at least that's the case for your client, that you can just do it like Jared described it for GEF, where you have, like, access to the complete block lab access list, and the entire cache. And you parallelize for that. Is that correct? Okay, okay. And this is, like, different for Aragon, right?

Somnath Banerjee: So… again, as Jared said, all of this doesn't matter because MPT is the bottleneck. for parallel, compensation. But, right now, even our execution, actual execution module. does not, benefit that greatly from reads, from BALT, because it's not really needed. Database is fast enough, at the current level, so it's the identical case for Aragon as well, that Parallel, reads from database, through the threads is the way that it is implemented right now. And there would not be any reason to, not do this, because If you're only processing, like, I suppose, like, 50 million gas or so. The parallel reads are not that much, and you are sort of processing the block on a single machine.

So your database thread… the database threads can be managed by the OS, Which is, you know, hosting it, so all is good. But, that's the case for Arago, it's the same, but my argument is that I don't think, Val's, pipe was to enable 60 million gas, or even 100 million gas, it was to… Maybe futuristically enable, gear gas or something? So, you can imagine, like, when you reach, that level, You would want to run a cluster, of executors. Where, it's not that same single source database. that you're running. Of course, you can say that you'll have multiple databases having the entire copy of the database and so on, but I think if you can pass the data at once, you can save some time, and of course.

In stateless, validators, it's a big, big win still.

Toni Wahrstätter: Yeah, that's fair. But also, for block club accesses, they do give you quite a lot in terms of, scaling, because you can also Basically, all the worst cases we have that are not like history growth or state growth, so basically all the worst cases around precompiles, opcodes, how much storage access we can handle and stuff. they will all become better, right? Because you were probably comparing or determining the, the results based on average blocks. But I think it would be a fair comparison to compare it with worst-case blocks, where basically you call, for example, the modx precompile as often as you can. And with block-level access lists, you should just be able to parallelize them.

Yeah, but I agree, it's not like a holy grail that allows us to go to 100 million, especially if we don't figure out solutions for state growth and stuff, but this is… Probably a different discussion. Yeah, what about other clients? Have a look.

Somnath Banerjee: If I may, I want to add one more thing. So, another thing is, let's say you have an ASIC or a coprocessor, which is, you know, maybe… I can imagine, the future, maybe next year or next couple of years, that you're doing quite a bit of, your execution through GPUs or code processors? to which you would sort of have the same model of execution as we have for ZK Proverse today, that it's an independently running module with a very small footprint of code, and you just, instantiate, like, 1,000 instances or 100,000 instances of that. in one go, and then you just wait half a second, and, like, all of those, GPU cores just return you the result.

Immediately, but if those same GPU-like cores, and it's not exactly GPU, but, you know, just get the analogy. If they have to sort of depend on CPU, to, again, go to the database and go via memory to return the results, they would not be very effective. So, I think, like, if you have, a coprocessor or something like that. Even in traditional computing, valves are going to be, like, if you just put the reads in, It's gonna be, like, a huge boost for that kind of use case, and I think it may come, next year or something like that.

Toni Wahrstätter: Thank you. Yeah, this is very interesting. I'm curious to hear, do other clients have an opinion on that topic, on the topic of including block-level access indices for everything that is not modified? Okay. Yeah, right now it looks like, most people are for, for not including them, but I definitely see the arguments, What do you think, Sam? Should we just, Postpone that decision, and keep it as it is for now, and then maybe Yeah, check with the CK people, too, and see what they demand.

Somnath Banerjee: Well, I… The argument is, that the 2% increase can… Probably give you, many seconds of benefit. In terms of passing the restate? Because otherwise, you would have to… Know the pre-state, in advance before trying to prove it. And, like, currently there is no way around this for ZKIP, people. They are happy to make a proof after execution is done, and yeah, I agree that, you know, hardware is big and all. But, it would be interesting to see if, you know, it reaches more demand, for these fancy use cases. So, I just want, This to kind of have a little extra data. And be future resilient, and to, like, not need any more modifications in the next half hour.

Rather than, you know, just have the bare minimum and… You know, just, look at how it is being done today and be happy with it. I'm okay either way, it's just that, if you had this, maybe at the protocol level. You get a, nice speed bump. So…

Sophia Gold: I mean, I'm happy to dig more into the ZK side and ask ZKVM teams, but I'm first unclear still how this difference Like, is a difference for, proving versus just validators re-executing? Right? Like, execution speed definitely matters significantly for proofing, but I don't understand how it, how it's more different here. Like… They're not stateless right now, right? like, ZKVMs, they're not, they're not doing execution statelessly.

Somnath Banerjee: Sorry, what do you mean they're not doing it? Are you saying, like, we have VMs have databases inside them?

Sophia Gold: The… I believe that the guest programs are loading the state, yeah.

Somnath Banerjee: Yeah, but, like, you'd have to pass the state to them after executing somewhere else, statefully, first, then… You, you have to do that because there is no provision, like, block-level access list as of today.

Sophia Gold: But after block-level access list, you'll still have to continue to do this.

Somnath Banerjee: Which is, like, to generate something like… Block-level access list, plus all the values populated, and then you can sort of generate the execution trace underfoot. So, yeah, currently they don't do it because they don't have it. I'm just saying, like, after BAL, they will still not have it, and still continue working in this way. Which maybe we can do a little bit better with.

Sophia Gold: Yeah, I just… I'm saying that I'm not sure that that's any different from what And a tester… That's re-executing and not, not proving the block would do, right? Like…

Somnath Banerjee: Okay, okay, okay, another clarification, okay, in my mind, we don't have two executors, we only have valves. And, the prover that does one-time execution only. So, it saves you, like, the execution… the first execution time entirely, not within the prover, but, like, outside of the prover that you use to generate the trace in the first place. You can just get rid of that, because the val is the… Kind of the trays that you are missing today, that you have to generate before generating the proof.

Sophia Gold: Right, but so, when… after Glamsterdam, right? I assume that the majority of… Attesters will, be… Right, yeah, this is sort of like what Kareem is saying. Like, well, I mean, I think it will be in production, but it won't be, like, the norm, right, for our testers to use. They'll still be re-executing. it should be, you know, faster with bowels, and I don't think that that is any different From what approver… from this… the considerations that a prover has in terms of execution. Or at least with regards to the issue we're discussing now.

Somnath Banerjee: Yeah, but they won't be able to use the belt, at least is my argument, that if they have… I know they'd be happy with it, but, like, why not make them… make it easier for them to use it with the read value?

Toni Wahrstätter: They would just not… they would just not be able to use it that, efficiently, right? Because what… what the prover needs in order to… let's say the prover wants to prove, the last.

Sophia Gold: 10 transactions off the block.

Toni Wahrstätter: Then I would need to give the prover the pre-state of the block.

Sophia Gold: Then the block level access list, so that the prover can arrive at the state where he starts from.

Toni Wahrstätter: And I would have to give him everything… concerning read values, so everything that is touched in the block, because I don't know in which transaction it is touched, so I would need to give everything to the prover. This is, like, what you're describing here, right, some that…

Somnath Banerjee: Exactly.

Toni Wahrstätter: that instead of pre-filtering which exact values the prover will need for those specific transactions, I will have to give him everything and be like, yeah, the right values will be part of the set I just gave you, but I can't yet tell you which exact read values you will need. And I can definitely see that, because, yeah. In a world where you would do some distributed proof generation, then you would, of course, need to send that over the wire. Yeah, I think it's a valid concern, and a valid argument, to include the transaction indices. As said, it would add, like, 2% of additional size, looking at the snappy compressed block access list size. It would definitely save, like, kilobytes of data that will not be needed to be passed to the approver.

it's the question of, is it worth it, right? Because those 2% would go into history, whereas the additional kilobytes provers need to send over the wire, and we don't really need to care about it that much. So yeah, it feels like we need more answers from CKVM teams, so it would be great if, yeah, we can reach out to them and ask what they think about the current block of accesses design, and then we can still, like, add the block lab access list indices. So, right now, I've already specced it. If you look into the Discord, there isn't spec implementation, it's… It's kind of trivial to add the… Transaction indices, because all the code exists that tracks that.

It's just, it adds a little bit more of complexity, because now we have, like, edge cases where transaction… We don't include, addresses and their transaction… and the index where they're attached. if… they are modified in the same transaction, right? Because otherwise we would have duplicated values. So I think it adds some complexity. But it might be worth it. Is there anything else, someone would like to add to that topic before we close that one?

Somnath Banerjee: I would also like to know if there is someone against it completely. Because there might be some things that I'm missing.

Carl Beekhuizen: I mean… I wouldn't say I'm against it completely, but I think we just need to be, like, very careful adding things with, like, unclear payoffs. Like, we need a lot more data before we commit ourselves to something like this, because Once we have this in the protocol, there will be… Someone who uses it, and now this is complexity we have to carry around forever. like, I think we need to, like, very clearly understand the trade-offs, and I think we're quite far from that, and I think we're, like. Over-indexing on exactly what we expect. ZK things to potentially look like in the future? It's just very unfair to me that this is the right thing to be adding in shipping right now. I think, like, we should rather be a bit more conservative and focus on

like… The simplest version, without this, and then rather focus on getting the, like, actual scaling benefits. Like, having client teams, like, implement like, the marginal scaling benefit from block-level access lists, rather spending their time on that over implementing this, I think it's a much better use of time. Just given what we know for now, that very likely may change, though.

Sophia Gold: Well, I'm not sure I fully understand the, The gain that you get from including these or not. But, Theoretically, like, it should be the same… scaling benefits for clients not in a ZK world, right? Unless people are saying that you're so bound by, a saber computation that You know, we've exhausted the, the benefits of proving, or improving execution for now.

Toni Wahrstätter: Right, yeah. Yeah, yeah, I think in the average block, there's still the stage root computation that is the heaviest part. For worst-case blocks, you might get different worst cases, so suddenly execution or storage or something might become the worst case. But yeah, it feels like We don't have enough answers yet to really, take a decision on that. It would be great to get more answers from CKVM teams, how they plan to use that. I would stick to not including them for now. If we still want to include them, it shouldn't be too difficult, because it's basically just adding transaction indices to storage reads, and of course, the transaction indices to the account object that we have, basically the changes object.

And, yeah. We can still add it at a later point. I think, it would not be too late, because it's, Rather small change. But yeah, in this case, I would say we just stick to the… To how it looks… how it is today. And… Yeah. Just reading the chat. Yeah, I agree with Karima. Awesome. Perfect, yeah, maybe just to add, the original motivation to not include transaction indices at everything that is not modified was because you actually don't need it for parallelization. Because if it doesn't change, then the value you have in cash is still correct, and you might not need it.

But yeah, let's see if we have to revisit that in the future. Anything else someone wants to add? Great, then I would suggest we just, yeah, go through all the clients and see where people are at, if there are any blockers, and also… See how far we are in terms of Getting closer to a first effort. Can we just start with you, Jared, Kev?

Jared Wasinger: Yeah, sure. Yeah, so I'm continuing to work to get the… the changes merged in Geth, Not really much of an update in terms of the performance. Since I gave the numbers from the la- prototype on the last call, yup.

Toni Wahrstätter: What's your estimate regarding a first deflate?

Jared Wasinger: I, could… Probably could have a branch ready fairly soon, Maybe… maybe, like, a few days to a week? At minimum.

Toni Wahrstätter: Yeah, I guess it will only make sense if we have at least a second client pair. But this is… this is great to hear. Okay, thank you.

Jared Wasinger: Oh. It's gonna take longer.

Toni Wahrstätter: Is that?

Jared Wasinger: to actually get it merged in Geth, though, but… Yeah. Anyways…

Toni Wahrstätter: Okay, thanks. Let's do Aragon next.

Somnath Banerjee: No updates. Mark from our team would be working on it. He's trying to… improve, our Merkle filtration try calculation, which seems to be the bottleneck at the moment, but no concrete progress there.

Toni Wahrstätter: Cool, so you're already looking into the… Parallelizing the stage root computation? Did I get that right?

Somnath Banerjee: It's already being parallelized, but, we have observed that, it can be optimized quite a lot, or at least needs to be optimized. Something to do with our database, that when you have So we have, some lock FTM parallelization that improves execution time already, without the balls, which is my 2.5x or 3x. It's very close to what Bells would allow you. But then you hit, like, at the same time when you start your parallel route calculation, that takes way longer. Which, you know, doesn't make sense, so we'll have to do some work on that. Yep.

Toni Wahrstätter: Great, thanks. Then, let's do Netherland next.

Marc Harvey-Hill: I, so progressing on, the block access list construction, most stuff seems to be working around all the system contracts, withdrawals, but I'm still looking into one edge case around, reverted transactions. But I think it shouldn't be too long until we're able to join a DevNet. Just had a quick question on, like, what's the state of tests at the moment? Are there any tests that I could run?

Toni Wahrstätter: Yes, there are. I would forward that question to Felipe, if he's… Ready?

Felipe Selmo: Yeah, yeah, I could speak about that. We released the first pre-release. At the end of last week, but, there were some issues on the spec side that needed to be updated, and I believe that they have been. And there were, there were some things on the test side as well. This should be ready for another release, and we could get it out as soon as, after this call. All the code is already in place. We just, should get some sanity checks there, and then, Yeah, we should just get out another release, so… We have some good test vectors.

Toni Wahrstätter: Awesome, thanks. Then, let's continue with REF.

Ishika: We have, ran the initial tests, and as of now, we are looking closely into the H cases to make sure we Not kind of misusing any. And, also, we are working on cleaning up our existing implementations and sort of including the other parts as they come.

Toni Wahrstätter: Awesome, thank you. What do you think, regarding, First Step Net? What is kind of the… The rough timeline, or the planned timeline.

Ishika: As of right, we will take some time. Like, we have, certain parts ready, but as of now, concerning indices or other parts, we need to discuss it with the team and see whether if they have some sort of opinion about it. What they want to look regarding it. So, it will take some time, I can say, about a week or two for us to, like, have things ready.

Toni Wahrstätter: Perfect, thank you.

Ishika: And then, peso.

Karim Taam: Yeah, so, no big update, we had to work on something else, but, yeah, for the moment, we still have the block access list creation. And this week, we will work on the state rule computation optimization, thanks to Block Access List. So yes, this is the next topic, we'll work on… It's over.

Toni Wahrstätter: Great, so you would already be ready for a DevNet in this case?

Karim Taam: So we have block accesses creation, not block accesses validation, but, I think we will be able… to propose a block with a block access list. I'm not developing… I'm not the guy who is working on that, but I can ask the guy who is working on that to verify that. something we can do, but yeah, I think we should be able to propose block with block access list, normally, yeah.

Toni Wahrstätter: Awesome. Thank you. Yeah, it's great to hear. It feels like we're getting very close to a first effort already. We're not in a rush, of course. And, yeah, I guess if we get to a first definite by end of month. Would already be a great achievement.

Karim Taam: Yeah, I think for the end of March, yeah, it would be okay.

Toni Wahrstätter: Cool Perfect. Did I forget anyone? Great. So, is there anything else people want to discuss before we wrap up? Maybe just to add, I was also discussing with Of course, because the block of access list is now an ROP and not an SSS anymore, we cannot prove anything against it. And it would have been kinda handy for pre-confirmas. So, the question came up is, like, how big of… how… Yeah, how big of a deal would it be to treat the block level access list similar to receipts, so that we put them into a try and allow proofs against this try, instead of only the block level access list half?

This is, like… I would assume a bigger topic. And… a rather big change, but I just wanted to bring it up so that people can discuss it, and we can still, discuss it, like, in the next Breakout call in two weeks, if this would be something. we need. So far, it seems like it's only simplifying the work of pre-confirmers and not, like, a big enabler. But yeah, interesting thought, definitely.

Jared Wasinger: So we would create a try of the hashes. of… Past block-level access lists?

Toni Wahrstätter: Yeah, for example, and then you could do an MPT proof against this try, and it would be easier Yeah, it would be a shorter proof than providing the entire block have access list.

Jared Wasinger: Hmm. Yeah, it seems doable.

Toni Wahrstätter: Yeah, we can… I can put it on the agenda for the breakout call in two weeks. We can discuss it, Definitely, for sure, it needs to give us some big advantages to, yeah, be worth the changes. But, yeah, let's see. Great. Is there anything else? Someone wants to add? Otherwise, we would just wrap up. Awesome. Then, thanks everyone, and see you… At the next breakout call in 2 weeks.

Jared Wasinger: Yep, bye.

Somnath Banerjee: Bye. Thank you.

Karim Taam: Motion.

Ishika: Thank you.

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