stokes:Okay, thanks. Hi, everyone. Welcome to ACDC. This is number 163.
Transcript
stokes:It is issue 1673 in the PM repo. There's a link to the agenda here.
stokes:And, yeah, the agenda's a bit lighter today, mainly just as we're all working on Fusaka.
stokes:And then there's a few announcements for Glamsterdam, but I don't think we'll get too much into that today.
stokes:So, let's go ahead and get started. So, first up with Fusaka, we have the DevNuts.
stokes:So…
stokes:We have DevNet 3 that's been going. I believe there was just a non-finality test over the last day there, and we could reflect on DevNet 4 and see if there's anything…
stokes:To touch on there. So, let's see, Perry or Barnabas, would one of you like to touch on either of those topics?
Barnabas:Yeah, I can. So, definitely, has regained finality in the past couple of hours, and we have turned on all the validators.
Barnabas:EL had some bug that, they pushed out and should be merged very soon. And some clients, like Lighthouse and Gaff, is still having, issues syncing up to head.
Barnabas:The syncing bug is supposed to be fixed quite soon in the trunk branch, and that is what we are using now on that ministry.
Barnabas:So, for now, I will just have to roll out a custom branch that, the Lighthouse team has been working on. There has been a memory leak that I have detected in REST. I have reported it to them, and there's a few more notes that are, still… I haven't been able to catch up to. They had an
Barnabas:We'll be looking into those, and ideally, you can also take a look and see which nodes are offline, and if it's one of your nodes, then just take a look and see if you can debug it.
Barnabas:We have about 80% participation now.
stokes:Okay, thanks for the update.
stokes:Yeah, anything on DevNet 4? So just as a refresher, we launched DevNet 4, and yeah, ran into some bugs, there was an ambiguity in the PPO spec.
stokes:Which led to some confusion, and then, yeah, kicked off some of these other issues, with the sinking things that Barnabas mentioned. So…
stokes:… Yeah, we've taken the dead net down.
stokes:The plan is to launch 7.5, which we'll get into next. I don't know if there's anything else to touch on.
stokes:DevNet4 at the moment.
Barnabas:Yeah, so the scope for Design 5 should be pretty much exactly the same as DevNet 4, and the spec did not change from Desident 3, so…
Barnabas:The only difference is that we really would like to get every client to…
Barnabas:have their trunk branches ready, so hopefully…
Barnabas:hopefully sometime next week, everyone will have all their PRS changes merged into their trunk branches, and then, we can launch this at 5.
stokes:And DevNet 5 is also a large DevNet, like DevNet 4, right?
Barnabas:That's exactly… That's the pleasure.
stokes:Okay, yeah, I'd love to hear from CL teams here, and honestly, even EL teams, if you're present, about, yeah, the timing there, so…
stokes:Ideally, yeah, we can get everything into the default trunk, …
stokes:End of next week, sooner the better, because then that sets us up to have it done at 5.
stokes:That should look, you know, pretty close to what we'd want from ANET, so… Anyone…
stokes:Have any issues with that, or any complications we should discuss?
stokes:Dave Trimmer.
ethDreamer (Mark):Yeah, just a comment, like, some of the chaos on DevNet 5 had revealed to us that the changes to our sync algorithm needed to be,
ethDreamer (Mark):a little bit more extensive than we had originally thought, than just… compared to finding bugs, we had to do a bit of a redesign. The code for that, my understanding is written. We're just trying to test it, but we're fine with, like, launching DevNet 5, before that's necessarily fully tested.
ethDreamer (Mark):You know, we would want that to block the launch of DevNet 5, is what we're trying to say. But, yeah, we're just in the testing stage for those changes.
stokes:Makes sense. Yeah, and I think just to kind of pipeline things towards mainnet, it'd be nice to have that in, say, like, the Unstable branch for Lighthouse.
stokes:Do you feel like that's reasonable, to have something together next week?
Barnabas:Yeah.
Barnabas:I've been working.
pawan:run the….
Barnabas:The main reason we would want this, all of this in trunk branches, because this is a very, very expensive DevNet, and if you're gonna need to have another one down the line, later on, anyway, then, like, if it's just gonna break, then there's no point of running the DevNet, so we ideally.
Barnabas:Want to have it, nicely tested in .NET3.
Barnabas:Do unfinity test and, test if everything is working with the trunk branches before we launch the expensive 10Net file.
pawan:Yeah, so, …
pawan:I have a branch that is working now, and sync, like, was syncing on DevNet 3, with the non-finality and stuff, so I think it is working, I just need to, like, iron out a few more corner cases. So, I think, like, I should be able to get a PR
pawan:up against unstable, like, pretty soon now. So, yeah, I think we should be ready for DevNet 5 as well.
stokes:Okay, great.
stokes:Anyone else?
stokes:Yeah, Matthew?
Matthew Keil:Yep, we're also merged to, Trunk Branch. We're doing a refactor and trying to get that unit tested, but, you know, by mid-end of next week, that'll be real close.
stokes:You don't feel like that timeline doesn't make sense?
stokes:Okay, I'll assume everyone agrees then. And, yeah, not sure how things look on the EL side, but yeah, if you're listening.
stokes:Keep this in mind.
stokes:It'd be nice to have .NE5Up as soon as we can, and yeah.
stokes:I guess, if anything, we can touch on the next ACDE for that.
stokes:So…
stokes:Okay, and I think from there, we see how DevNet5 goes, and at that point, assuming it goes well, I think we can, you know, start to seriously think about testnet timelines, which then would give us a mainnet date, so…
stokes:I know we've talked quite a bit about timelines in the past, … yeah, I think we're more or less on track to keep things moving, so…
stokes:I think for now, we'll just focus on….
gottfried:Good.
stokes:everything into trunk And, yeah, look for the launch of .NET 5.
stokes:Anything else on DevNets? Otherwise, there are a few other items for Saka to touch on.
stokes:Okay, Prism says here in the chat, we'll need about a week to get things ready, yeah.
stokes:Yeah, James, do you know if that's, like, a week from today, or…?
James He:Optimistically, I think, a week from today.
stokes:Okay.
James He:But more likely, maybe by…
James He:the following Monday or so, hopefully.
stokes:Got it.
stokes:Okay.
stokes:Cool. Well, yeah, … Good to know.
stokes:And otherwise, then, we will see how things progress.
stokes:Okay, … There was a quick FYI here. We covered this on the last call.
stokes:But essentially, it was just adjusting, this parameter, for minimal. This will help with testing, because then we can run larger blob counts, in the minimal preset, which is just a lighter sort of way to run DevNets and things.
stokes:That's been merged, and as far as I know, Justin Traglio was planning to release an Alpha 5 version of the specs, today, so it will include that change, and yeah, maybe a few other things.
stokes:But something to get on your radar.
stokes:And, yeah, hopefully this change to the ball parameter here that I linked isn't too invasive.
stokes:Of course, you know, the… I think the focus should be getting towards the mainnet. That being said, this will help with testing, so yeah, just try to find the right balance between, getting this done and everything else.
stokes:Okay. Justin, anything else on the spec release?
Justin Traglia:Nope, that's it.
stokes:Okay, cool.
stokes:Then, okay, the last Fusaka item here.
stokes:This came up in a few different forums this week with, some different async conversations.
stokes:I figured we'd touch on it. It sounds like, I think we've resolved it, again, in the different places this has been discussed.
stokes:But, Etan raised a question about, sort of, how BPOs work, …
stokes:We partitioned them with Fork Digest.
stokes:we decided…
stokes:Many calls ago to not include the fork version, and there's been some active discussion around how this kind of works.
stokes:And if there was a potential, you know, dust factor here, or some security concern, I think…
stokes:After analysis done, this week by many of you, we've kind of agreed that this is okay, but I did want to open the floor to have this conversation in case there was something to discuss.
stokes:Yeah. Anyone have anything to say here?
stokes:I mean, I guess what one TLDR is just that it sounds like this is more of a theoretical attack vector, it would require quite a bit of the network to not upgrade, and…
stokes:be a pretty, yeah, pretty, involved attack, so it seems like most of us think that it's not realistic, so we can kind of move ahead as planned.
Raúl Kripalani:Yeah, just to maybe kind of, like, add a little bit more detail, so it's… the three areas of impact that we potentially… that we analyzed were, first, can we make nodes engage in
Raúl Kripalani:Can an attacker make nodes in the majority partition, engage in wasteful work by fetching blocks that were produced in the…
Raúl Kripalani:in the minority fork, and… and their parents, and so on, because they don't know the parents, can they… would they go on a chase, on a hunt, trying to look for the parents, and this would lead to… to wasteful work. That was concern one. The other concern was, can this then, in turn, because the potential attacker, theoretical attacker here, would be the only party that's able to actually serve the data for those blocks.
Raúl Kripalani:Would they be able to get an advantageous position in the mesh by boosting their peer scores, given that they're the only ones that are able to satisfy the data availability of that block? And that is implementation… very implementation dependent, and …
Raúl Kripalani:And yeah, we determined that it really, really wasn't, wasn't a concern here. And then, at last, the third point is, can, is it possible to…
Raúl Kripalani:Use to cross-feed the attestations from the majority chain into the minority fork.
Raúl Kripalani:to boost, the weight of that chain, and eventually reach a sufficient level that would allow that chain to be justified, and that could, like, that is an extremely, extremely, theoretical, like, scenario, and the probabilities are, like, 1 in
Raúl Kripalani:129 million, or something like that, and it requires a ton of sophistication from the attacker, and it can only be performed in a tiny
Raúl Kripalani:window, of time, so we… ultimately, I think, Alex, like, I concur with Alex, the… the consensus here is it's really not relevant. Like, it's… it's not… it's not gonna be… it's… it's not something that we should worry about.
Raúl Kripalani:What we plan to do, maybe, is update the EIP, just to elaborate on the trade-off between the… between having chosen the fork digest solution versus the fork version solution, and maybe some, like, brief security implications, but… but yeah, this is definitely not a cause for… for concern, at least that's my view.
stokes:Great, yeah, thanks for the extra color.
stokes:Anyone else have anything to add here?
stokes:We got photos?
potuz:I have a question more than something to add, but I just don't really understand why this is even an attack. I mean, if we are in such a situation, it sounds to me like just a normal fork.
potuz:I understand that we typically, across a fork boundary, we would just, like, unpeer from peers that are not following the chain, but if I just forget that the fact that there was a BPO, there was no fork, this would just be, just like a normal fork.
potuz:It's just that people following one of the branches will not never accept blocks from the other branch, because it has more than the maximum number of blocks.
potuz:But it's just, from the point of view of the ones that are actually updated.
potuz:It's just a normal fork, so it should be just resolved.
Raúl Kripalani:Oh my god.
potuz:usual fork choice.
Raúl Kripalani:Yeah, the difference, I think.
potuz:a little bit.
Raúl Kripalani:Yeah, I think kind of, like, the unique scenario here is that because the network… because we chose the fork digest solution, where the network is partitioned, but the state… but there's no… the state is not…
Raúl Kripalani:partition, so to speak, because there is no change to the beacon state, and as well, the domain… the signature domain separation tag is also not namespaced. So basically, the vector, kind of like.
Raúl Kripalani:The potential, …
Raúl Kripalani:like, yeah, a potential vector here that could be used would be, like, cross-feeding information between one chain and another. That's basically it.
ethDreamer (Mark):I understand.
potuz:but the thing is that I still don't understand what is… what's… why is this even an attack? This is a difference between the normal branch and this kind of branch. But I don't see why, from the point of view of the chain, this is just not resolved in the exact same way as just a normal branching situation, unfortunately.
ethDreamer (Mark):I think the idea is that the attacker would technically require a bit less stake than they normally would, because you have a couple more people who are on the attacker's fork, because we induced a fork in the chain at the BPO boundary. So, like, it's not just the attacker's nodes that are engaging in this, but it's the people that forgot to update that would be engaging, or, like… Sure.
potuz:And as long as those guys are not a majority of the chain.
potuz:It's just a normal four-choice branching.
ethDreamer (Mark):That is correct.
stokes:Yeah, I think we're in agreement there, so… Yeah
stokes:Sounds like we're good to move forward. Again, yeah, thank you everyone who contributed to the conversation. I know there's quite a lot of analysis, that went into this.
stokes:So… Okay.
stokes:What else is on the agenda here?
stokes:If we're good with that, then… yeah, that was really all we had for Fusaka. Anything else we'd like to bring up, before we move to Glamsterdam?
stokes:Where I'll just have a few announcements, really.
stokes:Okay.
stokes:So, then… okay, Tony wanted to give an update, on a breakout for block-level access list.
stokes:Tony… there you go, there you are. Yeah, would you like to say anything?
Toni Wahrstaetter:Yeah, there will be a…
Toni Wahrstaetter:First breakout call next week on Wednesday, 2 p.m. UTC, usual time, about block lab access lists, so if you're interested, feel free to show up or watch the stream.
stokes:Okay, cool.
stokes:Exciting to see that being spun up.
stokes:And then… let's see, there was a last-minute addition here. Let me read Osgar's comment.
stokes:Meta-eip for the pricing proposals. Yep, Osgar, would you like to say anything more?
Ansgar Dietrichs:Yeah, I mean, it's really just a quick mention, obviously it's more of an EL-side topic, so the idea was just to mention briefly now, so that people can have a look, and then next week we can discuss it on ACDE. There was some desire to basically
Ansgar Dietrichs:aggregate the individual repricing efforts into some sort of meta-EIP, and then next week we could talk about, like, does that make sense? What role would the meta-EIP, …
Ansgar Dietrichs:have? Would we still want to discuss all the APs individually for the governance process, or in some sort of patched form? All these kind of questions. Again, just…
Ansgar Dietrichs:people, have a look. That's all, that's, …
Ansgar Dietrichs:That EIP is by Maria, and me, so reach out to either of us, with feedback. Awesome.
stokes:Okay, thanks.
lightclient:Reserve Amsterdam.
Ansgar Dietrichs:Oh yeah, sorry, that's specifically for Glamsterdam, so those are basically the… that's just tracking all the potential EIPs that could be relevant for Glamsterdam that are centered around repricings of one sort or another.
stokes:Cool.
stokes:So, take a look there. And, yeah, just to call out Terrence's comment, there's also a 7732 breakout next Friday. The link is here in the chat.
stokes:So, yeah, I mean, again, part of our strategy here is to parallelize our fork development process, so yeah, we have a bunch of breakouts spinning up, to start making headway on Glamsterdam.
stokes:And… let's see, I think that was it for announcements there.
stokes:And… yeah, the last…
stokes:Oh, actually, let's circle back to this. So there's a question, again, I'm probably going to pronounce this wrong, but, A.B. Kutap,
stokes:He was asking if there's a way to track, again, this, you know.
stokes:task of getting everything ready for DevNet5, essentially, where the main thing right now is getting, code merged from our experimental branches into, default chunks.
stokes:And… Yeah, Barnabas, you posted a comment here. Would this be, sort of, the canonical resource right now?
Barnabas:Yeah, we don't really have any better way, because this is, like, the repo that we use to roll out the images, so, like.
Barnabas:whenever we try to keep up with the images, there's gonna be a config drift, so I would just reference this.
stokes:Alright, thanks. I'll make sure that ends up in the notes, so people can refer to that.
stokes:And, yeah, okay. So, jumping back to livestream then, yeah, Ongar's point leads to…
stokes:final thing I had today, which is just a reminder, so, we've decided headliners for Amsterdam.
stokes:other EIP proposals we want to have made by Forsaka mainnet releases. So, you know, again.
stokes:We'll see exactly when that is, given how things go with development, but let's say roughly October, so, you know, in a couple months here.
stokes:And this would be things that are not headliners, but other things we want to put into Glamsterdam. And yeah, I don't think we should get into what those proposals are today, but just as a heads up, please keep that timing in mind so that we can keep moving forward on Glamsterdam.
stokes:Once Osaka is closer to midnight.
stokes:So… I think that's all we had today, actually.
stokes:Anything else? Otherwise, we'll wrap up, and… okay. Yeah, Barnabas?
Barnabas:Yeah, just one more thing, so everybody is on the same page. Ideally, we should have Office 6, ready with all the EPBS changes on top of, Hulu.
Barnabas:And we could probably target, late October for APB as a net zero.
stokes:Okay.
stokes:Photos?
potuz:Yeah, I was gonna say the same. Probably it's a good time to start giving short updates on Glamsterdam, on what we're doing. The, …
potuz:tests, I mean, the spec is going fast, we're adding tests, or Terrence is adding a bunch of tests, and Justin is, rebasing. There are a couple of things that are still missing in the spec, like the dual deadlines, and… but that's essentially… that's it. And some changes on… some changes on,
potuz:proposer… proposer head, get proposer head, and some changes for the proposer boost that can be actually backported to Phase 0. These are security changes that Francesco proposed.
potuz:There are other people that are starting to look at the spec, and as always, when you get new people looking at the spec, we are finding edge cases. This is mostly coming from the Lido guys that are, that are looking deeply into how they're gonna be approving withdrawals and these kind of things.
potuz:And there are, already some edge cases that could be interesting to look into. For example,
potuz:I think, so, EIP4788 currently gives the PICOM block route.
potuz:And it has to give the parent become block root, because it cannot give you the current become block root, because it hasn't been constructed. But after EPBS, that EIP correct, for example, could give the current become block root, and it seems that that would be more interesting for people that are actually using that EIP, so it's probably good to start looking into that.
lightclient:Why is it that much more interesting?
potuz:Because then you have something about the current payload. You can actually use something about the current payload.
potuz:Information about the current payload, like the withdrawals that are included in the current payload.
potuz:That were already paid in the CL.
stokes:You know, I still have the same circular dependency.
potuz:No, the Beacon block route does not commit, … … So how does it go?
stokes:I think it does.
potuz:Yeah, I think it still does.
potuz:Yeah, that's right. So, the become log root can only be the parent. Oh, that's crazy.
stokes:It cannot be used. Well, it's just… yeah, I mean, until we do something more invasive.
potuz:Yeah, so the biggest problem here is that there is no way of proving against the post state of the payload.
potuz:Because once you have a beacon block route, you only have the state root of the post state of the consensus block, and not the payload.
stokes:Right, and then I also wonder how that works with execution requests?
potuz:Oh, for… for execution requests, that's… that's… that is fine, right? Because the…
potuz:So the beacon block route, I mean, everything is commuted.
potuz:And the payload… the payload sends the request in the… in the… well, in the envelope.
potuz:And they're just only… that state route is modified, so there are two state transitions. One is on the beacon block, and then the other one on the payload, and the payload is the one that includes the execution requests.
potuz:So if you want to prove against what happens after the payload, and what happened after those execution requests, you need to have that post state.
potuz:The envelope commits to that post state, but that post state is not included currently in the beacon state.
potuz:And not in the PICOM block, of course.
stokes:Okay.
stokes:In any case, thanks for the update. So, yeah, development on 7732 is ongoing.
stokes:I'll direct people to the next breakout if you want to take a closer look.
stokes:And… yeah, I would suggest, just for time today, we move to another topic, if there is one.
stokes:So, anything else?
stokes:Otherwise, we can wrap up and use the time to work on Fusaka releases.
stokes:Okay.
stokes:then let's call it short crawl today. Thanks, everyone, for joining, and I'll see you next time.
Justin Traglia:everyone.
potuz:Bye.
Marius van der Wijden:I bet.
Orest Tarasiuk (t1):You're right.
Ansgar Dietrichs:That one.
Chat Logs
00:03:38
stokes:https://github.com/ethereum/pm/issues/1673
00:05:56
Barnabas:Offline nodes on devnet 3
00:09:59
Barnabas:can we roll unstable on devnet 3 for lodestar ?
00:11:10
James He:I think we need a week to get things into trunk(develop) at least.
00:11:19
Barnabas:Replying to "I think we need a we..."
week from today?
00:11:33
Barnabas:Replying to "I think we need a we..."
target should be next friday latest if possible?
00:12:11
James He:Replying to "I think we need a we..."
Optimistically targeting that
00:12:20
stokes:https://github.com/ethereum/consensus-specs/pull/4508
00:12:52
Justin Traglia:Yes, the alpha.5 release is in progress
00:12:52
Barnabas:release is rolling out https://github.com/ethereum/consensus-specs/actions/runs/17115285278/job/48544846439
00:12:53
Phil Ngo:Replying to "can we roll unstable..."
Yes, but we’re also actively merging new stuff to test on that so if you find it broken, please ping
00:13:39
Barnabas:does alpha 5 has epbs rebase in it already?
00:13:46
Barnabas:should we target alpha 5 for epbs-devnet-0?
00:14:01
stokes:https://ethereum-magicians.org/t/eip-7892-blob-parameter-only-hardforks/23018/5?u=ralexstokes
00:14:06
Justin Traglia:Replying to "does alpha 5 has epb..."
ePBS has been rebased from electra to fulu
00:14:13
potuz:Replying to "should we target alp..."
no, it' s missing a bunch of tests and the spec is not fully ready yet
00:14:26
potuz:Replying to "should we target alp..."
Hopefully alpha 6
00:14:33
Barnabas:Replying to "should we target alp..."
sounds good!
00:14:41
Etan (Nimbus):ideally, the people familiar with fork choice should take a look at it, so that we know that security is safe
00:16:41
ethDreamer (Mark):Also requires attacker to have 1/3 stake
00:16:56
stokes:Replying to "Also requires attack..."
And we likely have bigger issues at that point
00:17:10
ethDreamer (Mark):Replying to "Also requires attack..."
exactly
00:17:18
Etan (Nimbus):Replying to "Also requires attack..."
could the security level be emphasized somewhere that ethereum supports? isn’t it 1/3 anymore?
00:17:56
Barnabas:Replying to "can we roll unstable..."
ok rolling
00:19:37
Etan (Nimbus):peers don’t see the blocks from the other partition by default. they are not gossiped, attackers just send them to you via req/resp and can collect their attestations that way
00:20:53
stokes:https://github.com/ethereum/pm/issues/1691
00:21:06
terence:there's also an eip7732 breakout next friday as well if anyone is interested: https://github.com/ethereum/pm/issues/1696
00:21:32
stokes:https://github.com/ethereum/EIPs/pull/10206
00:21:38
stokes:Replying to "https://github.com/e..."
Repricing metaeip
00:21:43
Toni Wahrstaetter:This is the breakout call:
https://github.com/ethereum/pm/issues/1691
00:23:25
Barnabas:Image tracker: https://github.com/ethpandaops/fusaka-devnets/blob/master/ansible/inventories/devnet-3/group_vars/all/images.yaml#L1-L19
00:25:08
Marius van der Wijden:quick call lfg
00:25:18
stokes:Replying to "quick call lfg"
Time to work on fusaka 🙂
00:27:55
Marius van der Wijden:It would've been very nice
00:29:26
Ansgar Dietrichs:seems natural you can’t access current beacon block root, because they are still *constructed* EL payload first, beacon block after, no?
they are only verified the other way around, CL block first, EL payload delayed later
00:29:46
potuz:Replying to "seems natural you ca..."
the main problem is the post-state for the payload
00:29:50
potuz:Replying to "seems natural you ca..."
which is not accessible today
00:29:53
Orest Tarasiuk (t1):bye