Toni Wahrstätter:Hello, everyone, and welcome to today's EIP-7928 breakout call. It's the 11th breakout call, and it's 20… January 28 today.
Transcript
Toni Wahrstätter:So, looking at the agenda, let's start at the beginning, let me quickly post the agenda into the chat.
Toni Wahrstätter:Such that everyone can have a look.
Toni Wahrstätter:So the first two items were basically already discussed, at ACDT,
Toni Wahrstätter:beginning of this week, but I think it would make sense to get an update from Stefan.
Toni Wahrstätter:where we are at, there were some delays, as far as I know.
Toni Wahrstätter:It would be great to have an update there.
Stefan Starflinger:Yeah, sure. So, from the last ACDT, we decided to include a change that would remove the gas spent, I think, from the receipts.
Stefan Starflinger:And,
Stefan Starflinger:agreed that we would add it and delay the DevNet 2 until next week at the latest.
Stefan Starflinger:Hopefully, we can get it running a little bit earlier.
Stefan Starflinger:Yeah, it got changed.
Stefan Starflinger:Exactly, but otherwise, also, maybe to summarize, maybe not everyone was in ACDT.
Stefan Starflinger:from DevNet 1, I think it went pretty well. We got most clients to be in agreement. We didn't have too many forks anymore, even with the EVM fuzzer running, so that's…
Stefan Starflinger:very great, and we also got most of the clients syncing. There were still a few hiccups, but in general, it was working pretty well. And now, I hope that with DevNet 2, we can look into the optimizations more.
Stefan Starflinger:But, let's talk more about the spec clarification, because I think it would be great that we could tie everything of that up, and get everything in definite, too, of the open issues that we're gonna discuss next, and I think I've added everything to the spec sheet.
Stefan Starflinger:From what we're gonna discuss next.
Toni Wahrstätter:Perfect, thanks for the update.
Toni Wahrstätter:So, just to… just to confirm, it looks like 7928 is not blocking anything regarding DevNet 2, and we are ready to go, basically, but, it's more about other smaller EIPs, like 7778, right?
Stefan Starflinger:Yep, that's pretty much it.
Toni Wahrstätter:Okay, here.
Toni Wahrstätter:to echo what Jared is saying in the chat.
Toni Wahrstätter:Regarding 7778, there was, recently a change that reverted it back to keeping the receipt as it is, so it should be…
Toni Wahrstätter:done pretty soon, or pretty easy, I would say.
Toni Wahrstätter:But let's see.
Toni Wahrstätter:Great, so what is then… what was the latest, then? When will DevNet 2 launch? Do we have a date for that yet?
Stefan Starflinger:So, I'm aiming for next week, Wednesday, as the latest date, that I want to launch DevNet 2.
Stefan Starflinger:And we'll see. I will be testing the clients regularly to see how we get on, but that would really, it would be great if we could launch earlier.
Stefan Starflinger:I don't know how the development is going on, it would be great to get some client updates. I think the last update, from everyone that I got was last Wednesday.
Toni Wahrstätter:Awesome.
Toni Wahrstätter:Yeah, and this plays into the next topic, the client optimizations. We already saw in the Discord that Geth and Besu are both ready
Toni Wahrstätter:Having the flags ready… to…
Toni Wahrstätter:enable and disable the optimizations, for example, parallel execution, parallel…
Toni Wahrstätter:batch I.O. and parallel state route computation.
Toni Wahrstätter:Is there someone from the other clients that could provide an update on how far they are with regards to optimizations, and if they're
Toni Wahrstätter:Will be flags to turn them on and off.
Marc:Yeah, I can give an update for Nethermind. So working still on, parallel transaction execution, and state recommutation. I haven't started with the batch read yet.
Marc:But yeah, just been focused on, preparing for the DevNet for now.
Marc:Yeah.
Toni Wahrstätter:Awesome, thank you.
Toni Wahrstätter:Maybe someone from Reth, or from… Erigon?
Toni Wahrstätter:Otherwise, it's also not a problem.
Toni Wahrstätter:If we don't get updates, that soon, because, importantly.
Toni Wahrstätter:We need at least a few clients to do the benchmarks on top of a BAL.
Toni Wahrstätter:DevNet.
Toni Wahrstätter:So, having Geth and Besu is already a good start, and I think we should then…
Toni Wahrstätter:Get the benchmarking going as soon as possible, and for that.
Toni Wahrstätter:Yeah, I mean, I will leave that to Jochem anyway, because he's the expert there, so I'm not sure how to best tackle that, but I would assume we will just have a mainnet shadow fork and do the benchmarking there.
Toni Wahrstätter:Maybe Jochem, if you're on the call.
Toni Wahrstätter:You wanna say a few words to that?
jochem-brouwer:Yeah, it depends, I think, on what exactly we want to test. I think we want to benchmark the,
jochem-brouwer:the, the, the impact, what a block access list could have.
jochem-brouwer:I also think this is… Also, like, about,
jochem-brouwer:Because you could implement block access lists to just be consensus compliant.
jochem-brouwer:And you could also implement the block accesses with the optimizations in there, so, like, parallel execution.
jochem-brouwer:I think this is, at least something what we should do.
jochem-brouwer:And what we would then do to benchmark this is we have to benchmark test.
jochem-brouwer:But we will then benchmark the, the same client, which does not have these optimizations enabled.
jochem-brouwer:Against the client which… sorry, the same client, against a client which has these optimizations enabled, to see what the impact of these, of the block access list is.
Toni Wahrstätter:Perfect, yeah, sounds good.
jochem-brouwer:And, oh yeah, so, and to mention, like, this should be done on, like, indeed a shadow fork of mainnet, because if we do this on empty state… oh, Karim is already asking this. So, what network is being used for this? We need a network with state, and that… the simplest way is to just do a shadow fork of mainnet, because if you would,
jochem-brouwer:run these things on, like, empty state, or, like, consensus test-sized states, so, like, a very small pre-state, then you will see almost no influence at all, because the state reads are in there super fast, so you would not have any performance increase there.
jochem-brouwer:So we need, like, a big network, and we can also see what we could also do is also release on top of BloatNet, so this is, like, a shadow fog off-mainnet.
jochem-brouwer:But increased in size, to see also what the impact is if mainnet size, well, it will, of course, increase over the years.
jochem-brouwer:But the impact is then, on even bigger size, sites.
jochem-brouwer:And when do we expect to have the shadow fork ready? Well, I'm not sure if someone from… if PandaOps is here, Stefan is here, but I think this, the shadow fork can be done, instantly.
jochem-brouwer:So we can just run it on top of a shadow fork.
jochem-brouwer:Well, in an.
Stefan Starflinger:Yeah, I think as soon as we have DevNet 2 running, we can focus on the optimizations, and when the optimizations are in, and they're working as expected, I think we can start the shadow work.
jochem-brouwer:And maybe then a question, this DevNet 2, do we… is this planned to be a shadow focus of mainnet, or, like, an empty network?
Stefan Starflinger:DevNet 2 would be an empty network, but we would increase the gas limit to, I think, 150 million, so that we can also have a reasonable state after some time there, too.
jochem-brouwer:Okay, that's it, that's fine. Yeah, like, the benchmarks are, of course, also somewhat different than just testing the networking aspects.
Toni Wahrstätter:So we can also run these locally on, like, a shadow form to test the impact of state. Yeah, I'm not 100% sure about this, because even if we…
Toni Wahrstätter:put the gas limit to a billion, we will not be able to generate, like, reasonable state within a short period of time. So I think we should focus those tests purely on
Toni Wahrstätter:on Shadow Fork, or on BloatNet, especially BloatNet might be very interesting, because
Toni Wahrstätter:It gives us already a glimpse into the future, basically.
Toni Wahrstätter:So, and then we basically focused, DevNet 2 more on everything consensus-related and testing, all the new changes that come with DevNet 2, for example, the
Toni Wahrstätter:BAL payload, or the bulb EL block separation, the new engine API methods, and so on.
Toni Wahrstätter:If that makes sense.
Stefan Starflinger:Yeah, I agree with that also.
jochem-brouwer:Yeah, yeah, I think that what you then do is, like, DevNet tools, because it also makes sense to not immediately stress test the DevNet, and then do the stress testing on, like, a very specific benchmark network, so, like, a shadow fork, or BloatNet, or mainnet, or whatever, and then use that for the benchmarks. Yeah, I think that makes a lot of sense.
Toni Wahrstätter:Yeah, and just to be on the safe side, maybe we should first, clarify on ACDE or ACDT with clients, if they are actually ready for
Toni Wahrstätter:higher guest limits
Toni Wahrstätter:Because I don't know if we can just bump it up to 150, and then suddenly we'll run into weird RLP size limits, or whatever. So, just to double check. I assume clients will be fine with that, so every client might be fine with just bumping it up, but just to double check there.
Toni Wahrstätter:We don't need to trigger, like, running into the 10MB, uncompressed size limit or anything.
Toni Wahrstätter:Perfect. Anything else regarding…
Toni Wahrstätter:this discussion point. Just to summarize, I think we will now also start a shadow fork, and probably a fork of BloatNet, and then also
Toni Wahrstätter:basically unblock the benchmarking efforts by having two clients already ready, Besu and Geth, that can be used to test parallel execution and batch I.O.
Toni Wahrstätter:At the same time already.
Toni Wahrstätter:Anything to add?
jochem-brouwer:Yeah, maybe two.
jochem-brouwer:Clarify a bit, or maybe to ask that we are all in, like, the same,
jochem-brouwer:line of thought. So the parallel execution is using the block access list to, well, run multiple transactions in multiple threads. And the batch I.O. is actually used to read from the bal to a parallel fetch from the disk, right?
Toni Wahrstätter:Yeah, exactly.
jochem-brouwer:Okay, so those are, those are, like, two different optimizations, and I think it is nice also for the benchmarking.
jochem-brouwer:For the benchmarks to be able to test these, individually.
jochem-brouwer:So now, not individually, but maybe, like, with only parallel execution, and with parallel execution, and the batch I.O, to see what the impact is, so we can also measure the impact of these
jochem-brouwer:of adding the REITs.
jochem-brouwer:To the BAL, what the impact of this is.
Toni Wahrstätter:Exactly, and this will be the very interesting comparison.
Toni Wahrstätter:that we are… yeah, we've postponed this until we have DevNets, and now we're… it's time, I would say. Basically.
Toni Wahrstätter:finally determining, do we need the state locations in the block level access list or not? Are they actually worth it? And the best way to do so would be exactly what you said, comparing it with the batch I.O. enabled, and
Toni Wahrstätter:Then, with Batch.io disabled, and then seeing what are the numbers.
Toni Wahrstätter:And if we do that on a…
Toni Wahrstätter:Realistic state size definite, plus on a higher gas limit, we should get numbers.
Toni Wahrstätter:That's… yeah.
Toni Wahrstätter:We should get confidence for Glamsterdam.
Toni Wahrstätter:Great, anything else?
jochem-brouwer:Yeah, just asking what, for Corinne, the clarification, like, the background… Are those stations?
Toni Wahrstätter:Yeah, I think we can ignore it. I think we can ignore it at this point, because this is like an optimization that is solely dependent on the post-transaction state divs being in the block.
Toni Wahrstätter:So, this doesn't actually tell us anything about
Toni Wahrstätter:Should we keep the state locations or not, so…
Toni Wahrstätter:We can use them, we can also turn them off, depending on what the client supports.
jochem-brouwer:Yeah, I think this is, like, an optimization which, it's not really influenced
jochem-brouwer:Like, if you just think about, like, the reads, if it would remove that or not, like, this will not influence
jochem-brouwer:the, oh, right, the state would also have to get the visa. Yeah, okay.
jochem-brouwer:Interesting.
jochem-brouwer:Yeah, something to keep in mind, mate.
Toni Wahrstätter:Yep, exactly.
Toni Wahrstätter:Great. The second agenda item that we have on today's agenda would be spec and
Toni Wahrstätter:Spec updates and clarifications, so there were… three updates?
Toni Wahrstätter:Nothing new. So the first one was the engine API methods.
Toni Wahrstätter:And there was some discussions in the PR regarding, do we need the engine API methods and for what they're used for?
Toni Wahrstätter:Also, Mikhail had some comments there.
Toni Wahrstätter:Mikhail, are you on the call? Do you wanna briefly…
Toni Wahrstätter:tell us why the engine API methods are needed, and Your… your thoughts around it?
Mikhail Kalinin:Yeah, okay, so, hey, everyone.
Mikhail Kalinin:I'll try to summarize.
Mikhail Kalinin:So, if, I believe that BAL is, will be part of
Mikhail Kalinin:of the, CL block, of the beacon block.
Mikhail Kalinin:Right? Is that correct?
Toni Wahrstätter:Right, yeah, that's correct. It's in the execution period.
Mikhail Kalinin:Yeah, it's a part of an execution payload. It's quite similar to transactions, so there is no possibility for the execution layer client to process a block without a BAL, right?
Mikhail Kalinin:And, yeah, and if, we make it as a requirement, for…
Mikhail Kalinin:to pass, BAL to, to, to EL, Alongside to… to the payload.
Mikhail Kalinin:Then we… We have this dependency.
Mikhail Kalinin:kind of like, that the CL block has to… has to…
Mikhail Kalinin:keep BAL on its side, in, in its storage.
Mikhail Kalinin:Like, it would have to keep transactions, but, we have these deduplication methods, like.
Mikhail Kalinin:For, that allows CL to basically request,
Mikhail Kalinin:Work payload bodies, which are…
Mikhail Kalinin:Consisting of, transactions and withdrawals today, from EL's side.
Mikhail Kalinin:So if we make a requirement that the value is required to pass to a new payload call.
Mikhail Kalinin:And, EL will… will get it from CL.
Mikhail Kalinin:Via… in the regular case.
Mikhail Kalinin:Then we have to… Then we likely have to also introduce,
Mikhail Kalinin:this piece of data into these, payload bodies, methods. So, some CLs really use these,
Mikhail Kalinin:Rely on those methods to deduplicate,
Mikhail Kalinin:Data, and, reduce the… disk storage, impact.
Mikhail Kalinin:So, yeah. In this case, yeah, if it's required, then we have to kind of provide this additional
Mikhail Kalinin:be, additional data that can be pulled off from EL.
Mikhail Kalinin:So if it's… the other option, basically, yeah, make PAL as a non… as an optional field of a new payload call.
Mikhail Kalinin:And in this case, EL will have to either execute transactions without it, or look into…
Mikhail Kalinin:its own network, via DevP2P.
Mikhail Kalinin:Extract BAL, get BAL from there, and basic execute the block.
Mikhail Kalinin:So… And, yeah. Optional means that sometimes CL will just have it.
Mikhail Kalinin:When the block is just… is gossiped, it will come with a BAL included, and then
Mikhail Kalinin:CL can pass it to EL. So there's kind of, like, two options here.
Mikhail Kalinin:That I see. I don't know if it's clear or not, so… yeah.
Mikhail Kalinin:Let's probably discuss it.
Toni Wahrstätter:Yeah, thanks a lot. To me, it makes a lot of sense.
Toni Wahrstätter:what I don't get is why the optional BAL field is, like, even on the table. To me, it feels like treating the block-level access list the same as we treat the transactions, and
Toni Wahrstätter:thereby forcing CL clients to either keep the buzz around, or blind them.
Toni Wahrstätter:Which is, kind of what CL clients do in order to deduplicate, transactions. So basically, instead of storing the whole BAL, CL clients would only need to store the bul root.
Toni Wahrstätter:and have those two engine API methods available in order to retrieve the full BAL if needed. To me, this feels, like, very clean.
Toni Wahrstätter:with the optional BAL field in the execution playlist, I'm not… I'm not so sure, because essentially, the block of access list will be
Toni Wahrstätter:necessarily needed on the EL side, because you cannot validate the full block without having the block web access list.
Toni Wahrstätter:So… Yeah, I'm having difficulties wrapping my hand around optional.
Toni Wahrstätter:About the fact that it's optional.
Toni Wahrstätter:I know that this is more like a technical thing here, to make sure that CL clients can just get rid of it without blinding it, is that correct?
Mikhail Kalinin:Yeah.
Mikhail Kalinin:Yes, it is.
Mikhail Kalinin:So, like, for a normal case, BAL will be passed from CL, because it gets it from gossip.
Mikhail Kalinin:But in the case when, CL is, like, syncing, is in a sync mode,
Mikhail Kalinin:Then it will just pass the payload without BAL.
Mikhail Kalinin:And then the EL side will have to fetch it from the network.
Mikhail Kalinin:I don't know. Does it make sense or not? So…
Toni Wahrstätter:It does… it does make sense, so it's very much… we're… we're talking about syncing here, too.
Toni Wahrstätter:So essentially, the CL could provide other CL peers.
Toni Wahrstätter:With beacon blocks, even though those beacon blocks would not contain a full execution payload, because the BAL is missing.
Toni Wahrstätter:and the other CL that is syncing would then pass
Toni Wahrstätter:the beacon block execution payload to its EL without the bar, and the EL would then have to figure out where to get the BAL from, and the EL could then use DevP2P for that.
Mikhail Kalinin:And then…
Toni Wahrstätter:What?
Mikhail Kalinin:will happen… yeah, sorry.
Toni Wahrstätter:Go ahead, go ahead, please.
Mikhail Kalinin:Yeah, and then what will happen, in the case when,
Mikhail Kalinin:There is nothing, nothing to fetch, so there is, like, imagine there is no syncing case, EL has all the data to process a block, but CL does not give a, does not pass a BAL, because it's, it's optional. It's an optional field.
Mikhail Kalinin:then, EL…
Mikhail Kalinin:Will not be able to synchronously execute the synchronously process block and get back with a payload status.
Mikhail Kalinin:As it happens today, it will have to go to the network.
Mikhail Kalinin:And it sounds like a synchronous stuff, so it will have to return syncing.
Mikhail Kalinin:Instead of… The payload status.
Mikhail Kalinin:Something like that. It makes the thing a bit more complicated than…
Toni Wahrstätter:Right, yeah, and we could have done the same with transactions, right?
Toni Wahrstätter:So there's… there's nothing…
Toni Wahrstätter:speaking against doing the same for transactions. So we would suddenly actually introduce this new path that might be better.
Toni Wahrstätter:But even though it's… it's, like, different from how… from existing code paths.
Mikhail Kalinin:Right, but what… I see transactions are really necessary.
Mikhail Kalinin:Actually, it's not… there is no possibility to process a block without transactions, but you could process a block without
Mikhail Kalinin:Is your book-level access to this.
Mikhail Kalinin:Couldn't you?
Toni Wahrstätter:You can process it, their transactions at least, but you would not be able to tell if the block is valid or not, because in the end, you would still need to…
Toni Wahrstätter:comparator. So, you would at least need the BAL hash, right?
Toni Wahrstätter:Yeah, so the CL could also provide the BAL hash.
Toni Wahrstätter:then the engine API call to the EL would also need to provide the BAL hash, and then it would work.
Mikhail Kalinin:Right.
Toni Wahrstätter:Maybe a question to the EL clients. Is there already… has some EL team already implemented BALs into DevP2P for SnapSync, for example?
Jared Wasinger:I'll just say on the Geth side, we've slated this to actually use these for the SnapSync.
Jared Wasinger:That has been pushed back to something we plan to do in Q2.
Jared Wasinger:I mean, we can, of course…
Jared Wasinger:Yeah, I'll just leave it at that.
Toni Wahrstätter:Okay.
Toni Wahrstätter:Yeah, maybe we will just have to revisit that topic,
Toni Wahrstätter:Sometime later on. I would say, correct me if I'm wrong, Mikael, but I would say, right now, it seems like the simplest approach would just be to keep it as it is, and implement those two engine API methods that are
Toni Wahrstätter:defined in the… in this PR that I will now post into the chat.
Toni Wahrstätter:Let me quickly through that.
Toni Wahrstätter:So I think this was the right one, where we have defined those two new API methods.
Toni Wahrstätter:And those would essentially be needed by the CL in order to help other CL nodes to sync, because CL will be able to prune the block.
Toni Wahrstätter:But then, when it comes to helping other nodes sync, they need the BAL again. And because the EL will store the BAL, there needs to be this engine API method to retrieve it.
Mikhail Kalinin:Yep, that's… that's correct.
Mikhail Kalinin:And I think, yeah, it's easier to…
Mikhail Kalinin:To leave it as is, and change… and probably change it later on.
Mikhail Kalinin:So… I don't know, it's also a question to CL client developers.
Mikhail Kalinin:What do they think about it?
Toni Wahrstätter:Right, yeah, we don't have many serial developers here in this call, unfortunately.
Toni Wahrstätter:I think most of them are busy with EPBS anyway.
Toni Wahrstätter:But yeah, this will probably come up in the future again, and we should,
Toni Wahrstätter:We should think how, like, what is the cleanest solution for such things.
Toni Wahrstätter:And if we should just keep on doing the same that we do with transactions, or if there would be a smaller path.
Toni Wahrstätter:Awesome. Is there anything else on that topic, on the engine API method?
Toni Wahrstätter:Otherwise, we can go on to the next item, which is further clarifying what access means. We have had discussions on that, like, when do we count an account as being accessed versus not yet accessed?
Toni Wahrstätter:Having to do with the different phases.
Toni Wahrstätter:And this PR here, I will also post it into the agenda, just clarified that further.
Toni Wahrstätter:Unfortunately, I saw it get merged automatically before, I could respond to Jocham's comment here.
Toni Wahrstätter:I will… I will still do that and incorporate that, but I think right now we're in a good state because Felipe and Rahul have created tests for all those edge cases, and clients have been passing those tests, so I think we are quite aligned on that topic.
Toni Wahrstätter:But just to make sure, is there anything on the excess topic? I know that Jared and Gary brought it up in Discord recently, is there anything we should discuss?
Jared Wasinger:Yeah, I guess I'll just say… so, the proposal we brought up,
Jared Wasinger:Basically, it was about, changing the… Sort of changing the,
Jared Wasinger:The logic for whether or not we include a, like, when making a call and executing the gas handler, depending on how much gas there is, and it goes out of gas at some point in the handler.
Jared Wasinger:We will or will not include the, the target as an axis. And…
Jared Wasinger:the reason we made this proposal was that it greatly simplified the change there that need to be made on the side of Geth.
Jared Wasinger:But I think, yeah, Joakim brought up, A pretty good point, regarding,
Jared Wasinger:basically, we… I think the current spec is… is good, because we need to… we can't make it…
Jared Wasinger:we can't create a situation where somebody can make a call with one gas, and then the target gets included in the access list. It is sort of an attack vector.
Jared Wasinger:So, I… personally, I think that the current spec is… Is okay.
Toni Wahrstätter:Perfect, thank you.
Toni Wahrstätter:Awesome.
Toni Wahrstätter:I think we have, alignment on that point in this case. And then the last agenda item
Toni Wahrstätter:For the specs was to chase in RPC endpoints, I think clients are already…
Toni Wahrstätter:For DEFNET2, having the JSON RPC endpoints implemented.
Toni Wahrstätter:Is that the case for all clients, or is there a client that won't have the JSTAR PC already implemented?
Toni Wahrstätter:Until next week.
Toni Wahrstätter:Great.
Toni Wahrstätter:Then we have another agenda item by Stefan. Stefan, you wanted to talk a bit about standardized ALT traces?
Stefan Starflinger:Yeah, I just, thought about, generally, how could we approach, kind of.
Stefan Starflinger:In a standardized way, testing the performance gains of bowels.
Stefan Starflinger:And one of the most standard ways to capture these insights is with open telemetry traces.
Stefan Starflinger:And I think there are two clients that have that implemented, Geth and Reth, but I think Geth is in the process of adding that. I can share the document in the chat.
Stefan Starflinger:It's a little bit of a long shot.
Stefan Starflinger:But I wanted to maybe see if we can just use it as a way to brainstorm exactly
Stefan Starflinger:What kind of metrics block-level access will add that we want to capture, that we want to follow in a more structured fashion.
Stefan Starflinger:And it would be good that we can get, kind of, the BAL rolling and communicate, how best we can extract these metrics. I mean, this document is a suggestion to use OpenTelemetry.
Stefan Starflinger:But of course, that's not a hard requirement, if other clients might do it differently, but in general, it would be good if we
Stefan Starflinger:align on exactly when we capture the timings. For example, the prefetching is one of the important,
Stefan Starflinger:like, elements of the bowel, so how long does it take to prefetch everything? Have you implemented the prefetching the same way as other clients? Does it make sense that we capture it all in a standardized way?
Stefan Starflinger:And then, how well does the parallel execution work? Like, which… how many transactions are running in parallel? That would be really nice to see.
Stefan Starflinger:And to visualize. I would really like to get something like that running for all of the clients in Kurtosis,
Stefan Starflinger:So yeah, that's why I created the document, and I'm very happy to take any comments or feedback on it.
Toni Wahrstätter:Awesome, thank you.
Toni Wahrstätter:I see Jocham, you have your hand up.
jochem-brouwer:Yeah, I know that, Stefano, I've already talked to Carlos, but Carlos is also… I'm not sure if this works in parallel, but he has posted this research, post about, adding some more general
jochem-brouwer:metrics, and I think it will be helpful to coordinate this, like, maybe…
jochem-brouwer:Getting, like, these general metrics standardized, and then also, on top of that, the BAL metrics.
jochem-brouwer:Because then, otherwise, I will do two things,
jochem-brouwer:Not in parallel, but, yeah. I think you get the point.
jochem-brouwer:So, the question is, yeah, maybe work together with Carlos on these metrics.
Stefan Starflinger:Yeah, for sure. His metrics are a little bit different, than mine, because I, like, built on top of, kind of, what he was working on.
Stefan Starflinger:And just focused on, block-level access lists. So this is just generally to identify, I think, execution metrics, but this does not, consider BALs, yet.
Stefan Starflinger:And that's kind of, the spec that I wrote, to add on top of that.
jochem-brouwer:Okay, so it's, yeah, it's already written on top of, of this, thing.
Stefan Starflinger:Yeah, that's the idea. And in general, it's not a… just to reiterate, it's not a requirement for DevNet 2, but what I would like to have at some point is to be able to have some visualization of these metrics
Stefan Starflinger:in Grafana or something like that, to be able to export them.
Stefan Starflinger:And to have that in kurtosis would be the first step.
Stefan Starflinger:That'll be very nice.
Toni Wahrstätter:Awesome, thank you very much.
Toni Wahrstätter:Yeah, please.
Toni Wahrstätter:Have a look.
Toni Wahrstätter:Let's make sure that we get those metrics implemented such that we can then
Toni Wahrstätter:actually benchmark and test if optimizations make sense, and especially get some
Toni Wahrstätter:certainty that clients are doing the same and getting the same out of the optimizations. This is… this is great.
Toni Wahrstätter:Thanks a lot, Stefan.
Toni Wahrstätter:Perfect. Anything else on that topic?
Toni Wahrstätter:Otherwise, this would bring me to the last topic, namely…
Toni Wahrstätter:One thing that we should discuss is how we would deal with malicious block lab access lists, basically with
Toni Wahrstätter:Block web accesses that are wrong.
Toni Wahrstätter:But of course, for such block of access lists, we must make sure that we are able to invalidate the block
Toni Wahrstätter:That contains such a wrong block access list as early as possible in the process.
Toni Wahrstätter:And let me actually quickly share my screen.
Toni Wahrstätter:Let me actually try to do so.
Toni Wahrstätter:Can you see my screen already?
jochem-brouwer:I see a black screen and a mouse.
Toni Wahrstätter:Okay, that's correct. Okay, interesting.
Toni Wahrstätter:Interesting, though.
Toni Wahrstätter:Because it already showed me in the preview that it will be a black screen, but…
Toni Wahrstätter:Let me quickly try something here.
Toni Wahrstätter:Okay, seems like the sharing is not… Working, as expected.
Toni Wahrstätter:Then I will just post, or maybe can someone else share? Jochem does the sharing work for you?
Toni Wahrstätter:Could you share your screen?
jochem-brouwer:I can? Yes, I can.
Toni Wahrstätter:Okay, could you then open a link for me?
jochem-brouwer:Yes.
jochem-brouwer:Let me first share my…
Toni Wahrstätter:Perfect.
jochem-brouwer:This shows the local time.
jochem-brouwer:Right? Perfect.
jochem-brouwer:Okay, great. And what's your title?
Toni Wahrstätter:And I will not just post the short presentation I have here into the chat so everyone can even follow it live, but you should be able to open it.
jochem-brouwer:Yes. Just, tell me, what to do.
Toni Wahrstätter:Perfect, yeah, just click on the… on slideshow for the first slide.
Toni Wahrstätter:Or for the second one already.
Toni Wahrstätter:Okay, so just to quickly introduce you into the topic, we can go one slide back here often, please.
Toni Wahrstätter:just as a quick intro, so this will… this is how I think of block execution today. So today, you don't have a block of access list, so what happens is you first do some I.O. in the block, then there might be some execution in the mean…
Toni Wahrstätter:After that, there might be again an S load, and you have to go to disk again, and so on. And at the end, right after.
Toni Wahrstätter:our virtual execution deadline. There is also the state route calculation. This is basically the last thing we do before we say a block is valid or not.
Toni Wahrstätter:Now, going to the next slide.
Toni Wahrstätter:the picture changes a bit with block lists. First of all, we can ignore the gas limit here, this is just…
Toni Wahrstätter:a random number showing us, okay, we have now scaled from 60 to 30 million, so blocks are actually bigger already, and the best thing we get from block lab access lists is that we can now parallelize between batch I.O,
Toni Wahrstätter:Then there is still some I.O, for example, I.O. that happens in the very first transactions, when the state is not yet cached through the batch I.O, you might still need to go to disk, and then there is execution and the state recalculation happening in parallel.
Toni Wahrstätter:And this is essentially a block, how it might look with block web access lists.
Toni Wahrstätter:Let's go to the next slide.
Toni Wahrstätter:This summarizes it again. So, essentially, the state locations in the BAL are very useful for batch.io.
Toni Wahrstätter:Most of the state that we need during execution will already be pre-cached.
Toni Wahrstätter:And the bulk gas limit can quite significantly be increased. So this is, like, the happy case.
Toni Wahrstätter:Let's go to the next slide, then.
Toni Wahrstätter:So now, think of a malicious proposer, or a malicious builder, and what this builder does is the following attack scenario. So you would build… so let's start at the very beginning. What… what do we try to exploit here?
Toni Wahrstätter:So a malicious BAL would exploit the fact
Toni Wahrstätter:That in our block level access list, we don't map state locations, so the reads, how we tend to say, we don't map them to transaction indices.
Toni Wahrstätter:So, from the perspective of a single transaction, you cannot really know
Toni Wahrstätter:are the state locations in the BAL correct or not? Because they are not mapped to any transaction index. So, what a malicious bul would now do is, you would try to declare as many garbage storage slots as possible.
Toni Wahrstätter:So essentially, a malicious proposer could fill the BAL with garbage storage slots.
Toni Wahrstätter:So far, so good. So if you fill it with completely garbage, and you fill it full with garbage slots, then this might be quite easy to detect for any client, because we can enforce
Toni Wahrstätter:a maximum number of storage slots in the BAL, and this is quite easily derivable from the block gas limit, so we should probably do that anyway. Like, have a cap of how many storage slots can there be in the block level access list, just by derived from gas limit divided by the cost of accessing a storage slot.
Toni Wahrstätter:But now, what we could do is.
Toni Wahrstätter:what I have on this first iteration point here, creating a malicious bottle that doesn't use, like, naively the full gas limit for
Toni Wahrstätter:That transaction, but… the full gas limit minus one max size transaction.
Toni Wahrstätter:So, essentially, Assuming, like, 150, 200 million gas, you would use all of it except 16 million, 16.78 million.
Toni Wahrstätter:4…
Toni Wahrstätter:declaring storage slots in the BAL. So this is, like, the number of storage slots you would put into the BAL. And then, in the same block, the transactions would actually only do heavy computation.
Toni Wahrstätter:So this is like the attack. You would have a BAL with garbage storage slots, many of them, and you would have a block with transactions that do heavy computation.
Toni Wahrstätter:And now the question is, when is the first time that clients could figure out that this block is actually invalid?
Toni Wahrstätter:Right, and this is something we have to think about, because, of course, now, assuming we parallelize all transactions on a separate core, right? Assuming you have an infinite number of core, or you have 8 cores and there are 8 transactions, doesn't matter.
Toni Wahrstätter:From the perspective of each core.
Toni Wahrstätter:you can validate that the state diff is correct, right? You have a definite
Toni Wahrstätter:validation there. But with regards to storage keys, because they are not mapped to transaction indices.
Toni Wahrstätter:You cannot really tell if this malicious bar that only contains garbage is actually valid or not.
Toni Wahrstätter:on each core. So what you would need to do is you would have to actually execute all transactions.
Toni Wahrstätter:And as said, they only do heavy computation, and only after executing all transactions, you would basically be able to sync your course
Toni Wahrstätter:And compare which storage slots each core saw.
Toni Wahrstätter:And only then you could tell, okay, this button must be invalid, because the transactions never accessed what is in the block web access list.
Toni Wahrstätter:And in this malicious scenario, what you would get is basically a proposer would sacrifice his block, because you would end up with an invalid block.
Toni Wahrstätter:But you would cause the prefetch process to be completely useless, right? The batch I.O. process would basically fetch completely useless storage keys from the disk and put them into the cache.
Toni Wahrstätter:And at the same time, we would engage in quite expensive computation, because we would still execute those transactions, and while executing each transaction in parallel.
Toni Wahrstätter:We would think, okay, those storage slots are not accessed in this transaction, so they must be accessed in another transaction on a different core.
Toni Wahrstätter:And then the question is, okay, how…
Toni Wahrstätter:Fast can clients fail such a block?
Toni Wahrstätter:Let's go to the next slide.
Toni Wahrstätter:Or even to the next one.
Toni Wahrstätter:Actually, go to the next one.
Toni Wahrstätter:Sorry, go 3 slides back, I thought I had another slide there.
Toni Wahrstätter:Two slides, sorry.
Toni Wahrstätter:Right, so this is how the malicious block would look like. It would come with a lot of batch I.O, and it would still require… actually, it would not come with any I.O, this is actually wrong, it should only have execution, but there would be a long tail of batch I.O,
Toni Wahrstätter:for garbage slots, and a lot of execution happening. And if we go to the next slide, this would essentially mean that the state locations in the BAL give us nothing anymore, because the worst case
Toni Wahrstätter:having the state locations would be the same as the worst case not having the state locations. And this worst case would be an invalid block.
Toni Wahrstätter:And this would essentially mean we cannot scale as much as we want, which is, of course, Sad.
Toni Wahrstätter:Let's go to the next slide.
Toni Wahrstätter:And there's 3 possible ways forward. So the first one, the simplest one, is we do nothing about this problem. It means we can… we can get quite far, I think, with having, like, caps on the bar itself. For example, in the block lab access list, we can already tell
Toni Wahrstätter:That if we see a certain number of storage slots, that each storage slot must come at least with
Toni Wahrstätter:2,000 GAS, right? Because that's the least you need to access all of those storage slots. And if there is a bul that already contains too many storage slots for what is realistic within the block size, within the block gas limit, then we can already fail those balls earlier.
Toni Wahrstätter:And then, also, a sub-point under the do-nothing is we can keep track during execution. Let's say you have, 4 cores, and there are 8 transactions, then if you keep track during execution of which
Toni Wahrstätter:storage piece, do I already… have I already accessed? And how much gas was already spent?
Toni Wahrstätter:then you can fail the block early on, because you would realize, okay, the transactions I just executed, they didn't touch any of the storage keys, so all the storage keys in the BAL must still be touched, but there's not enough gas available at this point in time, so I can
Toni Wahrstätter:Failed the block early on, without executing all transactions in that block.
Toni Wahrstätter:So this is one option, and probably the simplest. I'm just not sure
Toni Wahrstätter:If the worst case would actually be
Toni Wahrstätter:The same as the worst case without even having the storage locations at all.
Toni Wahrstätter:The second least complex option would be we remove the state locations, so this is basically something that is anyway, to be decided, if we keep the state locations in the BAL, and this depends on the benchmarks we get.
Toni Wahrstätter:But one of the benchmarks we should definitely do is test such a malicious block, essentially having a malicious proposer that submits a malicious block-level access list that causes clients to
Toni Wahrstätter:Waste a lot of time, and then figuring out that the block is invalid very late into the process.
Toni Wahrstätter:And the last option, which would probably be the most elegant solution to this specific problem, would be
Toni Wahrstätter:for all state locations in the BAL that are currently, of course, not mapped to any transaction index.
Toni Wahrstätter:We actually map them to the transaction index when they are first accessed within the block.
Toni Wahrstätter:This would mean we don't have any duplication, because if a storage slot is kind of, like, changed, it would still not appear twice as a read again, so this would not change compared to today. But what would change is that each account would come with a first access index, and each
Toni Wahrstätter:storage read would come with a first access index. And I already did some
Toni Wahrstätter:Experiments, and it looks like with today's gas limit, this would increase the average bottle size.
Toni Wahrstätter:By approximately 4%.
Toni Wahrstätter:So we are only talking about a 1, 2, 3 byte number here, so it's quite insignificant from a size perspective, but of course, add some logic again to it. Also, it touches the worst case file size, which would increase from 0.2MB to 0.97MB.
Toni Wahrstätter:This is, like, negligible, we can totally ignore that, because
Toni Wahrstätter:as long as the worst case BAL size still stays below the call data block, and we are still, like, half a megabyte smaller than the call data block, I think we are fine, because we're not creating, like, a new dust vector.
Toni Wahrstätter:Then, the next point, it allows clients to prefetch
Toni Wahrstätter:Storage slots in the correct order, which might be quite nice, because today, with the storage keys, or with the state locations not being ordered.
Toni Wahrstätter:There is another worst-case scenario where
Toni Wahrstätter:The keys you need first are actually the lexicographically last in the vowel, so you would read them last while you need them earlier in the block, so this would be prevented. And one nice
Toni Wahrstätter:thing is that we would still not have any duplication of addresses and storage keys, so the power would
Toni Wahrstätter:Basically, from a size perspective, it would stay quite compact.
Toni Wahrstätter:But yeah, it would change something, and suddenly we're not talking about removing the state locations anymore, but actually adding indices to it.
Toni Wahrstätter:So yeah, this is, of course, a lot.
Toni Wahrstätter:that I presented right now, I guess,
Toni Wahrstätter:We won't find an answer about this today, but I'm curious if clients have already thought about this, like, especially how do we want to invalidate a block?
Toni Wahrstätter:as early on in the process without risking that we do a lot of batch I.O, and we also do a lot of execution, and then only figure out
Toni Wahrstätter:That the block is invalid very late into the process.
Toni Wahrstätter:And… Yeah.
Toni Wahrstätter:getting nothing out of the batch I.O.
Toni Wahrstätter:Yeah, any thoughts on this?
Toni Wahrstätter:Yeah, jochem, go ahead.
jochem-brouwer:Yeah, like, maybe, maybe one comment, which I just realized, because now we are talking about, like, we have to realize the current way where we have to, where we invalidate invalid blocks. That means that we have to first sequentially execute the entire block, and then, well, the simplest example
jochem-brouwer:on how to construct, like, an invalid block, is to just construct a valid block.
jochem-brouwer:But just change the state root at the end. So you would only realize at the end that the state root is incorrect.
jochem-brouwer:And… What we are talking about here is, like, we already have the parallel execution.
jochem-brouwer:So, if we would compare this worst case, or, like, this situation, to the current situation where we don't have the block access lists, then it likely still is, like, a very big improvement. I just wanted to raise that point for the perspective of this.
Toni Wahrstätter:Yeah, this is very true. So it's… it's… it's not, like, setting us back that far, but it's more like…
Toni Wahrstätter:Comparing the block-level access list with state locations, with the block-level access list without state locations.
Toni Wahrstätter:This malicious block would essentially get us into the same spot.
Toni Wahrstätter:Or, yeah, basically the same spot, where we waste almost all of the batch I.O, And…
Toni Wahrstätter:still have to do, like, full execution. And of course, we can put numbers to it, right? Let's say we have 3 seconds for execution, and we can support the gas limit of 500 million, I don't know, doesn't matter that much.
Toni Wahrstätter:But if we kind of scale the gas limit to a point where leveraging
Toni Wahrstätter:the worst-case batch I.O. and leveraging the worst-case execution would exactly get us to that boundary.
Toni Wahrstätter:Right? Then, suddenly, we find out that there is a worst-case block where you get nothing from batch.io.
Toni Wahrstätter:So this would definitely mean we have to sacrifice some scaling there.
Toni Wahrstätter:Which would, of course, be bad, because at this point, we should then
Toni Wahrstätter:decide for removing the state locations from the BAL, directly?
Toni Wahrstätter:without, yeah, doing nothing. Yeah, Jared, go ahead.
Jared Wasinger:Yeah, I… so, I guess I'm having… I'm not quite understanding how adding first access, to the BAL prevents the case where we have to execute the entire…
Jared Wasinger:A set of transactions, because with parallel execution, there's not really…
Jared Wasinger:Any guarantee about what order transactions will be executed in, so to validate this first access, we still have to…
Jared Wasinger:I mean, because at any given point, if we access a storage slot, it might…
Jared Wasinger:not be the first access of that slot in the block, and so we still need to execute the entire set of transactions to validate the first access, and once we… I mean, if we have to execute the entire transaction set, then we've already read all of the state locations.
Toni Wahrstätter:Right, yeah, I mean, this is true, but then you… you have at least a guarantee, with the first access index, you have the guarantee that after executing your first batch of transactions, so you only need to execute one single transaction, then you could already invalidate the block. Because imagine you have
Toni Wahrstätter:you execute… you have a transaction, and you execute all of them in parallel. Then, from the perspective of each individual transaction, you don't know if the whole block is invalid, because any of the other transactions could have
Toni Wahrstätter:read what is in the BAL, right? So, from the perspective of your transaction that only does
Toni Wahrstätter:Execution, you could not tell.
Toni Wahrstätter:maybe the others do execute, some storage reads. But now, having at least one storage… having at least the storage keys mapped to a transaction index, you can fail after executing the first transaction, basically. Because you would then already, within the first transaction, realize
Toni Wahrstätter:That this transaction, for example, does only compute
Toni Wahrstätter:And as soon as you executed the first transaction, you could fail the whole block. And if you now think, okay, we have 8 transactions and 4 cores.
Toni Wahrstätter:then this would mean you don't execute all 8 transactions until realizing you…
Toni Wahrstätter:You can invalidate the block already, but you would only execute 4 transactions, because then after those 4 transactions, the bul would have already been invalidated.
Jared Wasinger:Mmm, okay.
Toni Wahrstätter:So basically, basically what helps a lot is…
Toni Wahrstätter:Today, you give a transaction to a thread, and the thread can very clearly enforce that the state diff is correct, because there is nothing other transactions can interfere with.
Toni Wahrstätter:from the storage read location, it's different. So they need to be brought together at the end of transactions.
Toni Wahrstätter:Kinda collected during execution, and then compared with the BAL.
Toni Wahrstätter:So for… until we don't map storage keys to indices, we might not be able to get this isolation of being able to validate that transaction in full isolation.
Jared Wasinger:Yeah, I think I… I think I was actually just mis… misunderstanding it. I think I…
Jared Wasinger:I… I think it's starting to make more sense to me now.
Toni Wahrstätter:Yeah, we don't need to take a decision on this today. I would suggest that we definitely think about such situation when setting up the test framework, such that we are actually able to test such cases.
Toni Wahrstätter:the attack vector would basically be causing a reorg for the next proposal. So the next proposer would…
Toni Wahrstätter:Potentially face a block that takes too long to execute, and would then be in a very uncertain…
Toni Wahrstätter:situation where you don't really know, should I reorg the previous block because the execution took so long, or should I try to finish execution and build on top of it? So this is essentially the attack here. We could trigger, I think we could trigger reorg's,
Toni Wahrstätter:On a definite, by doing so. And also, of course, like, scaling the gas limit very aggressively to points where
Toni Wahrstätter:We don't have much buffer left.
Toni Wahrstätter:But yeah, I think we… clients should just look into this problem and think how they would actually practically
Toni Wahrstätter:Tech lit?
Toni Wahrstätter:Such that clients are not tricked into doing a lot of batch I.O, while at the same time
Toni Wahrstätter:Facing transactions that only do execution, and in the end, figuring out that everything was, invalid.
Toni Wahrstätter:But figuring out That it was invalid too late into the process.
Toni Wahrstätter:Yeah, is there any other comment regarding this?
Toni Wahrstätter:Yeah, seems like it's not the case, and we don't need to find solutions today. Just wanted to bring it up such that we are aware of this situation.
Toni Wahrstätter:To me, it feels like the cleanest thing right now would be…
Toni Wahrstätter:To do nothing, and just,
Toni Wahrstätter:I mean, for DevNet 2, we will do nothing anyway, because it's, it's not worth it to change something for DevNet 2.
Toni Wahrstätter:But then for DevNet 3, we should probably…
Toni Wahrstätter:It should be the goal that we have this situation, resolved.
Toni Wahrstätter:and Ida.
Toni Wahrstätter:Remove the state locations from the bundle entirely, or we agree on adding, like.
Toni Wahrstätter:first access indices, something like this, to the BAL. I think it would be, from a size perspective, it would be not a big deal. It's more like additional complexity,
Toni Wahrstätter:Though I would… Want to avoid, personally.
Toni Wahrstätter:But yeah.
Toni Wahrstätter:It's good that we have flagged that problem, and we can now… Collectively start figuring out solutions.
Toni Wahrstätter:Awesome.
Toni Wahrstätter:This is quite good timing, we're already at the end of the call.
Toni Wahrstätter:Anything regarding this topic, how to… invalidate.
Toni Wahrstätter:Invalid blocks as fast as possible, or anything that we forgot to… to do…
Toni Wahrstätter:Today, on today's call. Yeah, Cherry, go ahead.
Jared Wasinger:Yeah, I wanted to, bring up something that's a completely different subject, and it should be pretty quick. So… and maybe this is something that, should've… well, I wasn't actually aware of this by the time ACDT happened this week, so…
Jared Wasinger:basically, and I brought it up before, but it's just kind of…
Jared Wasinger:somewhat of a blocker. In fact, it is a blocker for Geth being able to…
Jared Wasinger:to make progress towards DevNet 2, is that the test fixtures currently don't have receipts in them, and we're getting, a lot of receipt root mismatches, and this is related to, I think it's 7778?
Jared Wasinger:the ETH transfer emit log EIP, so…
Toni Wahrstätter:We have different ones, so 7778 is the one that excludes the refunds.
Jared Wasinger:Okay, maybe, maybe it's 7708, I, I, I'm probably getting the number wrong. But, it would be great if we could get, like a…
Jared Wasinger:A release that has the receipts themselves and the fixtures, because otherwise it's basically impossible to debug failing tests, because right now there's just…
Jared Wasinger:Cool, okay.
Jared Wasinger:Yeah.
Jared Wasinger:Yeah, okay, cool.
Toni Wahrstätter:Yeah, seems like this.
Toni Wahrstätter:Was resolved quite quickly.
Toni Wahrstätter:Anything else we should add?
Toni Wahrstätter:For today, anything else people want to discuss?
felipe:Real quick… Oh, yep.
jochem-brouwer:Yeah, Philippe, please go ahead, because I think I want to ask exactly what you are about to be spoken.
felipe:Yeah, real quick, I just want to get consensus on the updates that were made to both self-destruct and calls and transactions to self.
felipe:I think we're all in agreement that
felipe:Any transfer to self should not emit a log unless there's a self-destruct ETH burn case.
felipe:But then also, we need to talk about…
felipe:We need to… we need agreement for DevNet 2 on whether or not it's only a self-destruct log if it's created and destroyed in the same transaction. And so, I just… I think we're all on the same page, but these are changes that have just come up recently.
felipe:And we just need to make sure that we're all in agreement.
felipe:For DevNet 2.
Jared Wasinger:Yeah, on the guest side, we're… We're in agreement.
jochem-brouwer:Yeah, I wanted to ask Philippe about the receipts, like, is adding… because I don't think the fixture lease ever have, like, the receipts in them. Is it, like, easy to add this to the fixtures, or not?
felipe:Off the top of my head, I…
felipe:I don't think it will be too difficult, famous last words, right? But, I think we can… yeah, I think we can take care of this, and I think the request is very sensible. I think we'll… either way, we should figure out a way to do this, for some… for some of these EAPs.
felipe:To help with testing and debugging.
felipe:In fact,
felipe:I'm a little late to the STEL meeting right now, and I'll bring this up, right now, and we'll find a way around it.
Toni Wahrstätter:Perfect.
Toni Wahrstätter:Awesome, yeah, then let's continue that conversation async, and we're at the end of the call.
Toni Wahrstätter:If there's nothing else, then I would say thanks to everyone.
Toni Wahrstätter:And see ya!
Toni Wahrstätter:In two weeks at the next critical call.
jochem-brouwer:Bye-bye. Thanks, everyone.
felipe:Hi, everyone.
Toni Wahrstätter:Thank you, bye-bye.
Chat Logs
00:06:14
Toni Wahrstätter:Agenda:
https://github.com/ethereum/pm/issues/1897
00:06:55
Jared Wasinger:The receipt change got reverted iirc
00:08:21
Stefan Starflinger:https://notes.ethereum.org/@ethpandaops/bal-devnet-2
00:09:56
Stefan Starflinger:added a section on feature flags https://notes.ethereum.org/@ethpandaops/bal-devnet-2#Client-feature-flags
00:12:26
Karim T. (matkt):What network is being used for this?
00:13:20
Karim T. (matkt):When do we expect to have the Shadow Fork ready?
00:13:57
Karim T. (matkt):👍
00:15:23
Karim T. (matkt):We would just need to mirror the mainnet transactions for performance.
00:16:30
jochem-brouwer:I think for testing purely we should not raise gas limit "just" to test the consensus
00:18:02
Karim T. (matkt):There's also the background stateroot.
00:18:23
jochem-brouwer:Antwoord verzenden naar "There's also the b..."
extra thread for state root calculation somewhat in parallel right?
00:18:42
Jared Wasinger:Replying to "There's also the bac..."
Loading the intermediate nodes on extra thread(s), and the hashing
00:19:20
Karim T. (matkt):Replying to "There's also the bac..."
The stateroot will trigger read io
00:19:45
Jared Wasinger:Parallel state root interplays with batch io because reading the intermediate nodes will compete for CPU (it’s not purely disk work to look up from db)
00:20:10
jochem-brouwer:Yes gotcha regarding the interplay of read I/O with the exec, did not realize this, thanks 😁
00:20:12
Jared Wasinger:If we look at them in isolation, it won’t give us a clear picture of the overall performance gains
00:20:42
Karim T. (matkt):Do you launch the prefetch at the same time as the parallelization, or do you launch the prefetch first and then the parallelization
00:22:08
Jared Wasinger:Right now, geth parallelizes the tx execution, state trie update, async loading of bal reads. There’s no prefetching.
But I might rewrite it to prefetch everything first and then do state root update and tx execution. Need to see if it is faster this way.
The rewrite won’t happen by the time devote 2 is launched
00:23:28
Karim T. (matkt):I was also wondering whether it's better to do the prefecth first or everything at the same time. Maybe I'll add a flag to test both
00:24:36
jochem-brouwer:Antwoord verzenden naar "I was also wonderi..."
I think this depends on the scenario. For both choices we can create a test case which performs worse in that case, but actually better in the other. Something to keep in mind, the benchmarks will execute the absolute extreme situations, which in usual blocks ("realistic blocks") will not happen. However we should still ensure that clients can exec and validate these blocks reasonably
00:25:07
jochem-brouwer:Antwoord verzenden naar "I was also wonderi..."
So per-strategy and client-specific we can craft blocks which perform specifically worse on those clients/strategies
00:26:18
Karim T. (matkt):Replying to "I was also wondering..."
That's why I think the shadow fork of the mainnet will also allow us to see the behavior with today's blocks.
00:28:15
jochem-brouwer:Antwoord verzenden naar "I was also wonderi..."
Ah ok, I see, the shadow fork I mentioned is a fork of mainnet w/h executing the blocks on top of it. This is actually a great idea (maybe already proposed before). We would re-execute mainnet blocks but now with BAL enabled (only BALs)
00:28:41
jochem-brouwer:Antwoord verzenden naar "I was also wonderi..."
This gives the realistic gains, not the worst case gains
00:30:05
Toni Wahrstätter:https://github.com/ethereum/execution-apis/pull/727
00:32:07
Toni Wahrstätter:https://github.com/ethereum/EIPs/pull/11066
00:34:31
jochem-brouwer:This comment https://discord.com/channels/595666850260713488/1364000387195076608/1465600399170994231
00:34:36
Toni Wahrstätter:https://github.com/ethereum/execution-apis/pull/726
00:35:46
felipe:It also allows for only accessing state if there's enough gas for everything else. So in a way there is consensus on a performance improvement where we don't touch state needlessly just to revert the frame later.
00:35:52
Stefan Starflinger:https://notes.ethereum.org/@ethpandaops/bal-otel
00:35:52
Jared Wasinger:Geth doesn’t have Otel for bals yet
00:35:55
Karim T. (matkt):It is for devnet 2 your open telemetry spec ?
00:37:37
jochem-brouwer:https://ethresear.ch/t/a-small-step-towards-data-driven-protocol-decisions-unified-slowblock-metrics-across-clients/23907
00:37:53
Stefan Starflinger:Replying to "It is for devnet 2 y..."
Its not a requirement for devnet 2
00:38:06
Karim T. (matkt):Replying to "It is for devnet 2 y..."
Ok thanks
00:41:43
Toni Wahrstätter:https://docs.google.com/presentation/d/1KsjpyPU5CQGbLnSIlHx-e_0CDdGEdonVhVD1d0PzoRM/edit?usp=sharing
00:58:48
jochem-brouwer:If tx 2 access slot A for first time, and it is not in slot change for tx 1 and not in first read in tx 2, it is invalid 🤔
01:03:11
Sixto Palacios:Thank you
01:03:17
jochem-brouwer:I'll add these to benchmark scenarios
01:03:25
jochem-brouwer:(malicious block BAL)
01:04:11
felipe:Will have to think on the pathological invalid block case some more
01:05:13
jochem-brouwer:eth transfers emit log?
01:05:53
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/01KFXH3FY6CZZH3EPYQMJC3BGF?ref=live_chat
01:08:03
Stefan Starflinger:thanks
01:08:06
Sixto Palacios:Thank you
Summary
13 highlights
· 4 action itemsExperimental
Summary
13 highlights · 4 action itemsExperimentaldevnet status
client optimization updates
testing and benchmarking
spec clarifications
malicious block handling
- Malicious BAL attack: garbage storage slots cause wasted batch I/O00:41:43
- Without transaction indices, blocks validated only after full execution00:44:43
- Three solutions: do nothing, remove state locations, or add indices00:50:59
- First-access indices increase size 4%, enable early invalidation00:52:03
organizational
- Receipt change for 7778 reverted; gas spent remains in receipts00:07:20