Barnabas:Welcome, everybody, on All Core Devs testing call, number 62.
Transcript
Barnabas:I'm just gonna post quickly the agenda for today. It's a pretty light agenda, so hopefully we can finish ahead of time.
Barnabas:First of all, happy birthday to the Beacon Chain. We just celebrated the fifth year anniversary of the launch of the Beacon Chain network.
Barnabas:I think that's a pretty big achievement for everyone, that are on this call and not on this call.
Barnabas:So, well done.
Barnabas:Regarding Fusaka, we did, main initiative work last week. Main Initiative work 1, was a success, we didn't find any, obvious bugs in there, so,
Barnabas:I think we are very safe to, go into Mainnet for Fusaka Fork on coming Wednesday.
Barnabas:Does anyone have any mentions regarding Fusaka?
Barnabas:In case not,
Barnabas:I guess we will see how it will draw on Wednesday, but I think we should be all good to go.
Barnabas:Okay, let's get into Glamsterdam, then. Maybe, Stefan, you can take over regarding the BAL DevNet Zero update?
Stefan:Yeah, sure. Can you hear me?
Barnabas:Yup.
Stefan:Perfect. We're making a lot of progress. I think we have a lot of clients that are now passing most of the execution spec tests.
Stefan:So that's really nice to see. Regarding the DevNets, we will probably be able to start one very soon. I'm still running some Kurtosis local testnets and running into some issues there.
Stefan:I've already, created a PR to the execution specs with one issue I found in Nethermind with, gas, memory expansion.
Stefan:how it's accounted, and otherwise, I'm… we're looking into a pre-compile issue also right now with Nethermind, but after that, I think we should be able to have 3 clients that are passing most. Maybe it would be good to get some client updates as well.
Barnabas:Yeah, that would be good. Is any EL teams ready to give us an update on their BAL development?
Marc:Yeah, for Nethermine, it's going well, passing 100% of the tests now.
Marc:And just discussing with Stefan that issue you mentioned, which, doesn't seem to be covered by the test at the moment.
Barnabas:Thank you. Anyone else?
draganrakita:Don't miss out.
Dustin:actually passing… -Oh.
draganrakita:Go, go for it.
Dustin:Nimbus is passing all, but I think last I checked, 5 or 7? I forget which number of the tests.
Dustin:So, yeah.
draganrakita:From Reth side, we had… we…
draganrakita:failing some withdrawals tests that I need to take a look.
draganrakita:There should be it.
Stefan:Is Geth here?
Barnabas:I guess not. Nobody from Geth or Besu?
Barnabas:Yeah.
Barnabas:Or is anyone from Besu around?
Barnabas:In case not, does anyone have anything else regarding… BAL devnet?
Barnabas:Yep, Spencer?
Barnabas:Hey.
spencer-tb:Yeah, I just wanted to say that it might be worth,
spencer-tb:Us on the testing side running all the static tests, so essentially the…
spencer-tb:to tests from Ethereum tests, refilled for block access lists.
spencer-tb:I don't know, like, the fire has just been put out, essentially, for all the tests right now, and clients are passing, but…
spencer-tb:it might be worth… Also, getting all the clients to pass those tests for block access lists, too.
spencer-tb:just thought I'd say that. But also, if it's a small dev net, it could also be worthwhile getting that up in the air.
Stefan:Does this also include, like, sync testing, for example?
spencer-tb:No, just, essentially, extra… extra tests, like, there might be some weird niche…
spencer-tb:niche case that, it could uncover.
Stefan:Okay, but I think that's it from my side for buck-level access to this.
Barnabas:Okay, thank you. Regarding APBS, is anyone around to give us an update?
Justin Traglia:From the spec side, we're still working on adding, test cases for get expected withdrawals.
Justin Traglia:We have an update… sorry, we have a breakout call this Friday. I'll post the agenda right now.
Justin Traglia:I might try to look into refactoring, get expected withdrawals to make it a bit cleaner this week.
Justin Traglia:And I guess, just whatever updates client teams have.
Justin Traglia:Regarding implementations.
Barnabas:Regarding the trustless payments, I think, if anyone else has any concerns, then this would be a call to bring it up, right? Otherwise, we're gonna be proceeding with the trustless payments, for sure.
Justin Traglia:Correct. But, keep in mind, the final decision on this won't be made this Friday. We're gonna save that for…
Justin Traglia:the next ACDC call, so, like a week and a half from now.
Barnabas:Oh, okay. I thought that it would be made… the call would be made on Friday already.
Justin Traglia:I mean, I don't think it should. Not everyone joins the breakout call, and it's a pretty important decision to make, so… I'd feel more comfortable making it at ACDC.
Barnabas:Okay.
Barnabas:Any client teams have an update, regarding implementation? Readiness?
Barnabas:Okay, from Lone Star, they have the…
Barnabas:Please progress on state transition. I'm passing the 1.6.1 specs. It's great.
Barnabas:Anyone else?
Barnabas:You guys don't need to be so shy.
Barnabas:Feel free to speak up.
Barnabas:In case no other updates, we can move on to the next topic, which is gonna be further gas increases.
Barnabas:So, Minnet just hit 60 million guests, last week.
Barnabas:Which is very good news.
Barnabas:And, I think the next step forward will be targeting 80 million guests.
Barnabas:Do we have any updates regarding how we can achieve 80 million? And,
Barnabas:What kind of repricing games we're gonna be playing for that?
Barnabas:Yep, listen.
jochem-brouwer:Yeah, I wanted to mention that for the 80 million guests, we have the problem with the receipts.
jochem-brouwer:So this problem is that the def P2P network, it can
jochem-brouwer:It has this high limit of 10 megabytes of message limit.
jochem-brouwer:And we have a problem with the receipts, because at 83 million, we have this theoretical limit of actually going over this.
jochem-brouwer:Well, Kamil was saying, hey, we switched to an issue for 85, but, well, I would say 80 is getting pretty close.
jochem-brouwer:So, I would just mention the EIP which actually solves this thing. It's EIP-7975.
jochem-brouwer:well, one of us, I would still say that 83 is also very close to it. I just want to mention that we are getting very close to this limit, and this EIP solves it.
jochem-brouwer:So, I think that we should start to implement this EIP, or something else which solves it. So, the EIP itself, it will just split up the def P2P messages into partial messages, and then we don't have this limit where we cannot send.
jochem-brouwer:The receipts which go to go over 10 megabytes.
jochem-brouwer:Yep.
Barnabas:Right, so… but this doesn't require a hard fork, right? This can be just, rolled out.
jochem-brouwer:Yes.
Barnabas:You got pretty… okay.
jochem-brouwer:It's a networking thing, but of course, all the clients could have to implement this. Yeah, but just wanted to mention this. Okay.
Barnabas:What would happen if, one client implemented it, and we would have, like, one message exceed the 10MB limit?
Barnabas:Like, you wouldn't be able to peer with that one client, right?
jochem-brouwer:I am not sure about this, but maybe if Felix from Geth is here, or someone from Geth can maybe explain this, but the EPA says that this is a sync issue, so this is likely not… well, that's not very nice, so maybe someone else can fill in on this.
Łukasz Rozmej:So, the chain would progress, the problem would be that, the sync would not work for anyone.
Łukasz Rozmej:Except this one client could sync from itself, because it's a different protocol version.
Barnabas:Okay, but the question is, do we want to actually, roll this out with the next hard fork in Amsterdam, or do we want to see…
Łukasz Rozmej:It can be hard for class, because it's a different protocol, DevP2P version, so we could do it without a hard fork, as soon as everyone is kind of ready.
Barnabas:Okay, what do we want to target, for this release, then?
Barnabas:Is this something we can start discussing now?
Łukasz Rozmej:So, for example, Nethermind have this scheduled to be worked on, but we are not currently working on it. I expect we will be working on it in maybe 2 weeks or something.
Barnabas:Okay, so maybe some… something like end of January, could actually work for this?
Ben Adams:I mean, it's… because of where it'll happen at syncing, it's not a disaster, because it means you're… you're starting up a new node, so the fix would be to upgrade your client.
Ben Adams:Yeah, so…
Łukasz Rozmej:So, as soon as everyone has a release with it, we can… it's not a blocker.
Barnabas:Okay, I will, start reaching out to different EAS and check on their implementation readiness, and then we can…
Barnabas:Tried to schedule it in.
Barnabas:Sometime.
Barnabas:Probably end of June, or beginning of February.
Barnabas:And, regarding any other blockers for 80 million,
Barnabas:Assuming that we could go on to 70… 870, then could we just go straight to 80 million?
Ben Adams:I'd just like to point out, though it's a bit redundant, since we're doing the fork on Wednesday, and we're unlikely to increase before then, that we'd have to wait till after Fusaka to…
Ben Adams:To push it higher.
Ben Adams:But, I mean, you know, that's only a couple days.
Barnabas:Push for what, exactly?
Ben Adams:To go above 80 million, so we want, like, the receipts… we want… we want the changes in Fusaka to go higher than where we are now, so that would be, like, the tap on transaction limit, etc.
Ben Adams:But As I say, that's only 2 days away, so…
Barnabas:I just put a…
Ben Adams:Put it on the record.
Barnabas:But we should just pipeline these things, and I don't think, like, Wednesday should be a blocker to, like, consider what else are we missing for the 18 million.
Ben Adams:Yeah, I think it… I think it's just the receipts.
Ben Adams:After a second.
Łukasz Rozmej:So, as far as I know, Carlos from EF is testing some… state scenarios?
Łukasz Rozmej:State-related scenarios, and some of them were… not great.
Łukasz Rozmej:Right now, but I think he didn't have the tests with applying the transaction cap from Fusaka, so… Yeah, so I think he wanted to redo it, so I don't know the state of it.
Łukasz Rozmej:Kamil?
Kamil Chodoła:Actually, actually do that. We need to rework all of our gas benchmarks to Fusaka right now.
Kamil Chodoła:But this shouldn't be, like, super hard, so we'll do that this week, hopefully. And this and next week, to make it work.
Kamil Chodoła:And yeah, this is exactly the point that some stateful tests will be, quite challenging, but it's more likely on the edge right now. And there are some new scenarios which were never analyzed by a rigon, as I believe, and Bezu, where the performance is not the greatest.
Kamil Chodoła:But we need to sit and check if those scenarios are actually valid.
Kamil Chodoła:So, there are quite a few points. I will try to summarize that and send a note on what needs to be done to bump it further. But for sure, we need to wait for Fusaka first to even start considering that, and EF70, as mentioned. But if 70 is required for anything above 80.
Kamil Chodoła:So I would even say that maybe we could go safer with 75 or something, just to leave some buffer for this issue.
Kamil Chodoła:and then go straight to 100 after the solving that. So on protocol level.
Kamil Chodoła:Actually, on networking level, there is only this receipt size issue.
Kamil Chodoła:But there are some things which probably can be optimized in clients to make it smoother.
Kamil Chodoła:the biggest issue from Netarmine's side, I see, is that those stateful scenarios are requiring some bigger changes on DB level, which we have.
Kamil Chodoła:But yeah, we are still analyzing them.
Barnabas:Okay, thank you.
Barnabas:Yeah, the… I saw a bunch of suggestions, to just move to 75 instead of 80.
Barnabas:I'm not sure if, that's something we want to do, even, without the,
Barnabas:Spilling up the receipts?
Kamil Chodoła:Can you repeat, please?
Barnabas:Is there a…
Barnabas:Is there an appetite to actually just move to $75,000 instead of $80 million as the next step without the receipts?
Barnabas:Or do we just want to, get unblocked on the receipts and just push to 80, or…
Barnabas:Even further?
Kamil Chodoła:In my opinion, I would go 75 first, and just to leave a buffer between this issue, because maybe there is something which we didn't consider, so it will be slightly slower, but I guess this is the maxed out thing which we already have in our tests and in our knowledge.
Kamil Chodoła:So 75 will leave us slight buffer, plus it will make us additional 15 MHz increase, and then 100 after… after solving that.
Barnabas:Does it pen?
Ben Adams:I'd also add, since it takes quite a while to build momentum.
Ben Adams:But also we can't really determine the timing, then…
Ben Adams:We'd probably want to start the push before…
Ben Adams:E70 was rolled out, but also…
Ben Adams:Give us… give us that buffer in case it… it suddenly went up really fast.
Ben Adams:You know, because we, as I say, we can't control the timing when the gas limit goes up, so I'd go more for 75.
Ben Adams:So we can start.
Ben Adams:Encouraging people to move up earlier, but also have the buffer in case it happens before we
Ben Adams:Have the protocol change widely rolled out.
Barnabas:I mean, 75 is something that could potentially be just bundled together with BPO3, because BPO3 would require a client release anyway.
Barnabas:Right?
Ben Adams:Yeah.
Barnabas:And we may… we may have ETH70 by then.
Ben Adams:So, we could go.
Ben Adams:We could do the AT or whatever.
Barnabas:Yeah, I guess this is something we can start discussing now, and then hopefully roll it out around the end of January.
Barnabas:Again, it will be up to the 870 implementation, and implementation readiness, whether we're gonna be targeting then 80 million or 75 million guests, whichever seems safe at that point.
Barnabas:And Kamil.
Barnabas:Hmm.
Barnabas:Kamil, would you like to discuss this, testing block V1?
Kamil Chodoła:This is something which Marcin is working on. I can just give a short
Kamil Chodoła:info on that. So, basically, we want to introduce a new namespace under our RTC, which will be fully utilized for testing capabilities. And here, this one specific example is to have a common interface between EL clients to trigger block building.
Kamil Chodoła:from RPC perspective, so we'll be able to basically performance test block building under certain…
Kamil Chodoła:conditions, and also it will unlock us some better possibilities for… to generate lists. So, if you have any questions to that, feel free to ask me or Martin.
Kamil Chodoła:But yeah, this is something we are working on right now, and would be good to have some… someone from EL teams and from testing, DevOps team to take a look at.
Marcin Sobczak:Yes, and I'm working on, like, proof-of-concept implementation in Nethermind right now, so, we'll have it soon.
Barnabas:Yeah, this looks great, from testing… side of you.
Barnabas:Is any other EL Iran that has read this, PR and could comment on it?
Barnabas:In case not, please take a look and, give us the feedback in maybe a week from now.
Barnabas:Okay, is there any other discussion topics, regarding the higher gas limit?
Barnabas:In case not, maybe we can peer towards the next blob flag discussion. So, there's an EIP open for the next blobs, which some…
Barnabas:Client teams liked, and some client teams didn't really like, because it's basically just a single flag that will limit local block builders to be able to limit how many, blobs they will include in a block.
Barnabas:Nethermind has a implementation of this, Reth has an implementation in their, main branch, in their trunk branch.
Barnabas:Is any other EL teams have an implementation, or opposed to having implementation for this?
Barnabas:Poem, this is not a…
Barnabas:a CL question, this is an EL-related question, but I can post the EIP in a second.
Barnabas:It's EIP7872.
Barnabas:Anyway, I think we should try to get this included into every single EL before we hit the next BPO, because this could actually affect the local block builders if they have to build too many blobs with their limited bandwidth. They might result in pushing out an orphan block.
Barnabas:So, this is, definitely a nice-to-have feature to… to include.
Barnabas:I see that there's resource also tracking,
Barnabas:That's good. And I haven't heard any, pushback from Geth either, so I think we should be good to go, and hopefully we can also start testing this feature, right after Fusaka.
Barnabas:Okay, and then there's one more discussion topic that's,
Barnabas:a bit, deeper rabbit hole, so… engine API changes,
Barnabas:I proposed an engine API change in the execution… Execution chat in R&D.
Barnabas:I'm basically saying that we should switch to SSD for the engine API in order to decrease the times we spend on decoding the JSON payload.
Barnabas:The topic brought up a bunch of, different, proposals, such as moving potential to, gRPC, or, moving to Protobus.
Barnabas:But yeah, I would like to hear the opinions of different EL teams, especially, like, what they think about just
Barnabas:migrating everything into SSD as an optional, thing.
Barnabas:Because, the more blobs we have, the more time it's gonna take to decode the, basics for encoded JSON.
Barnabas:Not just in the discussion topic.
Barnabas:I'm just curious if anyone has anything to say regarding this, on this call.
Alexey:Do you hear me?
Barnabas:Yep.
Alexey:So… Just, wanted to mention, then, if we…
Alexey:introduce this encoding on your side. Right now, it will…
Alexey:will help us, to move quicker, to our end goal of having SSV.
Alexey:Everywhere, as a replacement for RLP.
Alexey:And this format is not just a data format, it's a thing that we need to… optimize for.
Alexey:It means that, we can, store data, and.
Alexey:Like, in database and, in memory, ready for, this, Encoding, and pass it quicker.
Alexey:We need to optimize serialization, make it parallel, maybe.
Alexey:And all this work can start when we have at least something to work on. And if we could have a couple of endpoints supporting this format.
Alexey:It would, I would say start work on, active work on SSD, on execution on their side.
Barnabas:Sorry, do you mean, like, CL that would support this?
Alexey:Sorry?
Barnabas:Did you mean that, you need an example from SCL?
Barnabas:To support the SSD?
Alexey:No, no, I mean, examples. I mean, like, applications of this format.
Alexey:Like, huh on Yale's side, to start experiment with optimizations and, proper, serialization, and maybe miracleization, even.
Alexey:We just need to, like…
Alexey:real application of SSD on your side, yeah.
Barnabas:Wouldn't the engine API count as an application in your eyes?
Alexey:Yep, yep, exactly.
Barnabas:Yeah, so, yeah, I think this could be a very good first step into assessing everything, the whole stack.
Barnabas:And it's not a huge change. Like, you wouldn't need to touch too many databases or anything.
Barnabas:In my eyes, this is basically as easy as it gets, to introduce SSD into the EL.
Łukasz Rozmej:So I think this is a matter of prioritization.
Łukasz Rozmej:And… While it isn't consensus in any way, so we could also do it outside of the fork.
Łukasz Rozmej:this should be considered… if we want to do it, it should be considered when scoping Amsterdam, because it is actually…
Łukasz Rozmej:especially for us, when we don't have a good SSD library out of the box,
Łukasz Rozmej:It's quite heavy on the effort.
Barnabas:Yeah, so, I don't know if this would require an EIP in your eyes.
Łukasz Rozmej:It requires at least, execution spec, changes to execution spec, which are not 3D EIPs.
Łukasz Rozmej:And, and, considering, like I said, considering in… at least for the scope planning of Glamsterdam.
Łukasz Rozmej:So we just planned for it.
Łukasz Rozmej:In terms of, like, the size of the scope.
Barnabas:So the journal blocker for future blob scaling could actually be limited by this, decoding.
Barnabas:Based on the numbers that we've seen before, trouble said that, he spent about 300 milliseconds on 6 to 9 targeted max values, which is a significant amount of time.
Barnabas:I know that, some, teams said that it was a lot quicker for them.
Barnabas:And I'm still waiting for extra benchmarking, but, potentially we probably want to roll this out before Glamsterdam again.
Barnabas:at least the latest by Glamsterdam, if we are actually aiming for, like, 72 blobs.
Łukasz Rozmej:Do we have numbers for SSD versus JSON?
Barnabas:In any client?
Barnabas:Well, we don't have any SSD implementation in any of the years, so I would say no.
Alexey:Yeah, let's try to compare, considering we have GitBluff's implementation.
Barnabas:Okay, so I guess we should actually do proper benchmarking with the different max values.
Barnabas:And then, if it's something that we actually have to prioritize in Amsterdam or not.
Łukasz Rozmej:Yeah, and it still should be, like, brought up in Glamsterdam planning, just because if we decide to do it, we might want to, you know, do less in Glamsterdam of other things, just to have a bit more headroom.
Łukasz Rozmej:And regardless if we even roll it out before Glamsterdam, right?
Barnabas:Yep.
Barnabas:Okay, I will, try to push for some benchmarks on this then.
Barnabas:Mountain.
Barnabas:Go forward.
Barnabas:Okay, is there any other topics? I think we still have a bunch of time for open discussions, if anyone has anything else to raise.
Barnabas:Yeah, Mario raised a good point that we can probably have benchmarks for all the different formats and figure out which one makes the most sense.
Barnabas:It was the engine that blops.
Barnabas:Fun.
Simon (@siladu) | Besu:Yeah, I'm just wondering, what,
Simon (@siladu) | Besu:what we should be aiming for, really, because I think get… what is in get blobs also applies to, get payload as well. I didn't write, get payload there. But,
Simon (@siladu) | Besu:And that's gonna include the block as well as the blobs.
Simon (@siladu) | Besu:Which will scale with the gas limit as well, so probably…
Simon (@siladu) | Besu:engine get payload is the,
Simon (@siladu) | Besu:the more important one, I think.
Barnabas:Yeah, I think if we do end up going down the route of changing away from JSM to let it be SSD, or let it be literally anything else, we should actually consider, too, switching everything in the engine API, not just
Barnabas:A specific function.
Barnabas:Like, get maps, or get payload.
Simon (@siladu) | Besu:Sure, I would agree with that if we go with SSE.
Simon (@siladu) | Besu:But I'm wondering what, like, what is the impact on the CL? At what point does it become a problem?
Simon (@siladu) | Besu:Because that'll determine the priority, I guess.
Barnabas:Exactly, yeah. Yeah, we're gonna need to have better benchmarks for that, I guess.
Barnabas:And have everything written down, black and white, and then we can figure out,
Barnabas:How big of a problem this is.
Barnabas:Justin, I think we can,
Barnabas:we can merge the ball and PPS breakout calls to ACDT from, like, next year onwards.
Barnabas:At the 1st of January onwards.
Justin Traglia:Okay, that works for me. Sometime, beginning of next year.
Barnabas:Yeah.
Barnabas:I'm not sure if anyone else has a comment on that, but…
Barnabas:Yeah, next week, basically.
Barnabas:But, like, it will be a bit too short notice, and I think we're gonna have a bunch of cancellations also in the end of the year, with Christmas and New Year's coming up, so I think it would be cleanest to just, have the current schedule going on for the rest of December, and then, yeah, decide which calls to cancel, and then…
Barnabas:From next year onwards, we're just gonna start with, ACP.
Barnabas:those topics.
Barnabas:And I think the first ACDT will be on the 5th of January.
Barnabas:And regarding the lost ACDT,
Barnabas:Well, I'm not quite sure yet.
Barnabas:But we're gonna have it for the next few weeks, for sure.
Barnabas:You can get back to that, recording from now.
Barnabas:Okay, thanks for everyone's time. I think we can call it a day for now.
Barnabas:And see you all on Wednesday at the Fork.
Barnabas:Good luck, everyone. Bye-bye.
Justin Traglia:Hi, everyone.
Łukasz Rozmej:Bye.
Pooja Ranjan:Thank you.
Chat Logs
00:02:54
Barnabas:https://github.com/ethereum/pm/issues/1820
00:03:15
Trent:❤️ BC
00:03:18
spencer-tb:🎉
00:05:08
felipe:I will take a look at your PRs today
00:06:41
felipe:Besu is at 100% passing
00:08:19
Mario Vega:I’ll coordinate with Felipe to get these filled, great suggestion spencer 👍🏼
00:08:20
Justin Traglia:ePBS breakout call this Friday: https://github.com/ethereum/pm/issues/1801
00:08:32
Dustin:sorry, have to go, other meeting, basically for ePBS steady progress, we're been merging into trunk
00:09:43
nflaig:we have progress on state transition and passing v1.6.1 spec now
00:11:06
Kamil Chodoła:receipts are issues for 85?
00:11:23
Barnabas:Replying to "receipts are issues ..."
sounds like 80<83 😄
00:11:24
jochem-brouwer:https://eips.ethereum.org/EIPS/eip-7975#rationale
00:11:44
Kamil Chodoła:Go to 75 then :D and then eip implementation to unlock 100
00:12:37
Kamil Chodoła:Jochem let's spinup a perfnet for that
00:13:47
Simon (@siladu) | Besu:So is that 25MGas/s or 18.75MGas/s target 😁?
00:14:04
jochem-brouwer:This EIP is PFId for Glamsterdam BTW, but it is thus a network fork (update of devp2p/eth protocol). But we would need this at some point once we get closer to the limit (83 MiB)
00:15:43
jochem-brouwer:I'd also like benchmarks in
00:16:01
jochem-brouwer:Antwoord verzenden naar "I'd also like benc..."
To test the exec speed, if 80M is ok
00:17:32
draganrakita:75 makes sense
00:18:42
Simon (@siladu) | Besu:Maybe should wait until BPO2 has stabilised on mainnet first?
00:19:02
Barnabas:Replying to "Maybe should wait un..."
none of this would be rolled out before that 😄
00:19:14
Barnabas:Replying to "Maybe should wait un..."
we just begin to discuss it
00:19:54
Simon (@siladu) | Besu:Replying to "Maybe should wait un..."
Does 75 require client changes?
00:20:00
Barnabas:Replying to "Maybe should wait un..."
it doesn’t sound like it
00:20:28
Kamil Chodoła:https://github.com/marcindsobczak/execution-apis/blob/main/src/testing/testing_buildBlockV1.md
Would be great for other client teams to take a look (very early version - still needs some small changes) - but will be a huge unlock of testability of block building and better tests generation.
00:21:34
Barnabas:Replying to "https://github.com/m..."
is this an already open PR?
00:21:50
Barnabas:Replying to "https://github.com/m..."
we could bundle this pr to one of the Bal devnets if people are happy about it
00:21:52
Marcin Sobczak:Replying to "https://github.com/m..."
https://github.com/ethereum/execution-apis/pull/710
00:22:07
spencer-tb:Strongly support this from testing (steel) side!
00:22:41
Kamil Chodoła:We can follow back on that next week
00:23:22
Mario Vega:Replying to "Strongly support thi..."
I think the only open qs for this was whether we want to create invalid blocks with this, but I think we really should not.
00:24:02
pawan:Can you link the PR/issue for this?
00:24:29
Barnabas:https://forkcast.org/upgrade/glamsterdam#eip-7872
00:24:35
Mario Vega:https://eips.ethereum.org/EIPS/eip-7872
00:24:45
Stefan:Replying to "This EIP is PFId for..."
does this calculation consider the gas limit on individual txs of 23mil?
00:24:53
Simon (@siladu) | Besu:Besu has an issue tracking it but not implementation yet https://github.com/hyperledger/besu/issues/7683
Not aware of any objections
00:26:50
Barnabas:https://discord.com/channels/595666850260713488/1443978877440626809/1443980019947929783
00:29:42
Alexey:+rest
00:29:45
Łukasz Rozmej:I agree, still not that easy :D
00:29:59
Barnabas:Replying to "I agree, still not t..."
not saying its gonna be easy, its gonna be as easy as it gets
00:30:54
Simon (@siladu) | Besu:Is there consensus on EL being SSZified in general?
00:31:09
Barnabas:Replying to "Is there consensus o..."
its on a wishlist
00:31:29
draganrakita:Replying to "Is there consensus o..."
In general, rlp does the job
00:32:02
Mario Vega:There’s also some research that needs to be done in order to know which format is the most optimal for clients, I feel we should really think about this
00:32:11
Simon (@siladu) | Besu:I think 72 blobs should be significantly under 300ms with some optimisations, even with JSON
00:32:53
jochem-brouwer:Antwoord verzenden naar "There’s also some..."
What research is this?
00:33:02
jochem-brouwer:Antwoord verzenden naar "There’s also some..."
(is there someone looking into this specifically?)
00:33:38
Mario Vega:Replying to "There’s also some re..."
Benchmarking with prototypes from each client, I feel like if we decide on a format, and then when it comes to impl, el clients might find that this is even slower or something
00:33:59
Simon (@siladu) | Besu:What is the ceiling response time for engine_getBlobs or engine_getPayload?
00:35:16
Kamil Chodoła:So actually testing namespace solves the benchmarking testability of that? :)
00:35:26
Justin Traglia:When should we transition BALs/ePBS breakout calls to ACDT? I forget when we did this for Pectra/Fusaka.
00:36:07
Chris Berry:I seem to remember someone saying ACDT is for the next fork. So technically next week.
00:36:19
Chris Berry:Or what Barnabas said
00:36:51
Justin Traglia:Agreed 👍
Summary
7 highlights
· 2 decisions · 4 action itemsExperimental
Summary
7 highlights · 2 decisions · 4 action itemsExperimentalfork status and schedule
- MSF-1 successful; Fusaka mainnet fork confirmed Wednesday00:03:20