Mario Vega:Alright, welcome everyone to ACDT number 65. Today is January 12th, and this is the first ACDT on the… of the year, so Happy New Year, everyone.
Transcript
Mario Vega:And I want to share the agenda really quickly on the chat. Yeah.
Mario Vega:Alright, so I'll just get started. So, the first item in the agenda is the mainnet BPO that happened last week. I don't think there were any
Mario Vega:Issues, or…
Mario Vega:event… events that happened, but I just wanted to bring this up and see if anyone has anything, any comments regarding the BPO that happened last week in Maynet.
Mario Vega:Barnabas, I don't know, I see you online, I don't know if you want to share anything, or.
Barnabas:everything pretty much went as expected. I think we are good to go with, testing BPO string numbers.
Barnabas:But I think that's the next topic. Regarding BPO2, everything looks good now.
Mario Vega:Thanks. Anything from the clients that,
Mario Vega:Wants to be shared on this… On this call?
Mario Vega:Yep. Okay, so yeah, congrats everyone on this successful BPO2. I think we can just move on to BPO3. Do you want to…
Mario Vega:Start the discussion, Paramas, about, BP3.
Barnabas:Yeah, so BPO3, is gonna require us to basically implement,
Barnabas:GetBlobv V3, and partial cell messages on the CL side. This is something that we have work in progress. All the ELs have a Get BlobV3, implemented already in their trunk branches, and that is what we're gonna be using to test the partial messages on the CL side.
Barnabas:We currently have Lighthouse and Prysm interoping on a local critical setup, but we are expecting to launch a DevNet
Barnabas:Where we can, test this, publicly.
Barnabas:We also have a few more metrics that we want to include regarding the Get BlockV3 metrics. We have a PR for that, and the Beacon metrics report.
Barnabas:Interested up.
Barnabas:So, once this is added, then we can actually start the DevNet, because there's no point of running the DevNet without, being able to verify that things are working.
Barnabas:If you have additional ideas, what kind of metrics you would like to see,
Barnabas:Maybe just comment to this PR, and
Barnabas:Let's see if we can add that as well.
Mario Vega:Sounds good.
Barnabas:that's about it. Regarding timelines, I'm not sure if we can already discuss that. I think we should go through the whole process of testing it and making sure everything is working before we can discuss specific timelines.
Mario Vega:For sure. Anything that you need from the clients at this point?
Mario Vega:Other than input?
Barnabas:Yeah, they need to implement the partial messages on the CR side, which is quite a big change. And also adding volumetrics that is listed on this PR.
Mario Vega:Okay, so just to recap, Lighthouse, and what's the other client that has already implemented this?
Barnabas:Prysm.
Mario Vega:Awesome, okay, alright, so yeah, for the rest of the clients,
Mario Vega:please, reach out. Where are we coordinating this? Is R&D Discord, or…
Mario Vega:Anywhere else?
Barnabas:I'll roll me the Telegram group.
Barnabas:for some reason, it's in a random telegram group in Southern R&D. But yeah, you can reach out to me, or to Raul, from the P2P team, and
Barnabas:Yeah, if you're not included in the integral group, then we can add you.
Mario Vega:Sounds good. Okay.
Mario Vega:Yes, okay.
Mario Vega:Thanks, thanks for this input.
Mario Vega:Any comments on the client… from the client teams, regarding BP03? Is everything clear?
Mario Vega:Regarding the next steps…
Mario Vega:Any blockers, or…
Mario Vega:General comments about… about it?
Barnabas:I personally don't think it's super urgent, by the way.
Barnabas:Dude.
Mario Vega:for BP03. Okay.
Barnabas:Yeah, our blob usage is,
Barnabas:Not… not even near target, so… I think that's time.
Mario Vega:Perfect. Okay, that's good, sounds reasonable. Alright. Yeah, just to recap, if anyone needs help with PPO3, although not urgent, please reach out to Barnabas, and…
Mario Vega:And he can help you out to do coordinate.
Mario Vega:Alright.
Mario Vega:Cool.
Mario Vega:Just single comment, yeah, I think, from Lukash is if we want to wait for BPO3 until the demand increases, and yeah, I, I think this is, this is general.
Mario Vega:sentiment, from what I can see.
Barnabas:Yeah, so I don't think we need to, like, wait. If this is ready and good to be rolled out, then I think we should just roll it out, because it's a significantly more, efficient algorithm.
Barnabas:Using the partial cell request. So, like, it would help, basically reduce the bandwidth requirement for every single node operator on the network.
Barnabas:So…
Barnabas:We need proper testing. Once the testing is done, then we should just roll it out, whether or not,
Barnabas:we wait for BPO3, yeah, I'm not sure if we need to further increase the BPO number,
Barnabas:I, I think we can discuss that in Aqua Apps.
Barnabas:Maybe next week, or…
Barnabas:Maybe even two weeks from now.
Mario Vega:Yeah, Matthew?
Matthew Keil:The partial messages is a pretty big spec change, or at least implementation change, and I think we should see how that works on mainnet with mainnet traffic before we start to increase the blob.
Matthew Keil:Traffic, just to make sure that there's no edge cases that come up.
Matthew Keil:When we do actually hit mainnet.
Mario Vega:Yeah, to answer Justin's comment, I don't think there's a decision yet. Is this more of, like, a general question, or… I don't think we have numbers, if that's…
Mario Vega:Yeah, it's too excited. Okay.
Barnabas:Yeah, I think there's a business, we can figure out the PPO numbers, but it's… it hasn't been super urgent, and yeah, we need to have the implementation statistically working 100% of the time, and then we can start looking into which numbers would make sense.
Matthew Keil:Seems like a very prudent, prudent approach, is just make sure that the code that's going to be running has gotten some mainnet flexing of tests, you know, just to make sure it's good, and then the BPU number can probably go way up from there.
Mario Vega:Alright. Makes sense.
Mario Vega:All right, and we can continue this discussion on ACDC or ACDE this week or next, if clients have updates on the implementations.
Mario Vega:Alright.
Mario Vega:Good. Thanks. I think that's it for Fusaka, although, BPO3 can be considered maybe more of a lesserland topic at this point. But, yeah. Anyway, the next topic in the agenda is Glamsterdam.
Mario Vega:We're gonna start with, block-level access lists. I think there was an update, supposed to launch, be released this week for the tests.
Mario Vega:Other than that, I don't have any more info. Do we have anyone in the…
Mario Vega:In the call at the moment that has an update regarding block-level access list?
Stefan Starflinger:I could give a quick, update on the definite one.
Stefan Starflinger:But not on the testing, situation.
Stefan Starflinger:Currently, Definite One is, has been running over the holidays pretty, pretty decently. There were a few incidents where I had to spend some time, getting it, fixed, especially regarding syncing, so a lot of clients have,
Stefan Starflinger:released some patches regarding syncing up to the head, and that seems to be working pretty well. Only Reth hasn't had time yet to look into that, so most of the clients are working well. It would be nice if Reth could get up to speed here.
Stefan Starflinger:And Erica and I think they're also looking into getting their client syncing.
Stefan Starflinger:We're constantly spamming the network with EVM fuzzing and Uniswap transactions, but other than that, we also haven't expanded the testing too much yet. Beyond that, I've just been working a lot on getting all the tooling running smoothly.
Mario Vega:Thank you. Any comments from anyone from Breath or Erigon? Do you guys have any blockers, or…
Mario Vega:What's, what's the status?
Andrew Ashikhmin:So, on Erigon's side, our developer, who was our primary developer who was working on block access lists, was on holiday, so I think he's back from today. I need to catch up with him, but we should resume our bell progress soon.
Mario Vega:Thank you.
Mario Vega:Anywhere from Reth.
Mario Vega:on the call.
Mario Vega:Alright, if not, I think we should reach out async to the team to see what's the status on that.
Mario Vega:From the test side, I see Felipe on the call, do you want to chime in on the progress?
felipe:Yeah, yeah,
felipe:From the testing side, a few of the issues that we had on the DevNet were related to self-destruct, and there's a PR out to greatly increase the self-destruct test cases for bowels.
felipe:And I'm just waiting on this last PR.
felipe:have emerged.
felipe:to… Make a release, for the…
felipe:For the next test, bell tests.
felipe:Also, this next test release is going to have all of the old Ethereum tests that we have filled for Amsterdam, so it's going to include quite a lot more tests,
felipe:By its nature, it's just where we're gonna have all of those tests turned on.
felipe:I've already ran this against some of the clients.
felipe:that have, successful bowel implementations, that are passing all of the current tests.
felipe:And it looks like…
felipe:At least Nimbus passes all 39,000 tests, even with Ethereum tests turned on, so this is a good sign.
felipe:But yeah, we're gonna have…
felipe:significantly more tests in this next test release that I hope to get out, as soon as this PR is merged.
Mario Vega:Great, thank you.
Mario Vega:I also wanted to touch upon the topic of which EIPs should be included from Amsterdam in the next release after this one, but I will come back to that after EPVS.
Mario Vega:Alright, but on block-level access, is there anything else that we want to discuss today regarding block-level access list?
Mario Vega:Alright, if not, I think we can move into EPVS. Do we have anyone?
Mario Vega:That can give us an update on, the status of the EPVS implementations.
Justin Traglia:Yeah, I can. One second.
Justin Traglia:I just posted a… or sorry, I just shared a comment in the chat.
Justin Traglia:There have been two releases in 2026, primarily focused towards EPBS and COAS.
Justin Traglia:Alpha… sorry, V1.7.0, alpha0 is the, spec for DevNet… for EPBS DevNet 0.
Justin Traglia:There's a new Alpha.1 release, we can probably just bump the spec to that, doesn't really change anything.
Justin Traglia:This includes a lot of the changes that we talked about and agreed to last year.
Justin Traglia:Like, the big changes to builders, and some withdrawal refactoring, and stuff like that, and also proposer preferences, but that's not part of DevNet Zero.
Justin Traglia:I believe client teams are just working on implementing, all of those changes.
Justin Traglia:Yep.
Justin Traglia:Barnabas says, we should aim for Alpha 1 release for the DevNet, otherwise everyone will have to implement a broken Phase 0 changes.
Justin Traglia:Yeah, sure. And there's also, like, a new issue with, Alpha 1, actually. We probably should have implemented the withdrawals fix in Coloss.
Justin Traglia:I opened a new discussion on that on Discord. That's the, I guess, the third link in my comment.
Justin Traglia:Let's chat about that more there.
Justin Traglia:And there are still some open PRs that need to be reviewed and, either closed or merged, so please take some time to review those when we have a chance.
Barnabas:As we basically get rid of the PBS breakout rooms, I think this would be the place to discuss those PRs.
Justin Traglia:Okay.
Barnabas:Do you want to run through them, Justin? Sorry, I don't want to hijack the call, Mario.
Justin Traglia:Firefighter, I'm not super prepared to share my screen or anything. Mario, would you like to?
Mario Vega:Yes, no problem. So which PR should we start with?
Justin Traglia:We can start with the first PR in the list.
Mario Vega:I'm looking at it, it's the…
Justin Traglia:Add is higher value bid helper for bid forwarding.
Justin Traglia:threshold. It's sort of like a DOS prevention,
Justin Traglia:I haven't responded to Maribos' comment yet, but
Justin Traglia:Essentially, we can add a percentage increase minimum for new bids. So, like,
Justin Traglia:Yeah. In order to forward a bid, you have to receive one that's, like, 1-3% higher than the previous highest bid.
Justin Traglia:It sort of prevents the total number of messages that can be propagated.
Justin Traglia:That way, it's not like… One GUI increase every single time.
Mario Vega:I also cannot share screen. Can someone help out to share DPRs on screen, please?
Justin Traglia:I can probably do it.
Justin Traglia:Just, enable this setting, though. Okay, maybe I can't do it.
Justin Traglia:I would have to rejoin in order to share my screen.
Justin Traglia:Perfect. Thank you.
Justin Traglia:Yeah, that's the one.
Justin Traglia:So, if we were to define a 1% percentage increase, there could be, like, 2,000 messages to reach 1 ETH, which I think is, like, a good maximum.
Justin Traglia:If we were to do this, I might suggest, like, a 3% increase, just, like, as the middle of the road.
Justin Traglia:Yeah.
Justin Traglia:what do client teams or other people feel about this? Barnabas had a
Justin Traglia:an interesting suggestion. Maybe you want to talk about that some, too?
Barnabas:Yeah, so my suggestion was that the fixed 3% might be a bit too rough, especially when the block prices are a bit higher.
Barnabas:So I would actually suggest that we introduce a floor, so a minimum increase, so when the, book value is very low, then,
Barnabas:We would not wait for this 3%, but we would say that the minimum increase we want to do is something like 0.0001 ETH.
Barnabas:And we would also have a cap.
Barnabas:So, when we reach, like, 0.5 ETH,
Barnabas:then we will use a cap value of, like, 0.01 ETH.
Barnabas:And that way, the min, min floor plus the max cap,
Barnabas:Values would lower the total number of, spam transactions,
Barnabas:To, like, 500 to 256, 1 to 3%.
Justin Traglia:That sounds reasonable to me.
Justin Traglia:How do other, people feel about this PR?
Justin Traglia:Just, like, in general.
Mario Vega:Have client teams, had a chance to, check this review? See, Boros, please go ahead.
Potuz:Yeah, so…
Potuz:I mean, I don't oppose this PR, and I certainly think that clients should implement a version of this. Percentage, minimum, whatever it is to prevent the OS.
Potuz:I just want to call out that this is not enforceable in any way, so this is a P2P specification that we cannot downscore peers for sending us bids that are of low value, because that might be the highest value they have seen. We can probably downscore peers that send us,
Potuz:a bid with a lower value that they themselves have sent us before, but that's going to be hard to keep track. That's gonna,
Potuz:I mean, that has to be specified, and we will have to, like, keep track of what each peer sent us before, and so forth.
Potuz:In order to be actually enforceable in a way.
Potuz:And so, if we are not going to enforce downscoring of peers on this topic.
Potuz:I would suggest that these things are not really specified at all, and just allow clients to implement this.
Potuz:Instead of, like, having to have a more complex
Potuz:spec. I tend to lean into having
Potuz:smaller specification… less specification on things that cannot be enforced, and we just agreed that we have good defaults. But I don't mind if this is merged. We are going to implement this anyways.
Potuz:If people believe that it's good to have this specified, that's fine.
Justin Traglia:Yeah, you're completely right. If other client teams, agree with just closing the PR, we can close it.
Mario Vega:Any comments from other GLAN teams on this call?
Enrico Del Fante (tbenr):1… So, I agree with Bottus,
Enrico Del Fante (tbenr):Partially. I think, like, if someone wants to go to the complicated path to actually implement something…
Enrico Del Fante (tbenr):Maybe we should have a common rule that says this is… not…
Enrico Del Fante (tbenr):Valid, and based on that, you don't score?
Enrico Del Fante (tbenr):So, the complicated is… the complicated implementation would be actually tracking what has been sent by each peer, and then you take a decision. If you don't have these details, maybe you don't… you close the door
Enrico Del Fante (tbenr):To… to implement any… any downscore at all, because we don't have any, anything.
Enrico Del Fante (tbenr):I don't always make sense.
Enrico Del Fante (tbenr):So I'm actually in favor of something like that, having it good, good specs.
Enrico Del Fante (tbenr):Maybe not super detailed, but the… Overall limits that are,
Enrico Del Fante (tbenr):acceptable, and then based on that, we can potentially then score if clients want to implement.
Justin Traglia:We could just add a paragraph stating that clients May or should,
Justin Traglia:Implement something like this, but not actually define what it is.
Enrico Del Fante (tbenr):Yeah, but we need to have a common limit.
Enrico Del Fante (tbenr):That… that's my point, that's my point. So you… if you'.
Justin Traglia:Don't ask me.
Enrico Del Fante (tbenr):Saying… I don't agree.
Justin Traglia:We actually need a common limit.
Justin Traglia:I mean, client teams could do whatever they want here, like Proto said, it's not.
Potuz:No, no, no, no, I think what Enrico's saying is that if we are going to downscore, for example, because you sent me a bid, and then you sent me another bid that was only, like, a fraction more, higher than the previous one, then I will downscore you. If we are going to have something like this, I mean, if there's going to be enforcement of this kind of rules.
Potuz:Then we need to specify it, because then… then we actually need to have a hard value, that if you send me
Potuz:lower than this, I will downscore you, and you will be isolated.
Justin Traglia:Oh, I see. I agree with Enrico.
Enrico Del Fante (tbenr):Yeah, we need to have consistent behavior among clients if we want to have something like that. That's my take.
Potuz:I didn't… I don't think we are, I don't really think we are going to,
Potuz:To… to be implementing something like this.
Potuz:So I'm not… I'm not really sure. -
Potuz:Perhaps we should kick this scan for down the road, because…
Potuz:It might be complicated to implement this.
Enrico Del Fante (tbenr):Yeah, the full down score for sure.
Enrico Del Fante (tbenr):But… Oh, yeah.
Justin Traglia:Okay. Yeah, let's just kick it down the road.
Justin Traglia:Next PR, please.
Justin Traglia:And Potus, this is yours. Would you like to talk about it?
Potuz:Oh, this is a bug fix, but at the same time, it allows us to… to have builders, some set of builders, right at the fork. The issues that on the PR that we opened, that
Potuz:that,
Potuz:makes builders a different slides that are not validators, so their stake is not validating in any way. In that PR, we dealt with deposits in a very special way. So we… when you get a deposit request.
Potuz:For a builder address, so that's a builder that starts with the withdrawal, address starts with 003.
Potuz:Then, if there's no validator with that withdrawal address, we onboard that builder immediately. We fulfill that deposit immediately.
Potuz:If there was a validator with that address, then it goes through the standard process of, like, putting a queue and then adding to that validator.
Potuz:Now, the problem is, what happens to those deposit requests?
Potuz:That, that are included right before the fork.
Potuz:So if you deposit for a 003 validator right before the fork, it will go through the standard pipeline, and you… it will put a pending deposit, because deposits for validators are only processed after finalization.
Potuz:So, we will put a pending deposit for that validator in the… in the queue. And if you depo… if you…
Potuz:Add a deposit request right at the fork for a builder, the same withdrawal address, then it would process it as a builder immediately, and then later on, when we process after finalization, we process the pending deposit, we will have both a builder and a validator with the same public key, and that's a problem.
Potuz:So, in order to fix this, what I propose is something that I believe is, safe and easy.
Potuz:But it needs to be validated by other clients, which is, at the fork, look through the pending queue.
Potuz:Of validators, and if there's any pending, deposit for a 003 validator that is new, just onboard it as a builder.
Potuz:Immediately at the fork. So transform any 003 deposit for a validator that is not yet included as a validator, then immediately process that deposit as a builder, remove from the pending queue, and then you have builders at the fork.
Potuz:This… if this works, then it also solves the problem of not having builders at the fork, because builders can send these deposits in the last epoch before the…
Potuz:Before the fork, so if they get included right before the fork in the last… during the last epoch, they will be already active and with balance in one slot after the fork.
Justin Traglia:And then, to be clear,
Justin Traglia:builders wouldn't be able to submit a peer-to-peer, like, P2P bids, until the next seed block after the fork, still. But you're saying that's still okay?
Potuz:Yeah, so for… so that's… that's right. So the P2P, bidding, I don't think it's something critical, but it does seem that it's critical that we have the standard builders, that are already trusted.
Potuz:to… to be able to build immediately at the fork, otherwise applications like Gaoswap might start falling.
Justin Traglia:Okay.
Justin Traglia:Yeah, that, PR makes sense to me. Do other client teams have opinions on it before moving on?
Potuz:I just want to quick… quickly add something onto your comment. Builders will be able to submit P2P bids, I think. The only problem is that they won't have the preferences.
Potuz:But bids, I believe, will be propagated, and the proposer might want to take them if…
Potuz:If they agree with their view. Like, if my node, for example, would have
Potuz:a preference that is very simple to see. If you send me, for my fee recipient D my withdrawal address, then I'll take that bid.
Justin Traglia:Okay, but I mean, the… Proposer preferences, gossip topic, checks.
Justin Traglia:do require the proposer preferences. Like, you won't forward preferences.
Justin Traglia:If you don't know that it's correct, or wrong. I'm not saying it properly.
Potuz:Also, we're tying, like, bid forwarding to, satisfying the preferences from the proposer.
Justin Traglia:Yes, I think we are. At the moment.
Potuz:that's… That might be bug prone. I hadn't noticed this.
Justin Traglia:Aye.
Potuz:I would make those two topics be independent.
Potuz:So you're thinking that it's a good way of, like, preventing DOS?
Justin Traglia:I mean, yes, but also just making sure that the bid you get is actually what you want.
Justin Traglia:It's for the correct fee recipient and gas limit.
Potuz:Yeah, yeah, so the proposal.
Justin Traglia:someone else's.
Potuz:proposer would do this, right? So the proposer would do that filtering for sure. What is not clear to me is that if other validators should be doing that filtering, because… I mean, it's fine if they do, but
Potuz:It seems to me that these are two independent
Potuz:two independent message propagations. What is the…
Justin Traglia:I mean, what if you just forward a really high bid for the wrong fee recipient?
Justin Traglia:And…
Justin Traglia:the, like, the one that you eventually get will be incorrect. Or, like, you won't be able to accept it anyway.
Justin Traglia:Because you're only gonna forward the highest bid, correct?
Potuz:Yeah, well… Yes, and yeah, I believe so.
Potuz:Because you could just send it to your.
Justin Traglia:an attack.
Potuz:And then… then it doesn't… it doesn't, yeah, it doesn't cost you anything. You… you just set your fee recipient to be yourself.
Potuz:Yeah. Yeah, that's right.
Mario Vega:And Justin Potos, can we move on to the next PR, just for the sake of time? We are…
Mario Vega:Already spent a lot of time on this… on this PR.
Justin Traglia:Oh yeah, of course, sorry.
Justin Traglia:This is a simple PR with just, it,
Justin Traglia:Sorry, refactors a paragraph saying that…
Justin Traglia:Validators no longer have to broadcast.
Justin Traglia:Or something like that, I don't recall. Barath, are you here?
Bharath:Yep, sorry, I didn't know you brought it up.
Bharath:But, no, I mean, the last time I was reading the consensus specs, like.
Bharath:We weren't, like, setting, sorry, we were in… wait, let me… The silly ones.
Bharath:Yeah, I think we weren't, like, setting the, so I think…
Bharath:when a validator, like, self-builds, like, I think they have to broadcast the…
Bharath:blobs to it. So, I mean, based on the self-building case, I think we weren't, like, clarifying that
Bharath:Actually, could I take this offhand? Because, like, it's been a while since I've also lost context of this.
Bharath:I'm sorry, sorry about that, Doug.
Justin Traglia:Yeah, that's fine.
Justin Traglia:I think we should also discuss the next one offline as well.
Justin Traglia:Like, it's pretty complicated, and I… I definitely wouldn't be able to explain it in the next 3 minutes.
Mario Vega:Sounds good.
Mario Vega:Thank you. Alright, do we have a breakout for this, for the remaining OpenPRs, happening soon, or…
Mario Vega:Should we just do this async, and wait until the next ACDT?
Justin Traglia:I would prefer not to have a breakout call.
Justin Traglia:I enjoyed not having that responsibility.
Justin Traglia:So I would vote for async.
Mario Vega:Sounds good.
Mario Vega:Okay.
Mario Vega:Great. Thanks for,
Mario Vega:explain these PRs, and yeah, let's move to async, and yeah, I think this is basically the main blocker for DevNet, for EPBS, if I understand correctly. Yeah, Patus?
Potuz:So, I don't know about the clients, the main blocker for us is that we need to have a freeze. If it's not on the spec, at least we need to have a freeze on the structures.
Potuz:We don't want to have any more container changes, because that actually frozes our being able to merge and to develop.
Potuz:And this is the only reason we are not merging PRs into develop, is because the structures themselves are in flux. So it would be nice to get into a situation in which we can actually freeze that, and if this is going to be the call that we are going to be making this decision, then we should really take the time and make these decisions here.
Barnabas:Why can't we use alpha 1?
Potuz:It's not clear if the structures are going to be changing or not.
Mario Vega:But is it a problem if we start with alpha 1 and then modify the structures? What's the problem that you're envisioning?
Potuz:No, it's not a problem, that if we decide to, like, to move the balances away from the builder and just having a normal slice for balances, then that actually is a big change for us.
Potuz:I mean, the PR that we merged to make builders not validators was merged just a couple of weeks ago, and that is a very large PR.
Potuz:So if we keep having these sort of, like, big changes.
Potuz:Then… this is really a blocker for… releasing…
Potuz:I think Alpha 1 looks good to me. It's just that it's not really clear to me that the structures are frozen.
Justin Traglia:I don't think.
Barnabas:Which I do…
Justin Traglia:I guarantee they're frozen. But.
Barnabas:Which other PR is changing the structure? Is it the onboarding builders from pending deposits?
Justin Traglia:I mean, it's just, like, the thing that Potus just mentioned. Like, we may want to move builder balances into a separate
Justin Traglia:State field.
Barnabas:Right, but, like, that could be the scope of, like, DevNet3 or whatever. Like, I don't think we should be focusing on that, like, we can discuss it, I think, if we actually want to do that or not, but…
Barnabas:I… I would just want to have a DevNet up and running with the current spec.
Barnabas:And iterates from there.
Barnabas:Because we've been trying to launch 11 since October.
Justin Traglia:Yeah, I agree.
Justin Traglia:We just need to get a definite.
Potuz:Yeah, the problem, Barnabas, is also the other way around.
Potuz:if we do find changes… we could have frozen a couple of releases ago when the builders were validators, because anyways, the DevNet doesn't have external builders.
Potuz:We agreed on that, too.
Potuz:But the problem is that if we do something like that, and we freeze on one release, then we can't really release anything new on the specs, because
Potuz:Whenever there's a new spec test, a new spec release, then we need to Satisfied those spec tests.
Potuz:So, as soon as we freeze for the next DevNet, we cannot merge anything on the consensus layer spec.
Potuz:That changes any structure, for example, because otherwise we will just start failing test vectors.
Barnabas:For, like, 2 weeks. Like, if we do a two-week, test cycle, and we say that the next change will come in in 2 weeks.
Barnabas:Yeah, for two weeks, we would need to…
Potuz:way, we're gonna have a DevNet in two weeks. That's just not gonna happen.
Justin Traglia:I think he was saying to have a two-week cycle, so, like, after we get DevNet 0 up, then we could have DevNet 1, 2,
Justin Traglia:Weeks after.
Potuz:Yes, but then… but up to that point, up… so, if we freeze now on Alpha 1,
Potuz:And let's say that we have a DevNet ready in a few weeks from now, until we are actually testing on DevNet, we cannot have any new release on the consistent spec.
Marius van der Wijden:Why?
Marius van der Wijden:Because…
Potuz:because we take it in a trustless manner, what are the spec vectors, the test spec vectors? So we take it from the release, we grab the spec test vectors, and we just pass specs like that on our main branch.
Potuz:So, if.
Marius van der Wijden:Yeah, just…
Potuz:structure changes.
Potuz:We will…
Marius van der Wijden:you could just mock them out, right? Like, you can just specify a different branch, or a different release, or…
Potuz:Yeah.
Marius van der Wijden:And then… Remote, where you get the test vectors from.
Potuz:It can be cased.
Potuz:But we really don't want to be casing on our production code, like, we are skipping these tests, or, like, passing these tests this way for this DevNet and this other production for the actual, mainnet release.
Potuz:So, we prefer if we…
Potuz:If, when we freeze, we prefer that the spec test vectors are actually what we're going to be testing.
Justin Traglia:Couldn't you just ignore the new spec release as well? I mean, like, the changes… the changes that we're making don't really affect.
Potuz:Like, Fusaka Mainnet right now.
Potuz:Well…
Potuz:It depends, right? So you had, for example, something that was pushed that changed the test vectors for phase 0.
Potuz:Like, if there's anything that changes the expected vectors for Fulu, then we really want to pass them.
Barnabas:I agree with that, but I don't think from alpha 1 to Alpha 2, we will change anything that's pre-gloss, and we shouldn't change pre-gloss stuff anymore.
Potuz:If that happens, then we're fine.
Potuz:I mean, if only new releases are only changing Gloas, We're… we're happy.
Justin Traglia:Okay. I mean, like, I want to be able to refactor and approve code, but as long as it doesn't change the spec test, is what you're saying.
Potuz:Yep.
Justin Traglia:Okay.
Mario Vega:Alright,
Mario Vega:Alright, yeah, and I think we have to timeboxes, and then move on to, EL AIP prioritization.
Mario Vega:Any last comments on the CL topic at the moment for EPBS? From other clients, mainly. I would like to hear thoughts on other clients.
Mario Vega:Alright, yeah, on the EL side, I shared a link… for the CF5,
Mario Vega:So far… the so far, CFI, EIBs.
Mario Vega:Which are this one. And my… the main thing that I want to… I would like to resolve on this call is for, for the specs and the spec tests to be on the same page, and basically, in lockstep with the client implementations. At the moment, we have, I think, if I,
Mario Vega:9 CFI EIPs?
Mario Vega:If I… if I understood correctly. So, what I would like to… for us to… to go over this…
Mario Vega:Skull is the EIPs that we want to implement first in the specs and tests, just for us to have a release.
Mario Vega:for the ELs, that works on top of log-level access lists.
Mario Vega:And my suggestion is,
Mario Vega:the… that we implement the first four CFI EIPs.
Mario Vega:For the next, next release, which is, 7-7… 7778?
Mario Vega:7708008?
Mario Vega:7843.
Mario Vega:and 80-24.
Mario Vega:So this is my, recommendation, but I would like to hear from clients if there is any client that already started implementing these EIPs, or any other CFI EIPs, that's what I want to hear.
Mario Vega:In the skull.
Mario Vega:Yes, these are EL-only changes, basically. So we can basically, in parallel, while EPVS is being ready for Devon0, we can start implementing this in tests, and make a release on the tests, just to make sure that we are ready for
Mario Vega:with something on top of log-level access list for DevNet, for the first DevNet.
Barnabas:Oh, we can also just target ball.net too, I think, with these on top of… as extra.
Barnabas:Because I don't think we can have a glance again, like, a combined GDPBS definite anytime soon.
Mario Vega:Yeah, that also makes sense. I think, as long as we keep moving on the EL side, while EPBS is being ready.
Mario Vega:I think that's, that's, that's a positive.
Barnabas:I think we can totally do, Ball.net 2, with these 4 EIPs included already, and then with Ball.net 3, for example, we would include 4 more.
Barnabas:And just keep moving forward like that.
Barnabas:as long as they are EL-only changes, I don't see much of a problem.
Mario Vega:Sounds good. Yeah. Any thoughts from the EL clients? Does this sound like a reasonable approach?
Mario Vega:Okay.
Mario Vega:Nethermind mentions that they already have Sultan, which is good, because that's one of the EIPs.
Mario Vega:And it's easy for a test to implement?
Mario Vega:Have other clients already started implementing any of the CFI EIPs for Glamsterlam?
Marius van der Wijden:We haven't yet.
Marius van der Wijden:But we will make a plan this weekend, implement everything.
Marius van der Wijden:As soon as possible.
Marius van der Wijden:Yeah, I guess it's easy to start with those, because they are very easily implementable and testable.
Mario Vega:Thank you. Any other ELs?
Mario Vega:Alright.
Mario Vega:Any oppositions, to these EIPs, being the first one implemented and released on the tests?
Mario Vega:I shared the link on the chat if anyone wants to take a look.
Mario Vega:Okay, so I think what we can start doing is, we'll start, implementing tests and specs for this.
Mario Vega:And try to make a release, but we will have updates on the next week. I think Yale clients should also provide an update on next week's ACDT.
Mario Vega:for the status of these EIBs,
Mario Vega:Yep, I think that's, that's everything from, for this topic. Any comments on this? Is this…
Mario Vega:And one comment from Marius is that E-Transfer 1 is the most complex, should we try to tackle first? Alright. Yeah, I agree.
Barnabas:When do we want to have the nut to?
Mario Vega:That's a good question. I… I was thinking that we… Should…
Mario Vega:Target the next couple of weeks, but what we can do is perhaps, query the status.
Mario Vega:in next call, next ACDT, and decide then.
Mario Vega:If, the specs and tests are
Mario Vega:or the EL client implementations are falling behind. By the next ACDT, I think we can,
Mario Vega:Give another week, and then, see how… how things are going.
Barnabas:Do we know what the timeline would be for the test, for these four EIPs?
Mario Vega:That's a good question. These are the simplest.
Mario Vega:Well, except for the,
Mario Vega:77008, that's the most complex one, but I think for the rest of the EIPs, it shouldn't be…
Mario Vega:That hard to start this week with implementation, yeah.
Mario Vega:Alright, any other comments?
Mario Vega:And, yeah, January 21… 21st, sorry, sounds like, a good deadline for Debna 2 of Blockload Access List.
Mario Vega:Cool. Any other comments on this?
Mario Vega:Or should we move on to the next topic?
Mario Vega:All right. Thank you.
Mario Vega:We have 3 other topics, the first one is the, Gas limit increase.
Mario Vega:The 80 milliga… Do we have anything, anyone that can shame in on the status of this?
Kamil Chodoła:Aye?
Kamil Chodoła:So yeah, I can chime in on that. So, basically, Martin from our team is analyzing the recent results, and we'll be reaching out to the teams.
Kamil Chodoła:We find updates, etc, to get information if we should make some improvements, in clients. And yeah, it's right now being finalized, so we'll share some updates rather soon.
Marcin Sobczak:Yes, and probably we would like to aim in 75 million, as a next step.
Marcin Sobczak:And I'm analyzing the data right now, and we'll share with client teams, probably not today, but should be ready tomorrow. And there are some client-specific bottlenecks. Yes, I will share it soon.
Mario Vega:And one comment, from Maris is that…
Mario Vega:75 million gases are not important at the moment.
Mario Vega:And we should focus on repricings.
Kamil Chodoła:Yeah, focus on the pricing piece is there. We are working on that in parallel.
Kamil Chodoła:But we are just checking in meantime if we can do anything before.
Kamil Chodoła:We know about if 70 and it needs to be implemented, but this unstucks anything above, 80.
Kamil Chodoła:So yeah, so that's why we are just analyzing the anxiety if we…
Kamil Chodoła:Can do something, or we should… we have a new bottlenecks which should be addressed before.
Marcin Sobczak:Yeah, and this, it's likely that, increasing to 75 will be, like,
Marcin Sobczak:low, low effort from all the clients, like, there will be probably some specific bottlenecks which would need to be addressed at some point anyway, to just be performance across client be similar.
Marcin Sobczak:And, yeah, that's the point.
Mario Vega:Alright, thanks. Marty and Camille, do you need anything from other EL clients at this point?
Kamil Chodoła:Are there any blockers for… Nothing in particular, just maybe some… if Martin came up with some interesting findings, then we'll reach out.
Marcin Sobczak:Yeah, we share on, on Telegram, on the gas limit testing channel, and, there will be probably some, some scenarios, like client-specific scenarios, to take a look.
Marcin Sobczak:So, like, like usual, when, when I'm sharing such, such analysis.
Mario Vega:Sounds good. Thank you. Yeah, I think… and also the next topic is also relevant to… to you, Marcin.
Mario Vega:Which is the WRPC endpoint, should we just jump into that?
Mario Vega:Psh, I share a link of the, of the PR.
Marcin Sobczak:Yeah, so, the spec, the spec in, like, in current form is, is ready, and, NetRoman implementation, implementation, is also, ready, but not tested, so,
Marcin Sobczak:is the point when we can try to, to use it, and, then if there would have some issues, then, I will fix it, but it was, like, before, Christmas break,
Marcin Sobczak:I implemented it and didn't have time for testing, and after the break, there were more urgent issues, so it's generally done, but under-tested.
Mario Vega:Alright.
Mario Vega:Thank you.
Mario Vega:I think on this call, I… do you need still some feedback, right, from the ELs on this endpoint, right?
Mario Vega:Or have the other EL clients already chimed in in your PR, or do you need some more feedback?
Marcin Sobczak:There is implementation from Nethermind and from RAF, and we had feedback from Bezo, and some discussion, and yeah, that's it.
Mario Vega:Sounds good. From the testing side, I think we can…
Mario Vega:help out, we can discuss this later on the,
Mario Vega:gas testing call, but I think we can provide help on the execute side. We can start seeing how we can implement this on the execute for ills.
Mario Vega:And help you with the testing and validation of this endpoint.
Mario Vega:Alright.
Marcin Sobczak:Yeah, it would be great to just start using it, and in case of any issues, I will fix it, and maybe we will find that, like, we need to modify it somehow, or, like, just to…
Marcin Sobczak:We need to track what will be the best shape of it to be as useful as possible.
Mario Vega:Alright, thank you.
Mario Vega:Perfect. Yeah, and jumping onto the last topic for today, we have, this PR.
Mario Vega:on the execution APs,
Mario Vega:Is there anyone here that has more context, or would like to add context to this?
Simsonraj Easvarasakthi:Yeah, hello. I can. Hey everyone, this is Simpson.
Simsonraj Easvarasakthi:So a while back, we started working on, standardizing JSON RPC error codes. This is mainly because
Simsonraj Easvarasakthi:The current error codes are not really meaningful.
Simsonraj Easvarasakthi:And, it's overlapping between different errors, which means we cannot rely on these error codes to
Simsonraj Easvarasakthi:Definitely mean one single thing.
Simsonraj Easvarasakthi:So we… we wanted to standardize AI. We presented this a while back. Since then, we've been working and, refining this in the RPC forum, in the RPC call, and, got some valuable input from.
Simsonraj Easvarasakthi:different client groups, and we refine this. So it is at a stage, where we can
Simsonraj Easvarasakthi:you know, exposed to the wider audience and get more feedback, get it ready to march. So that's the PR. Thanks for putting it in the chat. Please take a look at it.
Simsonraj Easvarasakthi:But I can walk through, this in, like, 2 minutes, quickly. So, the proposal itself is very simple. To get… to implement this proposal, we've been working with the OpenRPC Foundation, and, because of…
Simsonraj Easvarasakthi:There are extension specification, which is a new concept, allowing you to plug customized specification extensions, which we needed to utilize
Simsonraj Easvarasakthi:And implement, this particular proposal, so they helped us, define error group specification extension.
Simsonraj Easvarasakthi:With that, we are able to implement this proposal. If you look at the proposal, it's very simple. So, we pre-defined some error groups. Let's take gas errors or execution errors, for example. Actually, I can share my screen, if you don't mind.
Mario Vega:Yes, please, go ahead.
Mario Vega:Just to mention that we already have… only have 4 minutes, so…
Simsonraj Easvarasakthi:Yeah, I'll make you really quick. Yeah, thank you.
Simsonraj Easvarasakthi:So yeah, we have a couple of error groups predefined gas execution, transaction pool. These are initial, and this is only to cover the most
Simsonraj Easvarasakthi:famous ones, if I can say so, which are useful for cross-team clients and maybe wallet or users who rely on these to react.
Simsonraj Easvarasakthi:React in the sense, let's say, you get a nonce to low error. If you get an error code that's known for non-s to low error, they can react to it in a way, increasing the nonce, and so on and so forth. So you predefine some error ranges to each error group, and predefine the numbers for error… each error.
Simsonraj Easvarasakthi:If you go into the,
Simsonraj Easvarasakthi:The spec spec is very simple,
Simsonraj Easvarasakthi:Let's take gassers, and it says, let's take, maybe, transaction pool. You get a transaction already known as, let's say, 1000.
Simsonraj Easvarasakthi:These, these are defined along with the executioners, which is very famous. We have, executioner by revert opcode, which is still 3. We try to cover, keep it to a minimal change, where you don't have to change too many, but then,
Simsonraj Easvarasakthi:At least to cover the popular error groups. That is it. It's very simple. The only caveat here is I tried to implement a test that generalizes this for multiple clients. You can see the
Simsonraj Easvarasakthi:basic client get, and Netherland has already been covered, but it's not consistent in a way that you cannot reproduce these negative test cases for each… all these scenarios, all the error codes that I've written, to… to produce the same output, because all these clients don't…
Simsonraj Easvarasakthi:allow you to set the limits. For example, to get a, gas, or out of gas error, maybe GET has a…
Simsonraj Easvarasakthi:field that I can set to replicate this, but maybe not on Nethermind or BASO. And these tests can be extended to different clients, but we have some sort of test that actually helps validate how the current client behaves to replicate these negative scenarios.
Simsonraj Easvarasakthi:And, see how we can fix it. But as you see, minus 32,000 is across a lot of errors, and which doesn't mean we can rely on minus 32,000 to mean it's a gas tube, too low or, too high.
Simsonraj Easvarasakthi:So that's what we want to fix. I do think we have a good alignment within the RPC forum, but want to bring it to a wider audience and decide on the next steps. So if you…
Simsonraj Easvarasakthi:if you guys can take a look at it and agree, we can get this merged as soon as we can, and then start implementing the test on a proper form. I'll start right there for any feedback.
Mario Vega:Thank you. I think we are running out of time, but please, your clients, if you can take a look into this PR, just to make sure that we have enough feedback before trying to merge. That would be really appreciated.
Mario Vega:And thank you. Thank you for the presentation.
Mario Vega:Alright, I think that's it for today. Any last closing comments?
Mario Vega:Before we wrap up.
Mario Vega:If not, I think we can finish the call there. Thanks everyone for joining.
Mario Vega:And, yep.
Mario Vega:Goodbye.
Marius van der Wijden:Bye-bye.
Dmitrii Shmatko:I don't care about.
Chat Logs
00:03:50
Mario Vega:https://github.com/ethereum/pm/issues/1865
00:06:21
Barnabas:https://github.com/ethereum/beacon-metrics/pull/21
00:09:02
Barnabas:https://dune.com/queries/3757544/6319515
00:09:11
Łukasz Rozmej:Should we wait with BPO3 until the demand increases?
00:09:22
Matthew Keil:Yes, I think its prudent
00:09:22
Justin Florentine (Besu):what do we do if it starts hitting target but its all spam?
00:10:01
Łukasz Rozmej:Replying to "what do we do if it ..."
Is it our role to judge what is spam or not?
00:10:12
Justin Florentine (Besu):Replying to "what do we do if it ..."
i'm honestly not sure
00:10:42
Justin Traglia:What target/max numbers are we going to push for? 24/32?
00:10:51
Łukasz Rozmej:Replying to "what do we do if it ..."
so I think the answer is generally no, but yes on the edges - so I think it depends how the fees look
00:11:00
Barnabas:Replying to "What target/max numb..."
TBD
00:11:03
Justin Florentine (Besu):Replying to "what do we do if it ..."
but i think we're getting to the point that agreeing to increase it might be that judgement
00:11:24
Justin Traglia:Replying to "What target/max numb..."
Yeah I was just curious. Makes sense.
00:12:07
Justin Florentine (Besu):Replying to "what do we do if it ..."
i think fees is a good enough answer for me
00:15:02
Stefan Starflinger:Reth holiday also afaik
00:15:30
Potuz:Replying to "what do we do if it ..."
It’ s a tricky situation. To be the Devil’s advocate why should main net validators be stressed by lowering the blob gas price just to get spam. This is something that should be really dealt with at the L2 level, if L2s start pumping the gas limit to the point that only one operator in the world can run their nodes, they could easily take all of L1’s blob space.
I don’t advocate for us making a decision on what’s spam and what’ s not, but there should be a push back against L2s needlessly becoming BSC.
00:15:36
Potuz:Replying to "what do we do if it ..."
On the back of L1 validators.
00:16:59
Justin Traglia:Releases:
https://github.com/ethereum/consensus-specs/releases/tag/v1.7.0-alpha.0
https://github.com/ethereum/consensus-specs/releases/tag/v1.7.0-alpha.1
New withdrawals discussion:
https://discord.com/channels/595666850260713488/1460267494026510420/1460267497495466097
Open PRs that need to be reviewed:
https://github.com/ethereum/consensus-specs/pull/4792
https://github.com/ethereum/consensus-specs/pull/4817
https://github.com/ethereum/consensus-specs/pull/4772
https://github.com/ethereum/consensus-specs/pull/4826
00:17:51
Barnabas:We should aim for alpha 1 release for the devnet, otherwise everyone will have to implement a broken phase 0 changes.
00:18:45
Potuz:Are we making technical discussions/decisions in this call or will we have a breakout?
00:18:50
Potuz:jinx
00:19:30
Barnabas:Replying to "Are we making techni..."
this is the place imo
00:24:37
Barnabas:sgtm, I just wanna avoid having too different behaviour between clients
00:25:16
Potuz:Yeah if we go that route we need to specify that
00:25:19
Potuz:Cause that affects scores
00:25:38
Barnabas:how big is a bid ?
00:29:22
Justin Traglia:Replying to "how big is a bid ?"
~328 bytes
00:31:25
Enrico Del Fante (tbenr):Not yet 🙂
00:32:02
NC:This doesn’t need to be included for devnet 0 does it?
00:32:26
Barnabas:Replying to "This doesn’t need to..."
no
00:32:42
Barnabas:Replying to "This doesn’t need to..."
alpha 1 is the new target for devnet 0
00:33:14
Barnabas:Replying to "This doesn’t need to..."
if we agree to include this down the road it can become the scope of a future devnet
00:34:15
Potuz:I think we’ll end up having to have a breakout anyway this call is probably not good enough to discuss technical details like these
00:34:48
Justin Traglia:For the next one, we should discuss it on discord.
00:34:59
Potuz:We did for most of them
00:39:27
Marius van der Wijden:But isn't that just a ci problem?
00:41:18
Marius van der Wijden:So you want to merge the epbs stuff directly into master?
00:41:48
Barnabas:prysm already does
00:42:08
Potuz:Replying to "So you want to merge..."
Yes, we want to be merging into our develop branch
00:42:21
Marius van der Wijden:Replying to "So you want to merge..."
This is not a very pipeline-able approach
00:42:39
Mario Vega:https://github.com/ethereum/execution-specs/issues?q=is%3Aissue%20state%3Aopen%20milestone%3Aamsterdam
00:42:55
Potuz:Replying to "So you want to merge..."
We already have prototyped this before and it’s really the only way of getting production code out there. Teku and Nimbus are doing the same
00:42:57
Potuz:Replying to "So you want to merge..."
Not sure about LH
00:43:49
Mario Vega:7778, 7708, 7843, 8024
00:44:05
Barnabas:Are these EL only changes?
00:44:32
Marius van der Wijden:Replying to "So you want to merge..."
What we usually do is build it on a separate branch and then upstream it in chunks to the mainline. Thus we can enable the new tests on the branch and the old tests on master and we switch over once everything is in master
00:44:49
Marius van der Wijden:Replying to "So you want to merge..."
And we continuously rebase the fork
00:45:20
Łukasz Rozmej:we have SLOTNUM: https://github.com/NethermindEth/nethermind/pull/7981
00:45:46
Łukasz Rozmej:but looks stale, need to update it
00:47:17
Marius van der Wijden:The eth transfer one is the most complex should be tackled first
00:47:34
Barnabas:ETA on impl these ?
00:48:56
Barnabas:lets aim for jan 21 for devnet 2
00:49:49
Marius van der Wijden:Can you post in the acd channel the four eips that should be implemented first
00:50:39
Marius van der Wijden:I don't think going to 75m or any gas increase right now is important
00:50:55
Marius van der Wijden:We should focus on repricings imho
00:51:01
Marius van der Wijden:And eth70
00:52:55
Potuz:@Kamil Chodoła what’s the difference in execution+broadcast time from 60 to 75 on the same node you’re measuring?
00:53:02
Mario Vega:https://github.com/ethereum/execution-apis/pull/710
00:54:09
Kamil Chodoła:Replying to "@Kamil Chodoła wh..."
Benchmarks for now are only execution focused and we test on 100 Mgas blocks.
We convert the data captured into MGas/s and make assumptions based on that
00:55:39
Mario Vega:https://github.com/ethereum/execution-apis/pull/650
01:00:42
Simsonraj Easvarasakthi:https://github.com/ethereum/execution-apis/pull/650
https://github.com/simsonraj/eth-err-tests/blob/master/reports/geth-local.log.csv
01:01:13
Justin Traglia:Bye everyone
01:01:19
Simsonraj Easvarasakthi:thank you everyone