Barnabas:Welcome to the ACD testing call, number 76. Today is the 30th of March. Akash, can you start the stream, please?
Transcript
Akash | ECH:Yep, we are alive.
Barnabas:Yeah, thanks. So, welcome everybody to All Core Devs testing call number 76. Today is the 13th of March 2026.
Barnabas:Let's jump straight into it.
Barnabas:We have the agenda.
Barnabas:Not that quick.
Barnabas:It's a bit, shorted agenda today, because Pari made the agenda and he couldn't make it to today's call.
Barnabas:But let's go through, Blob DevNet Zero. Currently, it looks like Prysm and Lighthouse are planning on trunk-ready implementations by the end of April.
Barnabas:So, we're going to try to do a rollout plan, shortly following that.
Barnabas:Parithosh's team will, run the trunk, versions of Lighthouse and Prysm with the partial cells.
Barnabas:Implementations on about 300,000 validators.
Barnabas:Other client teams, if you're still working on this, and you have an update on the partial cell implementation, you may speak up now, or put your
Barnabas:comment in the chat, and we would like to onboard you to Blob Definite Zero as soon as possible, hopefully.
Barnabas:Amazing.
Matthew Keil:headway on it, and getting closer will hopefully be in the next week or two, we'll be ready for DevNet.
Barnabas:Great. Thanks.
Barnabas:Not sure if anyone from Teku is around to comment on it, also.
Barnabas:I have a… I have opened a new PR, targeting EIP8136, which is the partial cell, EIP.
Barnabas:And I would like to include it in the Glamsterdam and not the EIP. I'm just curious, what the client thinks.
Barnabas:Think about this change.
Barnabas:I don't think we're gonna be rolling this out, much earlier than Glamsterdam, anyway.
Barnabas:Yeah, maybe…
Barnabas:So everyone can take a look at this offline. Is there any… any other team that, would like to comment on Blob DevNet Zero?
Barnabas:If not, then let's go to NFT DevNet10, which is the 870 config.
Barnabas:I'm not sure if Marius is on the call, maybe… or anyone else is working on 870 right now?
jochem-brouwer:Yeah, maybe as a general comment also on this networking change for the fork. EV70 is required for
jochem-brouwer:glance to them, at least if we want to go beyond the… well, I don't know what the exact number is, but the 80 million guess, because if we don't require E70, then we have this syncing problem where you can create, like, this block where the logs go over this 10 megabytes.
jochem-brouwer:Where you can't sync anymore, so I don't think we should actually introduce this to a different category, but it should be,
jochem-brouwer:In the configured for inclusion.
jochem-brouwer:Because it is required for the fork.
jochem-brouwer:Just as a comment on that.
Barnabas:Well, it would be required for the fork if you also say that we want to have a gas limit of 80 million, right? And we don't currently have an EIP that would be raising the gas limit.
jochem-brouwer:Yes, okay, that's a good point, yeah. Fair enough, fair enough.
Barnabas:Yeah, I'm not sure if we are gonna have another EIP to raise the gas limit at the fork.
Barnabas:If you do…
Barnabas:add one, then we could push it back. But for now, I would say that this is still an optional EIP for now.
Barnabas:Yeah, so I'm not sure if we want to have it 70 as a prerequisite for DevNet 3, while DevNet 3. Would every EL team would be happy with that?
Barnabas:I see Lucas, the management has already 870. I assume then…
Barnabas:I think it would be fine.
Barnabas:Any other EL teams can speak up?
Barnabas:Maybe you can make the decision about that, offline as well?
Barnabas:Yeah.
Barnabas:Okay.
Barnabas:Yeah, so Bezu, also seemed to have 870 and 71.
Barnabas:I'm not sure if, I'm not sure if you should have all 3 of them activated.
Barnabas:And that will bring us to broaden S3 discussions. Stefan, maybe you can take over?
Stefan Starflinger:Yes, sir.
Stefan Starflinger:So, about definite 3, I think the main blocker, is 837 still, especially the 2D gas accounting. There are some issues when I run the EVM fuzz, scenario, with the spammer.
Stefan Starflinger:There are quite, still a few orphan blocks. I managed to get it running stable with most clients individually.
Stefan Starflinger:But if I mix the clients up,
Stefan Starflinger:Or pair them together, then it breaks apart pretty quickly.
Stefan Starflinger:One thing I found, recently was, in Geth, I think.
Stefan Starflinger:I can share the link in a bit, but I shared it with the relevant teams already, with the 2D accounting, where the block
Stefan Starflinger:Can, go over the gas limit.
Stefan Starflinger:With either, state, or regular gas. And before, like, the classical gas limit for the block was informed, I think that was in gas.
Stefan Starflinger:At a Nimbus, so far, so there are still gaps in the testing, and, as far as I understand, Spencer will release another version.
Stefan Starflinger:With some extra tests, to get, really, the edge cases. It doesn't really make sense to start a DevNet if there are so many consensus-related issues, unless we just start the DevNet without, any transactions, which I don't think either makes sense as well.
Stefan Starflinger:And I've also, yeah, I mean, it's very brutal. It's also very tough to find issues. If I run them and I see orphaned blocks, it's very hard because of the…
Stefan Starflinger:Kind of difficulty of the accounting to see where the issue is.
Stefan Starflinger:Yeah.
Stefan Starflinger:Maybe Spencer, if you're on the call, maybe you could give an update on the next release that you're planning to make?
spencer-tb:Hey, everyone. Yeah, thanks. Thanks, Stefan. I think,
spencer-tb:One thing I would like to mention is that we're running, all the tests…
spencer-tb:From Osaka to Amsterdam now, so…
spencer-tb:There will be some extra fills.
spencer-tb:Also related to AT37, but also unrelated, so if clients can take a look at those.
spencer-tb:yeah, the next release…
spencer-tb:won't really have any spec changes, I think, where the spec is right now, I think we can…
spencer-tb:We can stay with that, and just focus on getting…
spencer-tb:More test coverage. But yeah, we'll try and get a release out.
spencer-tb:And the next day with, extra tests. I think one thing
spencer-tb:I guess I would like to ask is,
spencer-tb:Maybe we can try and get… Some…
spencer-tb:some… some… someone assigned from each… each client team, who is, like, visibly the… the person working on AT37.
spencer-tb:and then,
spencer-tb:We can also get some extra resources and steel, and we can just really try and push on this.
spencer-tb:With ironing out everything, because it's,
spencer-tb:Yeah, it's been… been going on for a while, I think,
spencer-tb:Overall, there have definitely been amazing input from client teams. I think Trogan from Wrath has been extremely helpful in finding
spencer-tb:spec mismatches, but I think if we could maybe try and get a group of us together, with,
spencer-tb:Even myself, Stefan, someone else from Steel, and then an individual person from each client team.
spencer-tb:And we can maybe start, just trying to iron everything out. Yeah.
Stefan Starflinger:Yeah, that sounds great. Would it be possible also to get a quick update from the clients, how it's going?
Stefan Starflinger:Maybe from Nethermind?
Łukasz Rozmej:So,
Łukasz Rozmej:In terms of testing and spec, we recently fixed a lot of issues, and it's even shown in test, and we still have
Łukasz Rozmej:A few issues left, but it's comparable to the other clients now.
Łukasz Rozmej:In terms of, parallel processing, we're…
Łukasz Rozmej:Still… close, but not there yet.
Łukasz Rozmej:So hopefully I've… I really hope in a week we can say that it's available.
Stefan Starflinger:Okay, so would something like, launching next week, Wednesday, be realistic?
Łukasz Rozmej:It's optimistic, but maybe.
Stefan Starflinger:Okay.
Stefan Starflinger:Then, Someone from Gas here to give an update?
Stefan Starflinger:If no one is here from guests, let's go with Nimbus, EL.
Stefan Starflinger:So I wonder…
Stefan Starflinger:everyone at ECC today. Then Erigon.
Stefan Starflinger:Otherwise, Reth?
Jen:Let me follow up async, but next week should be good.
Stefan Starflinger:Okay, Besu?
Daniel Lehrner (Besu):Yeah, same, same for us. I think we're more or less ready, so next week. Should be okay.
Stefan Starflinger:Okay, any updates regarding testing?
Stefan Starflinger:Have you tested with another client, as well, or just, in Bezo?
Stefan Starflinger:networks.
Daniel Lehrner (Besu):Right now, just in… in Besu Networks. We need to check with, Kurtosis.
Daniel Lehrner (Besu):Next, but at least, according to the tests.
Daniel Lehrner (Besu):We should be, spec compliant. But yeah, we need to test with Kurtosis.
Stefan Starflinger:Okay, great.
Stefan Starflinger:Okay, I think that's it from my side for DevNet 3.
Barnabas:Thank you. So the next topic, was Ball DevNet 4,
Barnabas:I think it would be better not to talk about Ball.net 4, at least till we launch Ball.net 3, and also, after that, I think it would be time to…
Barnabas:merge, EPBS with local access list, so maybe it's gonna be prime time to start talking about Glamsterdam.net Zero.
Barnabas:But before we do that, maybe we can, start discussing EPPS DevNet1 progress.
Barnabas:Anyone from prison?
Barnabas:Maybe, you can say how things are going?
Potuz:Well, it seems Terrence is not there. So… I think we're good to go. We're, Barnabas knows better than me how we are. He's finding bugs.
Potuz:There are some issues with blobs now, which I think they're fixed. There were some peering issues, but those peering issues would not happen on a DevNet.
Potuz:On a large lab net.
Potuz:I think we're good to… to launch.
Potuz:Whenever you guys want.
Barnabas:Right, so Prysm is almost ready, including all the PTC changes that we have been talking about in the past weeks.
Barnabas:If…
Barnabas:You're listening and you're a CL client team, please push your changes into EPP as DevNet1 branch, and ping me when you're ready. Then we will be spinning up, DevNet1 basically as soon as possible, once Prysm is confirmed to be working.
Barnabas:And then other clients can test their syncing capability, the checkpoint sync as well.
Barnabas:But yeah, it would be good to hear from, the other client teams as well.
Barnabas:I'm not sure if we have anyone else,
Barnabas:Nicole that is working on, PBS.
Eitan Seri-Levi:For Lighthouse, I think we could be ready this week. We're merging the Alpha 4 spec changes, to our trunk bench tomorrow.
Eitan Seri-Levi:We don't have Checkpoint Sync yet.
Eitan Seri-Levi:I think we have everything else.
Eitan Seri-Levi:So maybe we can participate.
Eitan Seri-Levi:And DevNet1 at Genesis, and…
Eitan Seri-Levi:I think Checkpoint Sync would probably be ready by the end of the week, or early next week.
Barnabas:Yeah, that sounds good. Can you let me know when,
Barnabas:It's either in trunk or in a feature branch, and then I can start testing with Prysm.
Eitan Seri-Levi:Yeah, I'll spin up a DevNet1 branch for you.
Barnabas:Okay, thanks.
Barnabas:Yep, photos.
Potuz:Yeah, I would feel better if we actually make checkpoint sync mandatory for this DevNet, or range sync, but then heavily tested on the server side for every participating client.
Potuz:Because if Lighthouse, or if Prysm fails,
Potuz:and then we can't checkpoint sync, or if Lighthouse fails, then we can't checkpoint sync, and then Lighthouse starts range syncing, and then Prysm is sending non-canonical payloads, and these kind of things, we're gonna be screwed quickly.
Potuz:So, I really think we should aim to have Checkpoint Sync on all participating clients before they launch, at least at the time they launch.
Barnabas:I mean.
Potuz:What did you?
Potuz:It was just a couple of lines on Prysm, so I'm surprised that this would take a long time in Lighthouse. For us, it was… after we had range syncing, it was just, like, 5 lines to add checkpoint sync.
Barnabas:They don't have range thinking either, I think, right?
Eitan Seri-Levi:Yeah, we don't have rain sync, we just… we've been dealing with a lot of,
Eitan Seri-Levi:other bugs, like, on our P2P, so most of the team's been, like, doing that, so we've just been kind of a skeleton crew for EPBS the last, like, 3 weeks, but
Eitan Seri-Levi:But yeah, I don't think it's too big of a change, so hopefully end of this week or early next week should be right.
Barnabas:I think if you can be ready by Genesis, and I can test interrupt, then that is gonna be just as valuable as having checkpointing working. And then if you can push for end-of-the-week checkpointing capabilities, that would be very good. You can test it on the running.net already.
Barnabas:Okay, thank you. Anyone else? We have an update for us?
Caleb:Yes.
Nico Flaig:Sorry, go ahead, Caleb.
Caleb:Okay, so for Nimbus, we are currently upgrading to Alpha 4.
Caleb:I reckon it should be done by the end of the week, so should be good to go by Thursday, Friday.
Barnabas:Okay, and do you have Checkpoint Sync?
Caleb:Yes, we do have checkpoints in case.
Barnabas:Okay, thank you.
Nico Flaig:Yeah, it's similar for Lodestar. We should have something end of the week. Just one question, do we plan to do blobs as well?
Nico Flaig:Or is it still out of scope?
Barnabas:Yeah, so blobs would be… Yeah, it's up to you guys, really.
Potuz:I think it should be in scope for the DevNet, but we can easily agree not to send them at the beginning, because anyways, it's not a hard fork. So we just agree not to send them at the beginning, and whenever client signals we're ready, we just start sending them.
Barnabas:Yeah, that sounds good.
Barnabas:Yeah, maybe we can do that a week from now, or something like that.
Barnabas:Okay, that's good. So, let's aim to launch, APBSN at 1, maybe tomorrow?
Barnabas:And, regarding EPBS.NET2, I don't think there will be a need for EPBS.NET2. I don't expect any drastic, spec changes anymore on EPBS, luckily, so I think what we could do is actually discuss, Glamsterdam.net 0.
Barnabas:Maybe we can start talking about target dates also for that?
Barnabas:My initial proposal would be the 15th of April. I know that that sounds like a stretch, but that will give us maybe a fallback date for the 22nd of April.
Barnabas:the 22nd should really be the last day, when we launch, Glamsterdam M.0, because ideally we want to have a very stable,
Barnabas:merge DevNet before we head out to interrupt.
Barnabas:In the end of this month.
Barnabas:And regarding spec-wise changes, bold.NET3 and APPS.NET1 would be merged in the EI and CS side. I don't expect to include any new EIPs. What we really want to do is just have a stable testing environment.
Barnabas:So, whatever is on, DPBL.NET1, and whatever is on ball.net 3 is, should be the target for Glamsterdam DevNet 0.
Barnabas:Yep, Bluetooth.
Potuz:I'm not sure how stable of an environment you want to have for glam.devNet Zero, but I think it'll be a mistake to merge valves with EPBS.
Potuz:before we've tested external builders, I think definite one, we're going to be testing external builders, but I do think that we want to have the builder API tested in isolation on APBS.
Barnabas:I mean, but that's still, like, 3 weeks away, so, like, there's not one, if it will come online tomorrow, we will have, like, 3 weeks to test that, so…
Barnabas:I don't expect that to be an issue.
Barnabas:And also, DevNet1 can, like, run along, Glamsterdam and DevNet0, so if you want to do, like, very specific EPVS.
Potuz:Yeah, no, I think it's absolutely fine, as long as the builder API does not come with Hartford changes.
Potuz:I mean, if the same spec is supported on DevNet1 done on the builder API, like, meaning contacting
Potuz:builders directly over HTTP,
Potuz:then… then we're fine. If we need to make any changes that are hard for changes for those, then I'd suspect that we'll need a DevNet 2.
Barnabas:Maybe Bharat can comment on that? I haven't been on…
Barnabas:I'll update you on the latest Bikini API discussions, so…
Bharath:Yeah, sure, sure, sure, I can take that. I'm not sure what you mean by a hard fork change, so, the… I have updated the latest spec, I think it should be, like, fully updated so far.
Bharath:I mean, it dev… I think,
Bharath:The new Builder API will involve, like, new APIs.
Bharath:But I don't… I don't ex…
Bharath:I mean, can take us offline, but it'll involve new APIs, we'll probably not have validated registrations anymore, we'll use proposal preferences.
Bharath:And, there will be, like, builder preferences to, like.
Bharath:indicate, like, the max trusted bid. So, yeah, I guess that'll be a, like, hard fork change. I think it makes sense to test that in isolation, but on the other hand, also, like.
Bharath:The builder API is only dealing with, like, consensus data structures, like the bid and the envelope. So, I think bars will anyways be encapsulated, like, in the
Bharath:bidding in the envelope, so… With or without bars, the builder API won't change, with either of them.
Bharath:So, that's one thing. But, yeah, outside that, I do agree that it makes sense to test the Builder API in isolation, because
Bharath:Yeah, I mean, with Balt, I don't know how the builder will
Bharath:break, like, so we are implementing an in-house, builder, an external builder. I don't know how that will impact that, I hope it doesn't. But I think I agree with Potus, like,
Bharath:isolated, like, environment for that makes a lot of sense. And then maybe you can integrate with Balls, yeah.
Barnabas:Yeah, so, like, my target would be for the first half of April to do this, and figure out what kind of spec we want.
Barnabas:And, basically make any kind of bacon API changes for Gamsterium.0.
Barnabas:I don't know if that's realistic.
Barnabas:Has any planning teams, taken a look at what it would be to merge these two,
Barnabas:Feature branches?
Barnabas:Like, the ball side and EPPS side.
Barnabas:Do we expect that to be a… Difficult problem.
Barnabas:Yep, Daniel.
Daniel Lehrner (Besu):I think you mentioned in the past that there is a little spec change that the ELs need to do, no? That they can, like, reorg to the parent…
Daniel Lehrner (Besu):Of the current head, or something like this.
Daniel Lehrner (Besu):for, for, for EPBS.
Barnabas:Yeah,
Barnabas:I think, Marius did a change on the gas side, and maybe Portus can comment on it.
Potuz:Yes, there is currently a line on the… on the engine API that says that if you receive, payload attributes for a four-choice update, for a previous head that is canonical.
Potuz:you, you can…
Potuz:You may trigger execution, and you may trigger a Fortress update. That may need to become a must.
Potuz:Namely, if I send you a four-choice update.
Potuz:For a block that you consider canonical and it's not a tip on your chain, it still may become the head.
Daniel Lehrner (Besu):Okay, but this, this is the only change, I think, no, that you need.
Daniel Lehrner (Besu):From… from the yields.
Potuz:You mean on the ELs? Yeah, so from… uniquely from EPBS.
Daniel Lehrner (Besu):Yup, yeah, yeah, yeah, yeah.
Potuz:Yes, that's correct.
Daniel Lehrner (Besu):Okay, okay, then, then it should not be a big problem.
Daniel Lehrner (Besu):At least for us, because we have all the…
Daniel Lehrner (Besu):The bar changes in our release branch. So we just need to…
Daniel Lehrner (Besu):We just need to modify this.
Daniel Lehrner (Besu):But I think it's not a big problem.
Barnabas:Okay, thank you.
Barnabas:So it looks like Nethermind… for Nethermind, it would also not be a big problem.
Barnabas:Make it to you.
Barnabas:And yeah, so EPBS DevNet1 will have Alpha 4 consensus spec alpha 4 as the target.
Barnabas:Yeah, that… that was the… the general idea to basically try to aim for Glamsterdam does not
Barnabas:zero by the end, the second half of April.
Barnabas:That's assuming that, you know, Paul.3 will go smoothly next week.
Barnabas:And that APPI71 will also go smoothly this week and the following week.
Barnabas:And other than that, I saw that Bharat also has two PRs that he would like to raise.
Barnabas:Third?
Bharath:Yeah, I can talk. So, we're working on building, like, the external P2P builder, and also, like, the builder will implement the builder API. For that,
Bharath:there are, like, two things that would make life, like, super easy. One thing is this PR, which…
Bharath:is basically, related to proposal preferences. Like, it involves, like, an SSE event.
Bharath:For the client to…
Bharath:Like, trying to, like, stream the proposal preference when it receives them, similar to, like, attestations.
Bharath:So that'll be, like, super useful in general, because as a builder, like, I want to listen to the preferences. Be very easy if, like…
Bharath:there is an SSE event for that. I think PRISM… James from PRISM has seen… has a draft PR with this, but yeah, I would love, like, clients to take a look. Nico, I think, raised that
Bharath:this PR should also involve, like, deprecation of two other APIs. I'll leave it up to client devs to
Bharath:work that out. I don't have a lot of context there.
Bharath:So… That is one thing. The second thing is,
Bharath:So, as a builder, like, when I'm building, like, payloads externally, like, if my bid gets selected in the block, I want to create an envelope to broadcast.
Bharath:I think the envelope involves a beacon-state transition, so,
Bharath:it's like… so it'll be nice if there's an API for the builder to, like.
Bharath:Send the beacon block route, the payload and the execution request, and get back an envelope from the… from the beacon node, which involves also, like, the late… the updated beacon state route.
Bharath:like, I would love if clients could take a look at this too, like, maybe erase the PR, like, but maybe there are some more parameters, like, or maybe, you know, you want, some, like, more updates on that, like, it would be great if clients could take a look,
Bharath:these two, like, PRs will probably make, like, building, like, the external builder, like, much easier. Like, otherwise, like, especially for creating the envelope, like, right now, I have to manually implement the state transition, which is not, like, very clean. So, yeah, like, please feel free to take a look when you feel.
Barnabas:Neither of these are hard fork-required changes, sir, right? Like, we could just add these on, DevNet1?
Bharath:Yeah, for DevNet one, yeah, they're not critical. They're just for… to make the life of, like, building, like, a builder easier with all these things.
Bharath:So, I don't think they're important for DevNet one, but it'd be great if clients can, like, review that and, like, take that and implement that, so…
Barnabas:I was still a bit confused, like, what kind of changes Bottus mentioned that would actually require.
Potuz:There are no changes now on the Builder API that requires a hard fork.
Potuz:When we start testing, this may appear.
Potuz:That's why I'm saying it's fine so far, we're aiming at DevNet1 for testing the external builder.
Potuz:But we might find ourselves in a situation
Potuz:Which is unforeseen, not many people have seen this builder API yet.
Potuz:We might find ourselves in a situation in which we may need a hard fork, and therefore a definite 2.
Barnabas:Okay.
Bharath:Yeah, these channels are also mainly to implement, like, a P2P builder tool. I'm not even looking.
Potuz:None of the changes that you have now require a hard fork at all, so it's absolutely fine right now.
Bharath:Yeah, and just to be clear, you're mentioning the APIs, right? Like.
Bharath:Or are you mentioning the Builder AP?
Potuz:Yes, by a hard fork, I mean something that would be consensus-breaking, so we would need a different spec. For example, if you need to change the structure of the bid, or if you need to change the structure of the payload envelope, then yes, we will need a new DevNet.
Bharath:Oh, yeah, no, no, no, the builder API, definitely, like, I think that's something, like, I don't want to do, like…
Bharath:I want to keep it, like… I want to make sure it uses the consensus data structures, and outside that, like, maybe the request auth and the builder preferences can stay with the builder specs, and they don't require, like, a hard focus.
Bharath:But yeah, I mean, we should definitely, like, not change these structures for the builder repair. At least we should not try to, so…
Barnabas:Okay. Is there any other, EPPS-related questions?
Barnabas:Are other discussion topics?
Bharath:I have one question, like, so I can also put it in the EPBS channel, but, like, now that,
Bharath:And recently, like, Nico has merged a PR and consensus specs to…
Bharath:also, like, broadcast the proposal preferences in the same epoch. So I just wanted to, like, understand, like, how the workflow will be. I think at the start of the epoch.
Bharath:I would assume a client is gonna broadcast the preferences for
Bharath:like, all the validators in the same epoch, and also in the next epoch. Basically, like, you look at the look ahead, and if a validator's in the current epoch, or in the next epoch, like, you make sure you broadcast for both cases, which is unlike before, where we were only broadcasting for the next epoch.
Bharath:So, just wanted to understand if that is, like, the way it will work.
Barnabas:Maybe Nicole?
Nico Flaig:So I think you would broadcast for the next epoch, only, and…
Nico Flaig:The current epoch would only be the case if you… if the node hasn't broadcast for that validator.
Nico Flaig:Because I just double-checked there's a gossip rule which basically says it's the first valid message, otherwise it's ignored.
Nico Flaig:I don't know, I guess nodes could just broadcast them again, but I think it's probably wasteful to do that.
Nico Flaig:So if your local node knows it already did it for the next epoch for that validator, I would think we are not gonna rebroadcast the same message again.
Bharath:Got it. So I… just to be clear, like, I think the happy case was gonna be, like, at the start of the epoch, you broadcast for the…
Bharath:Like, the validators of the next epoch, basically.
Nico Flaig:Yeah, exactly. And the other case is just, in case the node started up, then it will try to broadcast for the current and next, but otherwise, only next.
Bharath:Okay, sounds good, like, thank you.
Barnabas:Right. Is there any other questions?
Barnabas:In case not, Don also had a question.
Barnabas:Not sure if Den is around?
Barnabas:Regarding whether clients are using Frederick's security… Oh, April.
danceratopz:Yeah, hey, Barnabas, sorry, yeah,
danceratopz:It was just a quick question, really, whether, clients… client teams are available about
danceratopz:Aware, sorry, whether they're aware of this, thanks for dropping the link.
danceratopz:of this GitHub action, which was created from, Frederick Svantes from the, security team at the EF.
danceratopz:And I haven't used it myself. It just came up today in discussions because we've kind of realized that with
danceratopz:coding agents implementing more of our features in the specs and in clients as well.
danceratopz:We kind of need to up our game, really, and review, and perhaps this could potentially help us to, get better automated reviews on the specs that we're implementing, or the tests.
danceratopz:I hope we get to try this out ourselves in the testing team soon. We should integrate it in our stuff. And I don't think it's a silver bullet, but, it could… could help us.
danceratopz:As a follow-up, dragon from Ref, basically, also, Push that we could stop…
danceratopz:Trying to do, A deeper dive into the implementations of clients before we launch a DEFNet?
danceratopz:So the first step would be really to do a hardcore analysis of the specs against the Markdown… I'm sorry, the Python specs against the Markdown specs.
danceratopz:then also do a review of the tests, obviously. And once that's in place, that we're confident that the Python specs are in alignment with the Markdown specs.
danceratopz:then we should do, like, at least some kind of automated review of all the client implementations on a per-EIP basis.
danceratopz:Before going to a DevNet, in order to capture this kind of problem.
danceratopz:And I think this is basically the process that happens already, by the security team before
danceratopz:as we get very close to a hard fork, but I think it could really help, accelerate things and get things nailed down
danceratopz:on a DevNet basis as well. And…
danceratopz:With the tooling available today, we can automate quite a lot of this.
danceratopz:Anyway, sorry, it's a bit rambling and just a few thoughts, but it was mainly just to create awareness around this GitHub action and see if people were using it.
danceratopz:If anyone wants to step up and is using it, then please do chime in right now.
Barnabas:Thank you, Dan.
Barnabas:Yeah, I think we can… we can discuss it, maybe more on this call or offline.
Barnabas:I think it's related to the ER team, mainly, at this point.
Barnabas:Okay, does anybody else have anything else to raise?
Barnabas:Oh yeah, next week call. So next week, Monday, is, Easter Monday.
Barnabas:I know that probably a lot of you will be taking the day off,
Barnabas:We would be curious whether Anyone would be interested in having the call. The default will be canceling.
Barnabas:Yeah.
Barnabas:Chad has been saying that we're gonna be skipping it, so I think we should stick to that.
Barnabas:Right.
Barnabas:Then, I guess, 2 weeks from now, in the 13th of April, is the next, All Core Devs testing call.
Barnabas:Yeah, and as Marius mentioned, we can do an async update on Discord, if anyone else has anything to raise.
Barnabas:Between that and now.
Barnabas:Okay, thanks everyone for coming.
Potuz:Bye-bye.
Marius Van Der Wijden (M):Bye-bye.
Barnabas:Whatever.
Marius Van Der Wijden (M):Right?
jochem-brouwer:Thank you, bye-bye.
Chat Logs
00:05:14
Barnabas:https://github.com/ethereum/pm/issues/1988
00:06:29
Barnabas:https://github.com/ethereum/EIPs/pull/11452
00:08:08
Łukasz Rozmej:Nethermind has eth/70
00:08:28
Łukasz Rozmej:eth/71 is close but still in progress
00:09:28
Karim T. (matkt):Besu should has eth70 and 71
00:09:29
FLCL:let's activate eth/70 eth/71 if possible but support eth/69
00:11:28
Łukasz Rozmej:8037 is brutal
00:11:44
Barnabas:can we aim to hit 1st of April for devnet 3?
00:11:55
Łukasz Rozmej:I told you I hated this EIP :P
00:12:14
Łukasz Rozmej:Replying to "can we aim to hit 1s..."
April fools?
00:12:17
spencer-tb:https://hive.ethpandaops.io/#/group/bal
00:14:08
Barnabas:@Łukasz Rozmej is happy to work more on this I heard 😂
00:17:29
Karim T. (matkt):Replying to "can we aim to hit 1s..."
Restart only devnet 2 maybe just for the joke
00:17:58
Potuz:Replying to "can we aim to hit 1s..."
Is terence there?
00:26:01
Potuz:Replying to "can we aim to hit 1s..."
The current spec does not need a hard fork
00:28:24
Potuz:Replying to "can we aim to hit 1s..."
I briefly looked I think it’s easy on our side
00:28:39
Bharath:Replying to "can we aim to hit 1s..."
You mean the builder-api right?
00:28:49
Potuz:Replying to "can we aim to hit 1s..."
No, BALs
00:29:29
Bharath:Replying to "can we aim to hit 1s..."
Yeah I assume BALs should just be encapsulated fully in the bid and the envelope.
00:29:48
Łukasz Rozmej:This should work in current Nethermind master
00:29:57
Barnabas:For this devnet we are going to use:
engine_forkchoiceUpdatedV3
engine_newPayloadV5
engine_getPayloadV5
00:30:23
Łukasz Rozmej:Replying to "This should work in ..."
and soon released 1.37 (aiming for this week)
00:31:44
Bharath:https://github.com/ethereum/beacon-APIs/pull/593
00:32:41
Bharath:https://github.com/ethereum/beacon-APIs/pull/584
00:34:27
Barnabas:stay optimistic potuz
00:38:42
Barnabas:https://github.com/marketplace/actions/ethereum-security-reviewer
00:38:54
danceratopz:https://github.com/marketplace/actions/ethereum-security-reviewer
00:42:04
Mario Vega:Next weeks call?
00:42:27
Marius Van Der Wijden (M):Skip
00:42:33
jochem-brouwer:skip
00:42:50
Marius Van Der Wijden (M):Can we do async update thread in discord
00:43:13
Potuz:Go devnet 1!
Summary
19 highlights
· 5 decisions · 4 action itemsExperimental
Summary
19 highlights · 5 decisions · 4 action itemsExperimentalfork status and schedule
- Blob DevNet Zero: Prysm and Lighthouse trunk-ready by end of April00:05:28
- 300K validators to run Prysm/Lighthouse with partial cells implementation00:05:48
- EIP-8136 (partial cells) proposed for inclusion in Glamsterdam00:06:37
- ETH/70 required for Glamsterdam if gas limit exceeds 80M00:07:22
- Glamsterdam DevNet 0 target: April 15 (fallback April 22)00:23:25
testing progress
epbs updates
glamsterdam planning
Decisions
- ETH/70 optional for Ball DevNet 3; not required without gas limit EIP00:09:12
- EPBS DevNet 1 launches tomorrow with Alpha 4 consensus spec00:17:29
- Glamsterdam DevNet 0 will not include new EIPs beyond Ball+EPBS merge00:24:12
- External builder API must be tested in isolation before Ball+EPBS merge00:26:55
- Next week's ACD Testing call (April 6) cancelled for Easter Monday00:42:10
Action Items
- All EL teams: Assign one person per client team to coordinate on EIP-803700:13:12
- CL teams (Lodestar, Teku, Grandine): Push EPBS DevNet 1 branches and ping Barnabas when ready00:18:54
- All CL teams: Review proposal preference SSE event PR (beacon-APIs #593)00:31:44
- All CL teams: Review envelope creation API PR (beacon-APIs #584)00:32:41