Toni Wahrstätter:Great, thank you very much. Hello, everyone. Today is February 11th. Welcome to the EIP-7928 breakout call number 11.
Transcript
Toni Wahrstätter:We have a quite light agenda today, I would say. Of course, I've said that earlier… I've said that before, and it wasn't that light, but…
Toni Wahrstätter:Today, it looks like we only have two items, and of course, some client updates, splash definite updates.
Toni Wahrstätter:let's directly get into it. I've posted the agenda into the chat, so everyone can have a look. The first item would be
Toni Wahrstätter:as usual, every two weeks, getting some updates on the optimizations at clients. We've just launched DevNet2, it would be great to know
Toni Wahrstätter:from each client team, which optimizations, parallel execution, parallel I.O,
Toni Wahrstätter:and the parallel state route optimization, which of them is already implemented on DevNet2, and which one can we already use for benchmarking?
Toni Wahrstätter:Maybe we can start with, let's start with Kef.
Toni Wahrstätter:Okay, I see Jared is not in the call today, then… Let's… go for Besu.
Karim T. (matkt):Yes, so all of the optimization already. We had some issue, last week with the prefetch, but we fixed that.
Karim T. (matkt):So, for the moment, we have two branches, DevNet2 2, so in DevNet2 2, we have…
Karim T. (matkt):parallel execution, state routine background, and we have DevNet2 2 with this prefetch.
Karim T. (matkt):Where we have state routing background, parall execution, and batch I.O. So…
Karim T. (matkt):I asked Stefan to have two nodes, like that, with a different approach, just in case the prefesh can add some issues.
Karim T. (matkt):But yeah, normally the three implementations are present. We have a first implementation of the prefetch, but…
Karim T. (matkt):Mirgi is working on another optimization, in order to have maybe better performance with the prefetch.
Karim T. (matkt):We'll see later.
Karim T. (matkt):But yeah, for the moment, we have everything, and still trying to optimize more.
Toni Wahrstätter:Okay, this is… this is great to hear. So Beso is essentially at the point where it's fully ready.
Toni Wahrstätter:to be used for any kind of benchmarking. Of course, there might be further optimizations being rolled out, but…
Toni Wahrstätter:In general, the optimizations are there, which is great to hear.
Toni Wahrstätter:Thank you.
Toni Wahrstätter:Let's continue with… Ref?
Dragan Rakita:We are working on that. I think we are missing the parallel execution, and…
Dragan Rakita:I think the team is working on… or at least have something on the parallel state route.
Toni Wahrstätter:Okay, great. What about the I.O? Has that already been worked on, or is that, like…
Toni Wahrstätter:Delayed until after parallel execution state route.
Dragan Rakita:I'm not exactly sure, to be honest.
Dragan Rakita:I think it's delayed, and it will be done later.
Toni Wahrstätter:Okay, yeah, no worries, we can… we can follow up async, too.
Toni Wahrstätter:Let's continue with… with Nethermind.
Marc:Alright, so I'm working on the, parallel execution at the moment, and it's progressing, but yeah, not all the tests are passing yet, so it's not ready for,
Marc:To run tests on yet.
Marc:But yeah, we've mostly just been working on, kind of, getting the, sort of, base implementation, like, kind of tidied up and optimized and ready to merge.
Marc:And also worked on the kind of early, blocking validation, and I found maybe, like, a small thing to discuss with the, optimization around the storage re…
Marc:like, the thing that you would, the document you sent Tony. But yeah, maybe we could, discuss that later.
Toni Wahrstätter:Okay, yeah, let's discuss that, later, it's, it's on the agenda anyway, so… We'll get to that.
Toni Wahrstätter:So, just to summarize, you're working on the parallel execution and patch I.O. and…
Toni Wahrstätter:The parallel state route will then follow afterwards.
Marc:So, more working on the parallel execution. The parallel state route is kind of implemented, but I can't really kind of test if it's fully working until everything's working.
Marc:And then, I think the batch I hadn't started on, but I think it kind of makes sense to do that once the rest is working.
Toni Wahrstätter:Okay, great. Thank you.
Toni Wahrstätter:Dan, do we have someone from Erigon who can give us an update?
Toni Wahrstätter:If no one from Erigon is here, we can also follow up async, I think.
Toni Wahrstätter:Jared arrived in the meantime. Jared, we were already talking about client updates on the optimizations. Do you have a quick update on which optimizations are ready to be tested with Definit2 ready releases, and…
Toni Wahrstätter:Can be used for benchmarking.
Jared Wasinger:Yeah, sure. Yeah, so I've implemented 3, like, performance presets in Geth, so one of them is…
Jared Wasinger:sequential every… like, basically,
Jared Wasinger:sequential execution, and see… and… essentially how Geth executes blocks now, or how Geth…
Jared Wasinger:Would execute a block without,
Jared Wasinger:a block that posts Amsterdam that doesn't contain an access list, and then another one is,
Jared Wasinger:We have parallel execution, parallel, state root calculation, and then…
Jared Wasinger:The async loading of, state reported as, accesses in the access list?
Jared Wasinger:And then there's also an option that's a variant of this, except disabling the…
Jared Wasinger:batch I.O. is what it's being called,
Jared Wasinger:So, 3 of the… all 3 of these presets are, able to be enabled via flags.
Jared Wasinger:The…
Jared Wasinger:So I've been testing this on one of the nodes on the DevNet, and there seems to be some kind of issue…
Jared Wasinger:Because I've also coupled these changes with some fixes to the miner, or to the payload building, and there's some…
Jared Wasinger:issue with block building that,
Jared Wasinger:I'm still working to address right now.
Jared Wasinger:So, yeah, that's kind of the update for Geth.
Toni Wahrstätter:Awesome, thanks a lot.
Toni Wahrstätter:This sounds like, Besu and Geth are essentially ready to be used for benchmarking.
Toni Wahrstätter:And the other clients are also getting there, which is great to hear.
Toni Wahrstätter:Yeah, would be great, Charity, if you could let, Stefan know which flags,
Toni Wahrstätter:to be used for Geth, such that Stefan can add it to his stock, that is very useful.
Toni Wahrstätter:Awesome.
Toni Wahrstätter:But this brings us to the DevNet updates already. Maybe, Stefan, could you give us a…
Toni Wahrstätter:A quick update on the… on the DevNet, how everything's going, and your plans.
Stefan Starflinger:Yeah, sure. So, it's been going pretty well now. It was a little bit…
Stefan Starflinger:I think Nethermind had some small issues, and REST some small issues in the beginning.
Stefan Starflinger:But I think it's going pretty well. Just now, we got an awesome block on REST that might be worth looking into.
Stefan Starflinger:But I think in general, we're…
Stefan Starflinger:pretty stable. Still some tests that would be good to look into. I also saw that the testing team needs to rebase something so that PR from Nethermind will go through.
Stefan Starflinger:But otherwise, I'm looking into how exactly we can do the benchmarking, so just…
Stefan Starflinger:Doing, like, the sanity checking, it's probably not the best environment, the bell.
Stefan Starflinger:Definitely too to have benchmarks that are gonna be used to make any decisions on, but it would be great if we could have everything ready and know exactly how we want to benchmark, so that everything will be working when we actually do
Stefan Starflinger:For example, a shadow fork later when all the clients are ready.
Stefan Starflinger:So right now, I started, just looking, at the Promethos metrics.
Stefan Starflinger:To get some insights, so if there's any metrics that you'd like to add, or that you're still adding.
Stefan Starflinger:that I can then include into some analysis, some sanity check, to see if some optimizations are actually making
Stefan Starflinger:execution faster. It would be great if you could give me some information on that. I see Joachim, you're raising your hand.
jochem-brouwer:Yeah, I wanted to raise one general point about benchmarking, because I think there are… for the block access list, there are two ways, or maybe even three ways, to think about the benchmarking here. The most obvious one is about the execution.
jochem-brouwer:So, what the benchmark there does is you check if clients have reached
jochem-brouwer:a certain level of optimizations utilizing the block access list, and the most obvious one is parallel execution. But there's also this other benchmark, or…
jochem-brouwer:benchmarks as a problem, what we might turn into. It has to do with the sync.
jochem-brouwer:And this is something which we should also benchmark, because if a client falls behind, And,
jochem-brouwer:Sorry, it's not falling behind, but the chain is reorgan. If it then has to reconstruct the chain, but it has to…
jochem-brouwer:request blocks over DevP2P. This means that these blocks do not have the block access list, so you cannot utilize the parallel execution.
jochem-brouwer:And then the question is about, like, how do we benchmark slash test the syncing process in that case?
jochem-brouwer:And I think, you mean here mostly benchmarking the execution part, but I wanted to mention that there are other scenarios which we should also test slash benchmark.
Stefan Starflinger:I think if we benchmark the execution part, I think that's already a very good step in the direction of benchmarking the syncing, because the syncing is just…
Stefan Starflinger:I guess the execution, multiple times in a row, because you just apply all of the blocks quickly. But in general, yes, we should for sure test that as well. We have the sync core.
Stefan Starflinger:for that, so maybe we can add something there, but in general, I think the first step, from my perspective, would be how can we combine it with a benchmarker that,
Stefan Starflinger:guy that Rafael is currently building.
Stefan Starflinger:And I think we should spend some time there, to see that we can capture and test those metrics.
Karim T. (matkt):Also, I think when we talk about printing block access deeds, we said we should keep a minimum amount of block access deeds without… before the printing.
Karim T. (matkt):So I think if a node is behind, it should be able to do parallelization.
Karim T. (matkt):So, if you are… if your node is really stopped during a…
Karim T. (matkt):A lot of weeks, maybe, it will be a problem, but if it's just some blocks, I think you will be able to retrieve block access lists from other peers.
Toni Wahrstätter:Right, yeah. Yeah, just to get back, Johan, to your direct example, exactly what Kareem just said.
Toni Wahrstätter:there will be, so your EL clients keep enough block lab access lists around to always be able to serve you block lab access lists until the week's objectivity period, which is roughly, yeah, a little bit over two weeks.
Toni Wahrstätter:So in that period, you will always be able to, re-execute, and if you fall further behind than the weak subjectivity period, then you need a checkpoint anyway. So at that point, you would need to do the snap sync or something, or apply the ball, basically, to your state.
Toni Wahrstätter:But within the week's subjectivity period, so for roughly 2 weeks, you will always be able to have the same execution speed as if you would just execute at the head.
jochem-brouwer:Yes, but… But I definitely…
Toni Wahrstätter:Yeah, go ahead.
jochem-brouwer:Yeah, yeah, okay, maybe I'm just thinking, like, about the incorrect way, but if the chain is reorging, and we are, we are not getting the blocks over… via the CL, so via the engine API, but instead we have to request the blocks over DevP2P,
jochem-brouwer:In that case, we do not get access to the block access list, right?
Toni Wahrstätter:Why not? So every block would still be mapped to a block lab access list. Of course, if you reorg a block, then you would also have to reorg the…
Toni Wahrstätter:attached access list, but I'm not seeing why this is a problem.
jochem-brouwer:Okay, yeah.
jochem-brouwer:might have to do some more research, but I thought that if you… if you reorg and you have to, like, especially if you request a box over DevP2P, then you do not have the book.
Marius van der Wijden:You're welcome.
jochem-brouwer:Yeah.
Marius van der Wijden:Johann, the blocks are available via DevP2P, or at least they should be with ETH71, right?
jochem-brouwer:Yes, but the block access is not part of the block body, right? So it will not be sent.
Toni Wahrstätter:You would just request it separately, and then directly verify what you got against the header, because the bul hashes in the header. So you would request from DevP2P, and then hash it, compare it against the header, and as of that moment, you know it's part of this block.
jochem-brouwer:Right, but then still, the block access is not part of the block body, so it is not part of the DevB2P response.
Toni Wahrstätter:Not of that… of that request, yeah. There is a new… there is a new EVE71…
jochem-brouwer:Yo!
Toni Wahrstätter:It's not yet merged, but there is a def P2P PR.
jochem-brouwer:I see. Okay, then, yeah.
Toni Wahrstätter:So there's a new method, like getReceipts, get bodies, getHead, and then there is getBAL, or get block access list.
jochem-brouwer:Okay, cool. Yeah, then, for this, for that, process, we would need… we would require EF71. Yeah, okay, cool. I was not aware of this, EF71.
Toni Wahrstätter:This is going so fast, like, we get EV70 and only EV71. Yeah, I just… I just pumped the version yesterday, so it was… it was… the PR had EVE70 previously, and now it's EVE71.
Toni Wahrstätter:I don't think clients have implemented that yet, but yeah, this might be needed exactly for the reasons we just discussed, to enable your node to catch up
Toni Wahrstätter:In case it needs to do beacon sync.
jochem-brouwer:Yep, cool, cool, nice, great.
Toni Wahrstätter:Awesome. Is there anything else, regarding that topic that we should discuss?
Toni Wahrstätter:I know that FP2P spec has not yet merged, so we might… I might want to get that merged soon.
Toni Wahrstätter:So that, clients can actually start implementing it, and we have it at DevNet3.
Toni Wahrstätter:Or is anyone… Opposed to that.
Toni Wahrstätter:I guess this depends a little bit on the process, right? Because ETH70 is not yet, rolled out.
Toni Wahrstätter:So we might not be able to roll out E71 in this case, but yeah, I will have to double-check with that P2P people.
Toni Wahrstätter:Anything else on that topic?
jochem-brouwer:Yeah, I can maybe chime in on Stephen's question about the benchmarking and the testing.
Toni Wahrstätter:Yeah, please go ahead. Yep.
jochem-brouwer:Yeah. Yeah, so,
jochem-brouwer:So we have this, the east benchmarking, so, east benchmarks are basically just east tests.
jochem-brouwer:Being written, and we run these in the benchmarker.
jochem-brouwer:And this benchmark is a tool where, well, the output of this tool is how fast your blocks run.
jochem-brouwer:What we need for the book access list is we need to write, benchmarks specifically for book access lists. And the reason for this is that,
jochem-brouwer:currently, most tests, they can already be run in parallel, because transactions, they do not interact with each other. So we need to write specific tests, which mean you have to optimize specific parts of your client.
jochem-brouwer:In order to check that you have, you are doing this optimization correctly.
jochem-brouwer:I'm not sure, because I think…
jochem-brouwer:But correct me if I'm wrong, I think, Philippe, you wanted to help or take this on, in ease to write these, tests? Is that correct?
felipe:Yeah, yeah, I'm definitely happy to help here. One of the first steps that we need is to be able to fill for Amsterdam.
felipe:And… Thanks to Spencer.
felipe:and some of… some of the work that I did building on that yesterday, I… we are…
felipe:I posted in the chat here, but…
felipe:We have some development branches of Geth that we're able to fill for Amsterdam now, so we can start, concentrating
felipe:On writing some benchmark tests.
felipe:that are bowel-specific.
felipe:And really start, kind of, kind of testing
felipe:The benchmarks there now, which is… which is great, so…
felipe:But yeah, as far as I know, you had some, some earlier thoughts on… on how to, how to, write benchmark tests for… specifically for bells that don't allow other sorts of parallelizations, right?
jochem-brouwer:Yes, yeah, I'm just seeing your chat indeed, yeah. Yes, so we have to specifically think, like, how can we… you can think of these tests in two ways, like.
jochem-brouwer:how can we write, like, very optimal block access list, tests?
jochem-brouwer:which would then run, like, very nice, or how can we actually abuse the optimization system? And that's, of course, what we want to test and what we want to do, because we do not want to, that clients implement, like, very greedy optimizations, which can be abused.
jochem-brouwer:So, these tests, they have to be written, and these tests are then converted into this benchmark format, and we can then execute these for benchmarks. But for this, there is one…
jochem-brouwer:a thing I'm not…
jochem-brouwer:entirely getting, because this, the benchmark, what it does is it matches the time of the new payload and the fork choice update. And I see in the engine API that, of the new, the new payloads, the block access list is part of it.
jochem-brouwer:And I was slightly confused by this, but maybe I'm not… anymore.
jochem-brouwer:No, that's… that's actually Phil… that's actually right.
Toni Wahrstätter:You're correct, yeah. The policy is in the execution payload.
jochem-brouwer:Yes, yeah, you are right, yeah, yeah, that makes sense.
jochem-brouwer:What did I want to check here?
jochem-brouwer:Yes, so, oh, where are my notes?
jochem-brouwer:Yes, so there are 3 things, or maybe even 4 things here, what we need to benchmark and check. So, as I said in previous discussions also, that
jochem-brouwer:there is this implicit part of this EIP that it unlocks, and it also somewhat makes it mandatory that clients implement these optimizations, and the most obvious one is the parallel execution.
jochem-brouwer:What we should do here is, write benchmarks, which would normally perform, like, very bad.
jochem-brouwer:on clients, for these three optimizations. So we have parallel execution, we have the, the parallel state route calculation, so you don't have to execute transactions, you can just calculate the state route.
jochem-brouwer:Without, executing anything. And, of course, the prefetcher, and for this prefetcher, the most obvious case would be, like, to…
jochem-brouwer:to access or to edit as many storage slots as possible. And there is one thing… This is why I got slightly confused, I think. Because I initially thought that we can easily benchmark this by
jochem-brouwer:Providing clients with either the data which has the block access list, and also the one where we don't have access to the block access list.
jochem-brouwer:But this is not possible, because in the benchmarker, we execute the new payload, and the focus updated, and we therefore always have the block access list available. But I also know that clients expose these optimizations via a flag.
jochem-brouwer:And I think that will be then the way to test this. So what we will do is we test the client.
jochem-brouwer:configured without these optimizations, and a client with these optimizations, and then the difference between these two, that should give an indication if the optimization is
jochem-brouwer:Implemented correctly, if that, makes sense.
Toni Wahrstätter:Yeah, exactly, this makes a lot of sense.
Toni Wahrstätter:Also, what she said about the test cases, that we should think about the freedom from parallelizations and have test cases individually
Toni Wahrstätter:Crafted for each of those.
Toni Wahrstätter:Makes a lot of sense, yeah. Thanks a lot for the update.
jochem-brouwer:Yeah, and there's one final comment I wanted to make that's about the sync process, so we should also think a little bit, like, how are we going to test, because this is, I think, like, very, very important.
jochem-brouwer:Because this VORG situation, we also need this in combination then, we need to test this in combination with EVE71.
jochem-brouwer:Because, in this case,
jochem-brouwer:without EVE71, then this is a situation where a client falls behind, it has to, or doesn't really fall behind, but it has to reorg, but now it does not have access to these block access lists if you are not on EVE71. So this means that block access is implicitly, also mandate that clients implement EVE71.
jochem-brouwer:And we should also test this, and oh yeah, because, Stefan, you talked about… you just talked about this Syncor thing. I am not… I was not aware of this tool.
jochem-brouwer:But do you think we could, like, integrate some kind of setup with Syncore and Benchmarker to also, well, benchmark the Syncore, if that makes sense?
Stefan Starflinger:I'll have to get back to you on that. I'm not sure if those two tools are compatible. In general, Syncro just tries to do a checkpoint sync.
Stefan Starflinger:But maybe we can have something running
Stefan Starflinger:As well, that can capture some benchmarks during that time.
jochem-brouwer:Yeah, okay, yeah, yeah, yeah, so just to clarify what we want to benchmark in this situation is, like, the reorg situation, that clients have to, fetch these blocks over DevP2P.
jochem-brouwer:and therefore also have to fetch these block access lists over the FP2P. Because in this situation, if you do not fetch the block access list, then you cannot do the parallel execution, you also cannot do the statehood calculation without executing the transactions. And that just means that in the worst-case situation, we have, like, a very bad performance impact.
jochem-brouwer:Because if you say block access, they unlock, like, 4 times or whatever execution speed, then in this case, that's not possible if you do not have the
jochem-brouwer:block access lists, and… Therefore, this should definitely be part, also, of the benchmark effort.
Toni Wahrstätter:Right. Yeah.
Toni Wahrstätter:Yeah, I think it's fair to assume that,
Toni Wahrstätter:we… in any case, we always need to guarantee that the block of access lists are available for re-execution, at least within the accept activity period. But definitely worth to… to have that, figured out. And yeah, as Stefan said.
Toni Wahrstätter:the sink coal… Might be the right opportunity there.
Toni Wahrstätter:To have a focused session on how to use BALS for syncing.
Toni Wahrstätter:I see there is a question in the chat.
Toni Wahrstätter:Right. Yeah.
Toni Wahrstätter:As also, I'm just reading the chat, we have to… we have to be smart about, how to benchmark the clients in order to make sure that
Toni Wahrstätter:Yeah, the environment we set up is similar for each client, so not, like, have them fight over course or threats.
Toni Wahrstätter:Great, is there anything else regarding the benchmarking? So, just to summarize, BSW and Geth are essentially, benchmark
Toni Wahrstätter:ready. Other clients are… Getting there.
Toni Wahrstätter:We would probably be able to benchmark execution-related things on the DevNet directly. For state-related stuff, we would probably need a shadow port, but it's… yeah, it's good that we
Toni Wahrstätter:have DevNet2 now going, and clients are…
Toni Wahrstätter:Ringing out the last bugs, so that we then, when it comes to shadowing, shadow forking mainnet, there are no bugs that actually directly kill the… kill the network.
Toni Wahrstätter:Great.
Toni Wahrstätter:Anything else on that topic? Yeah, go ahead.
Łukasz Rozmej:About ETH71, so,
Łukasz Rozmej:I understood that it's defined that there's a separate message for getting the balls. Maybe when we request block bodies, if balls are available, they should just be returned in that message.
Łukasz Rozmej:Is that possible?
Toni Wahrstätter:That, that's possible too, of course. I was, I was…
Łukasz Rozmej:It would be easier.
Toni Wahrstätter:Probably be cleaner to keep them separate, because they're not…
Toni Wahrstätter:part of the EL block body.
Toni Wahrstätter:Right, so it's actually conceptually… You would actually go into different databases, right?
Łukasz Rozmej:Okay, so it depends, really,
Łukasz Rozmej:Yeah, to some extent you're right, but in case of implementing,
Łukasz Rozmej:pipeline that gets blocks and processes them, it's easier to have them just in one place, right, if they are available in one message, rather than, okay, those messages already returned a few blocks I want to process, but now I haven't got access list for them yet.
Łukasz Rozmej:So I'm kind of blocked here, it's… Yeah, it's somewhat less…
Toni Wahrstätter:More complex, right?
Toni Wahrstätter:But that would be a bug, right? Because if a…
Toni Wahrstätter:if someone provides you a block body, but not an access list, this is, like, a weird situation. It's almost like a peer gives you a body, but no receipt.
Łukasz Rozmej:Networking is unstable, right? So, maybe those packets got lost, maybe something, right?
Toni Wahrstätter:Right, but it would be essentially the same if the client doesn't provide you the receipts or something, right?
Łukasz Rozmej:Yes, to some extent, yes. So, maybe it's not that big deal, but it will make implementations more complicated a bit. Not maybe not something to worry about too much, but…
Łukasz Rozmej:Fine.
Toni Wahrstätter:Yeah.
Toni Wahrstätter:Okay, yeah, thanks a lot, good to know, definitely chime in in the…
Toni Wahrstätter:DeafP2P PR that I created. I can post it into the chat as soon as I find it. There's currently still some discussion about the PR,
Toni Wahrstätter:how to best proceed, I posted it into the chat now.
Toni Wahrstätter:So, yeah, feel free to chime in there, voice your opinion.
Toni Wahrstätter:I also, proposed,
Toni Wahrstätter:yeah, some optimizations, how the ball could be, how we could kind of filter out the reads from the ball when it comes to the FP2P, that might be kind of simple to add, but nothing to bring up today in this call, so feel free to have a look.
Toni Wahrstätter:Regarding the FP2P PR.
jochem-brouwer:Yeah, one… Awesome. Sorry, again.
jochem-brouwer:Can I also add these to, as a networking EIP? Because I was looking at the EIPs, and I could not find it, and, like, in DevPTP, it's the correct location, but it should also have an EIP for each71.
Toni Wahrstätter:Okay, yeah, if that's the… the, best practices there, I will… I will be…
jochem-brouwer:Yep.
Toni Wahrstätter:to do so.
jochem-brouwer:Google. Perfect.
Toni Wahrstätter:Anything else?
Toni Wahrstätter:Otherwise, we would proceed with the next agenda item, which would be…
Toni Wahrstätter:The early biorejection topics we discussed two weeks ago.
Toni Wahrstätter:Mark already brought it up today,
Toni Wahrstätter:Just to summarize, two optimizations were two different things. One of them was very simple cap on the items in the bowl. So basically, each item in the bowl
Toni Wahrstätter:Costs at least, 2,000 gas to access with today's prices. That's the…
Toni Wahrstätter:The cost to put an item on the access list, and the cost to access a warm state location.
Toni Wahrstätter:So that's 2,000 gas. And based on that, you can already tell if a block is invalid or not, because if the bar claims to access more items than the gas limit would allow, then clients should already invalidate the block. And to make sure this is, like, a strict
Toni Wahrstätter:requirement, I would suggest we put that into the… into the specs.
Toni Wahrstätter:Essentially, have a static check on the ball.
Toni Wahrstätter:that, that isn't really a limiting factor at all, because, it allows to use the full block gas limit for anything, but it's just, a measure against a DOS attack by a malicious builder.
Toni Wahrstätter:And the second item was how to invalidate BALS as early as possible, and regarding that, we discussed the blog post I had on Leaf Research two weeks ago.
Toni Wahrstätter:which, essentially, said that
Toni Wahrstätter:After executing transactions, we need to keep track of how many items in the ball have already been accessed, versus how many have not been accessed yet.
Toni Wahrstätter:And then knowing how many have not been accessed yet, and knowing the gas remaining of the block.
Toni Wahrstätter:One can also tell if this block is even realistic.
Toni Wahrstätter:To be executed successfully.
Toni Wahrstätter:And…
Toni Wahrstätter:Those were the two optimizations. One of them, the strict cap would be a consensus rule, and the other would more be an implementation detail within clients to… as a measure against DOS attacks.
Toni Wahrstätter:So, Mark, you already brought that topic up earlier. Do you wanna start?
Marc:Yeah, I mean, just a quick question on what you said there. So, you're talking about, accesses, so do you think… I mean, I guess you could do it with both reads and writes, like this heuristic? At the moment, I just implemented it for the reads, but do you kind of see it being used across both?
Toni Wahrstätter:So REITs is, of course, the safe way, because REITs are more expensive, so you would actually be overly strict in that regard, and if you kind of take the cheapest
Toni Wahrstätter:Gas, that you can…
Toni Wahrstätter:like, what is the cheapest? Of course, if there is a storage diff in the bul, you can assume that there was a write happening, basically.
Toni Wahrstätter:For each storage, slot.
Toni Wahrstätter:But this was just, to simplify it, to have it, calculated based on the reads. But you're basically proposing
Toni Wahrstätter:To have the… the storage writes in the bulb be…
Toni Wahrstätter:Priced higher with their actual gas consumption in that check.
Marc:I wasn't really proposing it there, actually, I was just asking, asking which one you meant, just because, you said accesses, I wasn't too…
Toni Wahrstätter:I see, okay. Okay.
Marc:But yeah, but the thing actually… oh, sorry, go ahead.
Toni Wahrstätter:No, no, just as you said, I wasn't really, going, thinking that much or that detailed. I was more thinking about how can this check be done as simple as possible.
Toni Wahrstätter:With existing constants that we already use in the, in the specs.
Marc:Okay, cool. Yeah, I see. But yeah, the main thing I wanted to raise is, I think, it doesn't account for, like, using the gas remaining, doesn't account for the few, system contracts that are executed at the end.
Marc:which aren't using gas, so when I implemented it, like, it was getting some false positives because of that. So I had to change it to, like, exclude these,
Marc:Like, post-execution, changes.
Marc:But that's just, like, a small tweak, really.
Toni Wahrstätter:Interesting. So you say we must… before… after counting the items in the barrel, we must filter out the items that originate from system contract calls.
Marc:Yeah, so yeah, if you're comparing.
Toni Wahrstätter:Yeah, that's a good point.
Marc:If you're, like, gen… say you're, like, generating it, and you're, like, on the last transaction, so you can say there's zero gas left, but you can see there's still a few more, like, reads in the, like, to-go, so you're gonna reject it, but that's because those are actually paying
Marc:no gas, right? So yeah, I think there's different ways you could fix it, but probably the simplest one is just to completely filter those out.
Toni Wahrstätter:Right, yeah, I will… I will look into this. I think the items that are in the bowl because of system contract calls are…
Toni Wahrstätter:Very limited anyway, so it's probably, like, the max number of items minus 10 or something.
Toni Wahrstätter:But yeah, good point. This is definitely something we should do.
Toni Wahrstätter:Because, of course, the goal here is to not be limiting at all, so the gas used, a gas limit would still be the only limiting factor here. This is just to allow us to statically detect an invalid block early on.
Toni Wahrstätter:And yeah, without Mark's suggestion here, we would, actually be overly strict, even though it's just a few slots, but still, I will update the specs, PR, and also the PR against the EAP, because this is, like, the consensus change here.
Toni Wahrstätter:Is there any other comment regarding those two approaches?
Karim T. (matkt):I just wanted to ask a question. You are saying, doing… we should do this check periodically. I'm not sure to understand why we cannot do that for each transaction.
Toni Wahrstätter:You could do it for each transaction, too, yeah.
Toni Wahrstätter:I was just thinking, like, minimizing overhead.
Toni Wahrstätter:So, you could do it, like, every 8 transactions, because if you have, like, 8 threads in theory, then…
Toni Wahrstätter:8 max size transaction would be parallelized, and only after the 8 transaction you actually get some meaningful result. This was my line of thought, but it might not make sense, so this is a client, implementation choice, I guess.
Karim T. (matkt):Okay.
Toni Wahrstätter:Yeah, just to clarify, one can do the check after each transaction.
Toni Wahrstätter:It shouldn't matter. You would even, catch invalid blocks earlier.
Toni Wahrstätter:Perfect.
Toni Wahrstätter:Yeah, if there's nothing else, I would definitely then go on with, modifying the first,
Toni Wahrstätter:two PRs to the specs and the EAP and make sure Mark's, input is incorporated.
Toni Wahrstätter:regarding the second, check, remaining gas versus untouched items, this is just a line, I think it's in the security consideration or in the rational in the EAP, as this is not really something that
Toni Wahrstätter:is specced.
Toni Wahrstätter:Just as a heads up.
Toni Wahrstätter:Before we move to our next topic, anything regarding invalid spells?
Toni Wahrstätter:Just one more thing. We have a tool that allows you to modify the bul in the engine API, which we can later on use to actually test that on a testnet.
Toni Wahrstätter:But I guess we don't need to test those things on a definite yet, so…
Toni Wahrstätter:we can, we can delay that, invalid ball testing, I guess.
Toni Wahrstätter:As in theory, it should just work.
Toni Wahrstätter:We will then see on the testnet if it does.
Toni Wahrstätter:Of course, we could test it earlier, but not sure if it's worth it.
Toni Wahrstätter:Great.
Toni Wahrstätter:Yeah, happy to have it, proud of the benchmarking efforts, too. Of course, this requires, like, passing a malicious bul to the EL. I'm not sure if we have the testing framework ready for that, but if it's possible, we should definitely do that.
Toni Wahrstätter:If it's not too much work.
jochem-brouwer:Yeah, I think it's just, yeah, go ahead. It's just adding, it's just passing it, like, as a new payload, right? So that should work directly, I would say.
Toni Wahrstätter:Yeah, it's a malicious pedal, basically, where the ball is.
Toni Wahrstätter:Different from what they pay. From the transaction, what they actually access.
Toni Wahrstätter:Great, and then the last point I have on the agenda is regarding the JSON RPCs.
Toni Wahrstätter:I wanted to get a quick check if clients have already implemented the JSON RPC methods for DEFNET2. I saw Geth did already, but I wasn't sure about the other clients, so if clients could give me a quick update if the
Toni Wahrstätter:JSON RPC methods are actually implemented.
Karim T. (matkt):Well, this is normally it's implemented, yeah.
Toni Wahrstätter:Awesome.
Toni Wahrstätter:Implemented for Peso, Nethermind, and Geth, I can see.
Toni Wahrstätter:One thing…
Toni Wahrstätter:I missed, and this is probably… this was my mistake here. So far, the JSON RPC specifications, how I did them by the time, was having the bytes, so basically the RLP text string in the…
Toni Wahrstätter:response from the Chasener PC.
Toni Wahrstätter:And recently, someone brought up that this should actually be the the object in JSON format.
Toni Wahrstätter:So I'm wondering if this is something we can do until DevNet 3, basically taking the RLP
Toni Wahrstätter:bytes and putting them into the objects when returning them on the JSRPC methods.
Toni Wahrstätter:I saw…
Toni Wahrstätter:Geth is right now returning the bytes as spec'd. I'm not sure if Beso does the same, but I would assume so, right?
Karim T. (matkt):Yes, I think it's later.
Karim T. (matkt):I should check, but normally it's okay. I don't know, Mirgi, if you are here? Can confirm?
mirgee:Yeah, I think so.
Karim T. (matkt):I just have a question regarding the naming. So, in Bezu, we have get block access list by block hash, but in the spec, I see get block access list by hash.
Toni Wahrstätter:Yeah, so I think the difference here is that you say block hash versus…
Toni Wahrstätter:block, right? That's the different… difference.
Karim T. (matkt):So, for sure.
Barnabas:Shh.
Karim T. (matkt):Yes.
Toni Wahrstätter:Okay, and it should be block hash, of course, yeah, that's true.
Toni Wahrstätter:I will fix that.
Barnabas:By number, or by block number?
Toni Wahrstätter:By block number, I guess. I have to double-check that too, but since it's the block number, it should be block number, and there's no pile number.
Toni Wahrstätter:Perfect, okay, I noted that down, I will… I will fix that in the JSON RPC specs, but then, essentially, for DEFNET3,
Toni Wahrstätter:The to-dos would be to put the ball into the JSON object when returning it, And…
Toni Wahrstätter:The JSON RPC naming will be by block number.
Toni Wahrstätter:And by block hash.
Toni Wahrstätter:Is that the correct summary of the three points?
jochem-brouwer:I'm actually, yeah, just thinking about this, because if you would have the, you would normally have the block, header, and then you would likely request the,
jochem-brouwer:the, the block XList hash by that.
jochem-brouwer:I would say, because…
jochem-brouwer:Are there situations where you already have the book access list hash, and you do not have the book header?
Toni Wahrstätter:So usually the mapping is one-to-one, so there can only be one block access list per block.
Toni Wahrstätter:And if you change the block hash, then the block access list would have to change too, so I think this should be fine, and… I would assume it's just the simplest to have it by block number and block hash.
Toni Wahrstätter:I'm, of course.
Toni Wahrstätter:open if clients want to change that to block, to block access list hash and block access…
Toni Wahrstätter:Yeah, it would be block by block access list hash and by block number. So this is, like, not super clean, and it feels like doing both by block number and block hash feels cleaner.
jochem-brouwer:Yeah, I, I think I, I think, I think I agree, yeah.
jochem-brouwer:Yeah, I'm just… I'm just thinking, like, are there situations where there is a… where you have the block access as a hash, and you don't have the block, like, the block hash where this, exists? So someone just gives you this block access as a hash, and you just want to have the contents of this, because then you would want to request
jochem-brouwer:If gets block access list, yeah, by hash, so meaning the block access list hash, not the block hash.
jochem-brouwer:Then it was… Right, but…
Toni Wahrstätter:But I see the only way that you get the hash is by getting the header, and then you have
Toni Wahrstätter:cash, too.
jochem-brouwer:That's right, yeah.
jochem-brouwer:Yeah, okay, I would just think about it some more. We can do this async, yeah.
Ameziane Hamlat:Just related to the… just related to the… Go ahead, yup.
Ameziane Hamlat:Yeah, sorry. So we already have existing, LPC endpoints where we… when we have the block in the name, like the backtrace block, then we just follow either by hash or by number, because we already have the block.
Ameziane Hamlat:So, for example, we have dibetrace block by hash, dibetrace block by number, ETH get block by number, and so on. Maybe we should respect the same investment, the same name.
Toni Wahrstätter:Okay, I see. So you would say we… we should have
Toni Wahrstätter:Get block access list by hash, and get block access list by number, instead of by block hash and by block number.
Ameziane Hamlat:Actually, when you read it like that, it feels like block hash makes sense here. I am not sure anymore, because…
Ameziane Hamlat:Because the… The block hash is the hash for the block.
Ameziane Hamlat:Which is not the same as the block access list, right? Because we'.
Toni Wahrstätter:Yeah, actually…
Ameziane Hamlat:Yeah.
Toni Wahrstätter:Yeah, I agree, I agree.
Toni Wahrstätter:Maybe we should move that discussion, actually, as Barnaby proposes there, implicitly. Barnabas, like, move it into the RPC call, because this fee is, like, yeah, we should get it right, and I'm definitely…
Toni Wahrstätter:Not the right person to decide on that exactly, so what is the right naming there? And probably we just want to follow the best practices here.
Toni Wahrstätter:So, yeah, please chime in in the…
Toni Wahrstätter:in the PR, I will post it into our chat here.
Toni Wahrstätter:Into the agenda.
Toni Wahrstätter:Not in the agenda, in the chat.
Toni Wahrstätter:So please let me know what you think, and we can then figure that out there async.
Toni Wahrstätter:Great. Anything else regarding that topic? Otherwise, we would move on.
Toni Wahrstätter:maybe let's finish the call with some testing updates. I wanted to ask Rahul or Felipe if there… Stefan, is there anything else we should discuss this week regarding testing?
Toni Wahrstätter:Especially if we're focused on DEFNET 2.
Barnabas:Before we move on to testing, could I just pray that we would like to have it simulate RPC call implemented in the next Debnet as well?
Barnabas:So it would be very good if, all the client devs look into that.
Toni Wahrstätter:Okay, perfect. So that was eaves simulate, should be implemented in DevNet3, yeah.
Toni Wahrstätter:Okay, yeah, please, clients, look into that.
Toni Wahrstätter:And then… Is there any… is there any news regarding testing? Anything we should, pay attention to?
raxhvl:There's, like, a new test that tests for…
raxhvl:the EIP2935, for historical block hash.
raxhvl:That's… that's in progress, so that's a new system contact that will be covered in the next release.
Toni Wahrstätter:Perfect, thank you.
felipe:Yeah, as far as more testing,
felipe:I think, yeah, there's still a few tests, for bells that are coming out, just to extend, coverage, but,
felipe:Maybe some of the things to address are the remaining failing tests that are already out from the last release.
felipe:And some of these are related to only,
felipe:The exception mismatch, and so there are invalid tests that are correctly invalid.
felipe:But some clients have… are… are raising, the unexpected, exception there, and so…
felipe:These should be fairly simple fixes. If clients can make them, yeah, that would be great. Otherwise…
felipe:I will try to find some time to submit PRs for each of these clients.
felipe:To at least get these invalid tests passing, but, we should look at the ones that are not related to this, and just have clients start getting all of these tests passing. Would be… would be priority.
felipe:And then again, the benchmark tests
felipe:are the next focus on the testing front, and we're making good, good progress here. And it seems like
felipe:We may be, starting to use Geth for our benchmark releases, which is…
felipe:If anyone has been involved in the benchmark testing at all, Geth is about 5 times faster in some cases than EVM1 was, which we were using for benchmarking, and so…
felipe:This is gonna be a really nice, update there as well.
Toni Wahrstätter:Awesome, thank you very much for the update.
Toni Wahrstätter:Great. Before we end the call, is there anything else We should discuss today.
jochem-brouwer:Yeah, I have, two more questions, sorry. The first is, did we already check?
jochem-brouwer:the interactions with other Glamsterdam proposed EIPs.
jochem-brouwer:Because I could see interactions with the reduced intrinsic transaction guess. This will increase the amount of transactions per block.
jochem-brouwer:This could theoretically also increase the max-sized book access list, and maybe also the repricings that could also impact this, in case that some prices are lowered.
Toni Wahrstätter:Yeah, I think we are safe on that front, because the worst case is very clearly, coming from storage writes and storage reads, and both of those don't look like they would be… become cheaper when comes to them. So from a worst-case size, I think, things will…
Toni Wahrstätter:only improve with the repricing EAPs being shipped. Regarding the other 4 EAPs that we already have on Defnet 2, it seems like there is no real issue with those and block of access list.
Toni Wahrstätter:also looking at the other CFID OPs, I don't think there will be any surprises, at least,
Toni Wahrstätter:what I saw.
jochem-brouwer:Okay, cool.
Toni Wahrstätter:Or have you… have you seen anything different?
jochem-brouwer:No, no, no, I just want to check, yeah, I think we're safe, but I just wanted to raise the point. And my second question is about the def P2P, so EV71. So we are constrained there by also the 10 megabytes DevP2P limit.
jochem-brouwer:And EVE70, introduced the partial receipts, so this actually allows the receipts, the… yeah.
jochem-brouwer:all the bundles received should be more than 10 mega… 10 megabytes. I would also propose to also do this with the book access lists.
jochem-brouwer:To allow this to have more than 10 megabytes, or, maybe this is not possible because of the already existing limits.
jochem-brouwer:We just wanted to raise that in DevPTP, we have the 10 megabyte limit, and we should, figure out when this limit can be hit.
jochem-brouwer:Or constrain this in the block, that it is not allowed to create a def… a block exist larger than some size.
Toni Wahrstätter:Yeah, I agree. To me, it feels like the simplest approach would be to do the same for block cloud access lists that we do
Toni Wahrstätter:for… for all the other objects in ETH70.
Toni Wahrstätter:And then it should work.
Toni Wahrstätter:So then we are basically, independent from the gas limit, the bulk level access list size can just grow linearly in theory, and we would still be fine.
jochem-brouwer:Yeah, that sounds good. Okay, that was… that's my points, yeah.
Toni Wahrstätter:Awesome, thanks.
Toni Wahrstätter:Anything else we should discuss in today's call before we wrap up?
Toni Wahrstätter:Right.
Toni Wahrstätter:Yeah, that's all we had on the agenda today.
Toni Wahrstätter:Next breakout call will take place in 2 weeks again.
Toni Wahrstätter:Thanks a lot to everyone, and see you in two weeks.
jochem-brouwer:Alright, thank you. Bye-bye.
Jared Wasinger:I owe.
Chat Logs
00:08:40
Karim T. (matkt):Nice is it from from benchmark you did ?
00:10:06
Ameziane Hamlat:Replying to "asked claude for a c..."
Bonsai L1 cache 😂, I like the analogy with CPU L1 cache
00:10:24
Karim T. (matkt):Replying to "asked claude for a c..."
I should maybe rename it like that
00:12:08
Stefan Starflinger:This is just from the prometheus metrics and logs
00:12:14
Stefan Starflinger:@geth what are the flags?
00:12:36
Ameziane Hamlat:@Stefan Starflinger There may be an issue with the numbers, I don’t see how prefetch would help that much in reducing the reads
00:13:36
Dragan Rakita:We figured out the problem that we had with EIP-7778 on devnet-2
00:14:01
Jared Wasinger:Replying to "We figured out the p..."
—bal.executionmode={sequential|full|nobatchio}
00:14:39
Ameziane Hamlat:Replying to "This is just from th..."
I see, so that’s based only on the metrics on the flat database reads. As those reads are batched in advanced, besu doesn’t need to do it during execution.
00:15:15
Ameziane Hamlat:Replying to "asked claude for a c..."
I think I understand now the results
00:15:35
Stefan Starflinger:Replying to "asked claude for a c..."
I didn't question the numbers yet :D
00:16:06
Karim T. (matkt):We said we should keep a minimum of BAL without pruning
00:16:29
Karim T. (matkt):Something like 113056 blocks
00:18:42
felipe:I wanted to note EELS has a branch of geth with support for opcode counts and has latest Amsterdam updates to t8n. I was able to fill some Amsterdam benchmark tests via these dev branches yesterday. We should be able to start building BAL-specific benchmark tests there soon.
00:19:21
Karim T. (matkt):For me BAL should also be available using P2P
00:20:19
spencer-tb:Replying to "I wanted to note EEL..."
Does anyone know how we want to benchmark BAL specifically, parallel/serial/both <- for benchmark tests in EELS
00:20:58
jochem-brouwer:Where is the eth/71 spec? Is it draft EIP?
00:21:24
Stefan Starflinger:So what is the status on EEST benchmarking and benchmarkoor?
00:21:30
felipe:Replying to "I wanted to note E..."
cc: @jochem-brouwer^^ I know you had some thoughts on BAL-specific benchmarks
00:22:29
felipe:Replying to "So what is the sta..."
It's EELS all the way down now 🙂
00:22:59
Stefan Starflinger:Replying to "So what is the statu..."
Giphy [ID:NEvPzZ8bd1V4Y]
[Full message cannot be displayed on this version]
00:30:29
Ameziane Hamlat:In case of benchmarking BAL features, clients need to be benchmarked in separate VMs to have access to available cores and not fight on cores with other clients.
00:32:26
Barnabas:I’d recommend holding back shadowforks till we have all EL clients confirmed working with BAL optimizations. As these are pretty expensive tests to run.
00:34:20
Toni Wahrstätter:https://github.com/ethereum/devp2p/pull/264/
00:35:46
jochem-brouwer:Antwoord verzenden naar "https://github.com..."
FYI, here is eth/70 EIP: https://eips.ethereum.org/EIPS/eip-7975
00:40:11
Karim T. (matkt):What do you mean by “This check SHOULD be performed periodically (e.g., every 8 transactions) to enable early rejection without impacting parallel execution.” ?
Do you think this check will impact // execution ? Seems to be a light check
00:41:29
jochem-brouwer:Antwoord verzenden naar "I’d recommend hol..."
Yes agreed, first focus on parallel execution and then later on state or sync which would require big state / shadowfork to bench correctly
00:44:13
jochem-brouwer:This would be part of benchmark effort also I'd say (invalid BALs)
00:45:27
Marc:implemented in nethermind
00:45:35
Barnabas:can we get it merged?
00:45:38
Barnabas:and add it to hive ?
00:46:41
Karim T. (matkt):Is it eth_getBlockAccessListByBlockHash or eth_getBlockAccessListByHash
00:47:44
Karim T. (matkt):yes
00:49:08
Ameziane Hamlat:It is different from existing RPC we already have ex.
debug_traceBlockByHash and
debug_traceBlockByNumber
00:50:18
Karim T. (matkt):We already have eth_getTransactionByBlockHashAndIndex
00:51:21
jochem-brouwer:I think it is ambiguous because eth_getBlockAccessListByHash could mean BAL hash or BlockHash, while eth_getBlockAccessListByBlockHash is clear what the hash points to
00:51:25
Barnabas:I think this is a call to be made in the rpc standard call
00:51:27
Barnabas:lol
00:51:29
Karim T. (matkt):Not sure eth_getBlockAccessListByHash you don’t know if it is the hash of BAL
00:52:01
Barnabas:How about eth_getBlockAccessListByBalHash ?
00:52:16
Toni Wahrstätter:https://github.com/ethereum/execution-apis/pull/726
00:52:43
jochem-brouwer:This is also good for RPC consumers to let them chime in on here what would be a good practice :)
00:53:21
jochem-brouwer:eth_simulate?
00:53:22
Barnabas:eth_simulateV1
00:53:36
Stefan Starflinger:Lets get all the hive tests passing otherwise all good from my end
00:53:40
jochem-brouwer:Antwoord verzenden naar "eth_simulateV1"
Does it interact with BAL?
00:53:41
Karim T. (matkt):Do you have a link to the spec of this RPC ?
00:53:46
Barnabas:Replying to " eth_simulateV1 "
shouldn’t
00:53:53
Barnabas:Replying to " eth_simulateV1 "
it will help us with benchmarking tho
00:54:05
Karim T. (matkt):eth_simulateV2 ?
00:54:07
jochem-brouwer:Antwoord verzenden naar "eth_simulateV1"
Ah right yes it could def. strain exec time
00:54:49
Barnabas:Replying to "eth_simulateV2 ?"
https://github.com/ethereum/execution-apis/blob/main/docs-api/api/methods/eth_simulateV1.mdx
00:54:57
Barnabas:Replying to "eth_simulateV2 ?"
there is a v2?
00:54:58
Karim T. (matkt):Replying to "eth_simulateV2 ?"
thanks
00:55:10
Karim T. (matkt):Replying to "eth_simulateV2 ?"
No I was asking if you want a v2
00:55:41
Barnabas:Replying to "eth_simulateV2 ?"
I want every client to implement v1
00:55:51
Barnabas:Replying to "eth_simulateV2 ?"
as we still have a bunch of clients not having v1
00:57:13
Karim T. (matkt):Replying to "eth_simulateV2 ?"
We have but are you asking to add BAL compatibility ?
00:57:45
Barnabas:Suggestion for devnet 3 scope:
BAL OPTIMIZATIONS (parallel exec, parallel state loading, parallel state root calc)
8037 State Creation Gas Cost Increase
7954 Increase Maximum Contract Size
01:03:41
Fireflies.ai Notetaker Gustavo:Gustavo invited Fireflies.ai here to record & take notes. View Security & Privacy info: https://fireflies.ai/policy
Type:
'/ff leave' - Remove Fireflies
View Realtime notes here: https://app.fireflies.ai/live/01KH1JNFZ76EHSA6NDV1FP1H0H?ref=live_chat
Summary
16 highlights
· 3 action itemsExperimental
Summary
16 highlights · 3 action itemsExperimentalclient optimization status
- Besu: All 3 optimizations live on bal-devnet-2 (parallel exec, state root, prefetch)00:05:33
- Reth: Parallel exec and state root in progress; batch I/O delayed00:07:02
- Nethermind: Parallel exec in progress; state root partially implemented; batch I/O not started00:07:55
- Geth: 3 performance presets implemented via flags; block building issue being resolved00:10:06
devnet and testing
- bal-devnet-2 stable; Besu and Geth ready for benchmarking00:13:02
- Benchmarking framework needs BAL-specific tests targeting parallel exec, state root, prefetch00:14:00
- ETH/71 (DevP2P BAL retrieval) required for reorg scenarios; must test with sync00:14:34
- EELS can now fill Amsterdam benchmark tests; BAL-specific benchmarks in progress00:22:59
early block rejection
json rpc updates
Decisions
Action Items
Targets
- Devnet-3: BAL as JSON objects, corrected RPC naming, eth_simulateV1 support00:46:54