Toni Wahrstaetter:Great! Welcome, everyone, to the second…
Transcript
Toni Wahrstaetter:EIP7928 breakout call. I will post today's agenda in the chat, it's rather short. We have two agenda items, today.
Toni Wahrstaetter: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.
Toni Wahrstaetter:So for everything that is not touched, or for everything that is touched but not modified.
Toni Wahrstaetter:And the second item is basically just client updates and seeing where we're at and how close we are to a definite.
Toni Wahrstaetter:Right, there was a short discussion on the Discord,
Toni Wahrstaetter: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.
Toni Wahrstaetter:And the question is, should we include block-level access list indices for it?
Toni Wahrstaetter:So I would just, yeah, pass that question to clients.
Toni Wahrstaetter:What do you guys think?
Toni Wahrstaetter:Maybe you can start some by…
Toni Wahrstaetter:Telling us the motivation behind it.
Som | Erigon:All right, thanks, Tony, am I wonderful.
Toni Wahrstaetter:Yeah, I can hear you.
Som | Erigon:Got it. Okay, so the motivation is,
Som | Erigon:The way I envision block-level access list to servers in the post-Clamsterdam world is…
Som | Erigon:One of the aspects is parallel, execution, of course.
Som | Erigon:And I suppose that is, something that most of the clients
Som | Erigon:including Aragon, I would be looking into and implementing, because, you know, why not?
Som | Erigon:That should speed up, execution to some extent. By that, I mean, like, it's…
Som | Erigon:From our initial results with parallel execution, we've seen that something like a…
Som | Erigon:Mark and Patricia try might slow you down, so you need, like.
Som | Erigon:Quite a bit of parallelization, in order to benefit from that.
Som | Erigon:That's, like, a day-to-day, but another, possibly, potentially big thing that might happen is…
Som | Erigon:that you include, ZK EVMs,
Som | Erigon:And create proofs for transactions and blocks.
Som | Erigon:So, when I sort of, dived into this, with our…
Som | Erigon:work for a prover. It is apparent that in order to create a proof, with the current set of ZKVMs, that sort of
Som | Erigon:Simulate the running of a bare metal,
Som | Erigon:you know, cut-down version of RISC-V,
Som | Erigon:Runner, you sort of don't want it to…
Som | Erigon: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
Som | Erigon:fully stateless.
Som | Erigon:But in order for something to be fully stateless, of course, you need, the whole state
Som | Erigon: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.
Som | Erigon:So, you would expect this kind of a setup to run alongside
Som | Erigon:Something that can read the bells and give you the pre-state.
Som | Erigon:Of execution, which you would then pass through the
Som | Erigon:risk 5 runner that you've got, inside of your prover.
Som | Erigon:And, that will just one shot give you the proof.
Som | Erigon:Offer execution… Trace generation?
Som | Erigon:So, in order for you to know which state to give it, because you don't want to give unnecessary state, really, because
Som | Erigon:Every, every byte of data that you've passed into, this
Som | Erigon:very, performance-sensitive kind of a, setup. It's very costly, so you'd rather just give it
Som | Erigon:Only the bits and pieces necessary for that,
Som | Erigon:tiny bit of execution that happens. One way to analyze the proving itself would be to…
Som | Erigon:Generate the prices, and then…
Som | Erigon: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
Som | Erigon:Transaction level granularity, for…
Som | Erigon:Parallelization, both in regular execution and for proving.
Som | Erigon:So in order to do that, you would need the transaction-free states for all the transactions, because your client is, you know, stateless.
Som | Erigon:And in order to do that, block-level access lists can sort of help you by already telling you
Som | Erigon:Which all accounts perform reads, so you can just exactly parcel, your runner with that exact, read state needed.
Som | Erigon:So that is the, overall motivation.
Toni Wahrstaetter:Let's see, thanks.
Toni Wahrstaetter:Yeah, to me, it feels like there is a trade-off between,
Toni Wahrstaetter: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.
Toni Wahrstaetter:But on the other hand, we allow people who generate proofs
Toni Wahrstaetter: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,
Toni Wahrstaetter:So all the pre-state that that transaction touches, but also the pre-state that that transaction reads.
Toni Wahrstaetter:And because we don't have transaction indices mapped to
Toni Wahrstaetter:what is red in the block of access list?
Toni Wahrstaetter: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
Toni Wahrstaetter:pass, yeah, all the values that are only red. Is that kind of correct?
Som | Erigon:Yep.
Toni Wahrstaetter: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
Toni Wahrstaetter:kilobytes of data?
Toni Wahrstaetter:To the provers.
Sophia Gold:So, I'm not sure if the,
Sophia Gold:Like, stateless execution matters so much for the provers when you look at
Sophia Gold: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
Sophia Gold:For full execution, before starting proven. But that's, of course, like, optimistic, so,
Sophia Gold:If you can fully parallelize everything, along with having,
Sophia Gold:you know, transaction gas limit, I think that's where you get most of the benefit.
Toni Wahrstaetter:Thank you.
Toni Wahrstaetter:Do other clients have an opinion on that, especially when it comes to proving or parallelization?
Toni Wahrstaetter: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,
Jared Wasinger:akin to, I forget the EIP number, but there's an EIP that…
Jared Wasinger:specifies a… sort of a standard node specs. I've been running benchmarks against
Jared Wasinger:against a VM that's roughly equivalent to those.
Jared Wasinger:I… And I haven't implemented these indices yet, but I just… I…
Jared Wasinger:I don't really expect them to… to…
Jared Wasinger:I don't expect it to speed up block processing in the general case, and also, based on what we've seen so far,
Jared Wasinger:the state root computation is still, dominant, so unless…
Jared Wasinger:that can be brought down below execution. Any savings we would gain in execution don't…
Jared Wasinger:really have a practical effect. But, yeah, that's… My impression.
Toni Wahrstaetter:Okay, thanks. Maybe one follow-up question?
Toni Wahrstaetter:Like, it wouldn't really…
Toni Wahrstaetter:improve execution time. It would more be like, okay, you need to pass less data to execution, which in turn might improve execution again.
Toni Wahrstaetter: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…
Jared Wasinger: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
Jared Wasinger:between con… between requests, a staple cache, it just exists in that cache, so it's pretty opaque.
Jared Wasinger:to us.
Jared Wasinger:Like, there's no, like, shuffling around of data.
Jared Wasinger:to the executing Go routines or threads in my implementation.
Karim T.:You don't need to pass the right of the previous execution?
Karim T.: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…
Jared Wasinger: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 T.:as you said, I think if we… Sorry?
Toni Wahrstaetter:No, go ahead, please.
Karim T.:I just wanted to say, in basis size, I see.
Karim T.:If you want to implement.
Karim T.:the full polarization.
Karim T.:I think what we will use is for the one on the right, on the right.
Karim T.:something similar to what Jared did, I think, so…
Karim T.:Just passing the write of the previous transaction to each transaction, and run in parallel, and do the read.
Karim T.:On each shred, in parallel, and see…
Karim T.:And compute and merge the results at the end, but…
Karim T.:At the moment, I don't really see the need of the grid.
Karim T.:And the same for Bezos, the compute, or the state computation is still king,
Karim T.:Big part of the block execution, so…
Karim T.:Block access is only with the right will improve a big part.
Karim T.:Processing.
Toni Wahrstaetter: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
Toni Wahrstaetter: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.
Toni Wahrstaetter:And you parallelize for that.
Toni Wahrstaetter:Is that correct?
Toni Wahrstaetter:Okay, okay.
Toni Wahrstaetter:And this is, like, different for Aragon, right?
Som | Erigon:So… again, as Jared said, all of this doesn't matter because MPT is the bottleneck.
Som | Erigon:for parallel, compensation. But, right now, even our execution, actual execution module.
Som | Erigon: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
Som | Erigon:Parallel, reads from database, through the threads is the way that it is implemented right now.
Som | Erigon:And there would not be any reason to, not do this, because
Som | Erigon:If you're only processing, like, I suppose, like, 50 million gas or so.
Som | Erigon:The parallel reads are not that much, and you are sort of processing the block on a single machine.
Som | Erigon:So your database thread… the database threads can be managed by the OS,
Som | Erigon:Which is, you know, hosting it, so all is good.
Som | Erigon:But, that's the case for Arago, it's the same, but my argument is that
Som | Erigon:I don't think, Val's, pipe was to enable 60 million gas, or even 100 million gas, it was to…
Som | Erigon:Maybe futuristically enable, gear gas or something?
Som | Erigon:So, you can imagine, like, when you reach, that level,
Som | Erigon:You would want to run a cluster, of executors.
Som | Erigon:Where, it's not that same single source database.
Som | Erigon: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.
Som | Erigon:In stateless, validators, it's a big, big win still.
Toni Wahrstaetter: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
Toni Wahrstaetter: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.
Toni Wahrstaetter:they will all become better, right? Because you were probably comparing or determining the, the results based on average blocks.
Toni Wahrstaetter: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.
Toni Wahrstaetter:And with block-level access lists, you should just be able to parallelize them.
Toni Wahrstaetter: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…
Toni Wahrstaetter:Probably a different discussion.
Toni Wahrstaetter:Yeah, what about other clients?
Toni Wahrstaetter:Have a look.
Som | Erigon: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…
Som | Erigon:I can imagine, the future, maybe next year or next couple of years, that you're doing quite a bit of,
Som | Erigon:your execution through GPUs or code processors?
Som | Erigon: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.
Som | Erigon:in one go, and then you just wait half a second, and, like, all of those, GPU cores just return you the result.
Som | Erigon:Immediately, but if those same GPU-like cores, and it's not exactly GPU, but, you know, just get the analogy.
Som | Erigon: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.
Som | Erigon:Even in traditional computing, valves are going to be, like, if you just put the reads in,
Som | Erigon: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 Wahrstaetter:Thank you.
Toni Wahrstaetter: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?
Toni Wahrstaetter:Okay.
Toni Wahrstaetter:Yeah, right now it looks like, most people are for, for not including them, but I definitely see the arguments,
Toni Wahrstaetter:What do you think, Sam? Should we just,
Toni Wahrstaetter:Postpone that decision, and keep it as it is for now, and then maybe
Toni Wahrstaetter:Yeah, check with the CK people, too, and see what they demand.
Som | Erigon:Well, I… The argument is, that the 2% increase can…
Som | Erigon:Probably give you, many seconds of benefit.
Som | Erigon:In terms of passing the restate?
Som | Erigon:Because otherwise, you would have to…
Som | Erigon:Know the pre-state, in advance before trying to prove it.
Som | Erigon:And, like, currently there is no way around this for ZKIP, people.
Som | Erigon:They are happy to make a proof after
Som | Erigon:execution is done, and yeah, I agree that, you know, hardware is big and all.
Som | Erigon:But, it would be interesting to see if, you know, it reaches
Som | Erigon:more demand, for these fancy use cases. So, I just want,
Som | Erigon:This to kind of have a little extra data.
Som | Erigon:And be future resilient, and to, like, not need any more modifications in the next half hour.
Som | Erigon:Rather than, you know, just have the bare minimum and…
Som | Erigon:You know, just, look at how it is being done today and be happy with it.
Som | Erigon:I'm okay either way, it's just that, if you had this, maybe at the protocol level.
Som | Erigon:You get a, nice speed bump.
Som | Erigon: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
Sophia Gold:Like, is a difference for, proving versus just validators re-executing?
Sophia Gold:Right? Like, execution speed definitely matters significantly for proofing, but I don't understand how it,
Sophia Gold:how it's more different here. Like…
Sophia Gold:They're not stateless right now, right?
Sophia Gold:like, ZKVMs, they're not, they're not doing execution statelessly.
Som | Erigon: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.
Som | Erigon:Yeah, but, like, you'd have to pass the state to them after executing somewhere else, statefully, first, then…
Som | Erigon: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.
Som | Erigon:Which is, like, to generate something like…
Som | Erigon:Block-level access list, plus all the values populated, and then you can sort of generate the execution trace underfoot.
Som | Erigon: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.
Som | Erigon: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…
Sophia Gold:That's re-executing and not,
Sophia Gold:not proving the block would do, right? Like…
Som | Erigon:Okay, okay, okay, another clarification, okay, in my mind, we don't have two executors, we only have valves.
Som | Erigon: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…
Som | Erigon: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…
Sophia Gold: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.
Sophia Gold:it should be, you know, faster with bowels, and I don't think that that is any different
Sophia Gold: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.
Som | Erigon: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 Wahrstaetter: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 Wahrstaetter: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 Wahrstaetter:And I would have to give him everything…
Toni Wahrstaetter: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…
Som | Erigon:Exactly.
Toni Wahrstaetter: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.
Toni Wahrstaetter:And I can definitely see that, because, yeah.
Toni Wahrstaetter:In a world where you would do some distributed proof generation, then you would, of course, need to send that over the wire.
Toni Wahrstaetter: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.
Toni Wahrstaetter:It would definitely save, like, kilobytes of data that will not be needed to be passed to the approver.
Toni Wahrstaetter: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.
Toni Wahrstaetter: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
Toni Wahrstaetter:the block lab access list indices.
Toni Wahrstaetter:So, right now, I've already specced it. If you look into the Discord, there isn't spec implementation, it's…
Toni Wahrstaetter:It's kind of trivial to add the…
Toni Wahrstaetter:Transaction indices, because all the code exists that tracks that.
Toni Wahrstaetter:It's just, it adds a little bit more of complexity, because now we have, like, edge cases where
Toni Wahrstaetter:transaction… We don't include, addresses and their transaction… and the index where they're attached.
Toni Wahrstaetter:if…
Toni Wahrstaetter:they are modified in the same transaction, right? Because otherwise we would have duplicated values. So I think it adds some complexity.
Toni Wahrstaetter:But it might be worth it.
Toni Wahrstaetter:Is there anything else, someone would like to add to that topic before we close that one?
Som | Erigon:I would also like to know if there is someone against it completely.
Som | Erigon:Because there might be some things that I'm missing.
Carl Beekhuizen:I mean…
Carl Beekhuizen: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
Carl Beekhuizen:Once we have this in the protocol, there will be…
Carl Beekhuizen:Someone who uses it, and now this is complexity we have to carry around forever.
Carl Beekhuizen: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.
Carl Beekhuizen:Over-indexing on exactly what we expect.
Carl Beekhuizen:ZK things to potentially look like in the future?
Carl Beekhuizen: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
Carl Beekhuizen:like… The simplest version, without this, and then rather focus on getting the, like, actual scaling benefits.
Carl Beekhuizen:Like, having client teams, like, implement
Carl Beekhuizen: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.
Carl Beekhuizen:Just given what we know for now, that very likely may change, though.
Sophia Gold:Well, I'm not sure I fully understand the,
Sophia Gold:The gain that you get from including these or not. But,
Sophia Gold:Theoretically, like, it should be the same…
Sophia Gold:scaling benefits for clients not in a ZK world, right?
Sophia Gold:Unless people are saying that you're so bound by, a saber computation that
Sophia Gold:You know, we've exhausted the, the benefits of proving, or improving execution for now.
Toni Wahrstaetter:Right, yeah.
Toni Wahrstaetter: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
Toni Wahrstaetter: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.
Toni Wahrstaetter:I would stick to not including them for now.
Toni Wahrstaetter: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.
Toni Wahrstaetter:And, yeah.
Toni Wahrstaetter:We can still add it at a later point. I think, it would not be too late, because it's,
Toni Wahrstaetter:Rather small change.
Toni Wahrstaetter:But yeah, in this case, I would say we just stick to the…
Toni Wahrstaetter:To how it looks… how it is today.
Toni Wahrstaetter:And… Yeah.
Toni Wahrstaetter:Just reading the chat.
Toni Wahrstaetter:Yeah, I agree with Karima.
Toni Wahrstaetter:Awesome.
Toni Wahrstaetter: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.
Toni Wahrstaetter:Because if it doesn't change, then the value you have in cash is still correct, and you might not need it.
Toni Wahrstaetter:But yeah, let's see if we have to revisit that in the future.
Toni Wahrstaetter:Anything else someone wants to add?
Toni Wahrstaetter: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…
Toni Wahrstaetter:See how far we are in terms of
Toni Wahrstaetter:Getting closer to a first effort.
Toni Wahrstaetter:Can we just start with you, Jared, Kev?
Jared Wasinger:Yeah, sure. Yeah, so I'm continuing to work to get the…
Jared Wasinger:the changes merged in Geth,
Jared Wasinger:Not really much of an update in terms of the performance.
Jared Wasinger:Since I gave the numbers from the la- prototype on the last call, yup.
Toni Wahrstaetter:What's your estimate regarding a first deflate?
Jared Wasinger:I, could… Probably could have a branch ready fairly soon,
Jared Wasinger:Maybe… maybe, like, a few days to a week?
Jared Wasinger:At minimum.
Toni Wahrstaetter:Yeah, I guess it will only make sense if we have at least a second client pair.
Toni Wahrstaetter:But this is… this is great to hear. Okay, thank you.
Jared Wasinger:Oh.
Jared Wasinger:It's gonna take longer.
Toni Wahrstaetter:Is that?
Jared Wasinger:to actually get it merged in Geth, though, but… Yeah.
Jared Wasinger:Anyways…
Toni Wahrstaetter:Okay, thanks.
Toni Wahrstaetter:Let's do Aragon next.
Som | Erigon:No updates. Mark from our team would be working on it. He's trying to… improve,
Som | Erigon:our Merkle filtration try calculation, which seems to be the bottleneck at the moment, but no concrete progress there.
Toni Wahrstaetter:Cool, so you're already looking into the…
Toni Wahrstaetter:Parallelizing the stage root computation? Did I get that right?
Som | Erigon:It's already being parallelized, but, we have observed that,
Som | Erigon:it can be optimized quite a lot, or at least needs to be optimized. Something to do with our database, that when you have
Som | Erigon:So we have, some lock FTM parallelization that improves execution time already, without the balls, which is my 2.5x or 3x.
Som | Erigon: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.
Som | Erigon:Which, you know, doesn't make sense, so we'll have to do some work on that.
Som | Erigon:Yep.
Toni Wahrstaetter:Great, thanks.
Toni Wahrstaetter:Then, let's do Netherland next.
Marc: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.
Marc: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 Wahrstaetter:Yes, there are. I would forward that question to Felipe, if he's… Ready?
felipe:Yeah, yeah, I could speak about that.
felipe:We released the first pre-release.
felipe: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.
felipe:And there were, there were some things on the test side as well.
felipe: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,
felipe:Yeah, we should just get out another release, so…
felipe:We have some good test vectors.
Toni Wahrstaetter:Awesome, thanks.
Toni Wahrstaetter: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
Ishika:Not kind of misusing any.
Ishika:And, also, we are working on cleaning up our existing implementations and sort of including the other parts as they come.
Toni Wahrstaetter:Awesome, thank you.
Toni Wahrstaetter:What do you think, regarding, First Step Net? What is kind of the…
Toni Wahrstaetter:The rough timeline, or the planned timeline.
Ishika:As of right, we will take some time.
Ishika: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.
Ishika:What they want to look regarding it.
Ishika:So, it will take some time, I can say, about a week or two for us to, like, have things ready.
Toni Wahrstaetter:Perfect, thank you.
Ishika:And then, peso.
Karim T.: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.
Karim T.:And this week, we will work on the state rule computation optimization, thanks to Block Access List.
Karim T.:So yes, this is the next topic, we'll work on… It's over.
Toni Wahrstaetter:Great, so you would already be ready for a DevNet in this case?
Karim T.:So we have block accesses creation, not block accesses validation, but, I think we will be able…
Karim T.: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.
Karim T.:something we can do, but yeah, I think we should be able to propose block with block access list, normally, yeah.
Toni Wahrstaetter:Awesome.
Toni Wahrstaetter:Thank you.
Toni Wahrstaetter: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.
Toni Wahrstaetter:And, yeah, I guess if we get to a first definite by end of month.
Toni Wahrstaetter:Would already be a great achievement.
Karim T.:Yeah, I think for the end of March, yeah, it would be okay.
Toni Wahrstaetter:Cool Perfect. Did I forget anyone?
Toni Wahrstaetter:Great.
Toni Wahrstaetter:So, is there anything else people want to discuss before we wrap up?
Toni Wahrstaetter:Maybe just to add, I was also discussing with
Toni Wahrstaetter:Of course, because the block of access list is now an ROP and not an SSS anymore, we cannot prove anything against it.
Toni Wahrstaetter:And it would have been kinda handy for pre-confirmas.
Toni Wahrstaetter:So, the question came up is, like, how big of… how…
Toni Wahrstaetter: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?
Toni Wahrstaetter:This is, like… I would assume a bigger topic.
Toni Wahrstaetter:And…
Toni Wahrstaetter: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
Toni Wahrstaetter:Breakout call in two weeks, if this would be something.
Toni Wahrstaetter:we need. So far, it seems like it's only simplifying the work of pre-confirmers and not, like, a big enabler.
Toni Wahrstaetter:But yeah, interesting thought, definitely.
Jared Wasinger:So we would create a try of the hashes.
Jared Wasinger:of… Past block-level access lists?
Toni Wahrstaetter:Yeah, for example, and then you could do an MPT proof against this try, and it would be easier
Toni Wahrstaetter:Yeah, it would be a shorter proof than providing the entire block have access list.
Jared Wasinger:Hmm.
Jared Wasinger:Yeah, it seems doable.
Toni Wahrstaetter:Yeah, we can… I can put it on the agenda for the breakout call in two weeks. We can discuss it,
Toni Wahrstaetter:Definitely, for sure, it needs to give us some big advantages to, yeah, be worth the changes.
Toni Wahrstaetter:But, yeah, let's see.
Toni Wahrstaetter:Great. Is there anything else?
Toni Wahrstaetter:Someone wants to add?
Toni Wahrstaetter:Otherwise, we would just wrap up.
Toni Wahrstaetter:Awesome.
Toni Wahrstaetter:Then, thanks everyone, and see you…
Toni Wahrstaetter:At the next breakout call in 2 weeks.
Jared Wasinger:Yep, bye.
Som | Erigon:Bye. Thank you.
Karim T.:Motion.
Ishika:Thank you.
Chat Logs
00:01:30
Toni Wahrstaetter:Agenda:
https://github.com/ethereum/pm/issues/1708
00:05:41
Karim T.:Non only the key location but also the values of the key we are reading in this case for stateless
00:15:04
Jared Wasinger:Did you mean reads overall or just the tx index karim?
00:18:30
Karim T.:It could be in a next step, when BAL v1 is working correctly thinking about a next step
00:18:32
Jared Wasinger:Worst-case disk read blocks would be interesting
00:19:04
Jared Wasinger:Replying to "It could be in a nex..."
Yeah, we can always update the format in a future fork
00:19:23
Toni Wahrstaetter:Replying to "Worst-case disk read..."
yeah agree, or worst-case exeuction (e.g. modexp)
00:19:25
Karim T.:Replying to "Did you mean reads o..."
Reads overall, if you want to use it for running a transaction on a node without the state
00:19:43
Toni Wahrstaetter:Replying to "It could be in a nex..."
agree yeah
00:20:12
Sophia Gold:Generally you use GPUs or ASICs for proving and the execution remains on CPU
00:22:43
Ishika:Have no strong opinion as of now abt including indices,will talk with the reth team and add :)
00:22:49
Karim T.:I think for ZK if you want to run your block in riscv and generate the trace. It will be a stateless execution so you need read values + write + code not only read index
00:25:53
Karim T.:I think using BAL for ZK trace generation will be nice. But it should be not in production for the moment as ZK trace is far for being in production on mainnet
00:28:43
Som | Erigon:Also saves the 2 seconds before proving can begin
00:33:05
Karim T.:I think it’s too soon to think about modification of BAL for ZK , nothing is really defined , it’s still research
00:44:51
felipe:Thanks