AllCoreDevs - Testing CL Breakout #099
Transcript
- Jihoon
- Nico Flaig
I have this implemented it e2e and luca has even tested, but I would like to mention my concerns so we can make a good decision on this
- Potuz
can you talk about it Nico?
- Luca | Vero
- Nico Flaig
yes I can talk about it but then we are not gonna do the endpoint, I wanna give Luca a chance to first explain the pros of it
- Barnabas
can’t this be an optional endpoint?
- Nico Flaig
Replying to "can’t this be an opt..." no, it's desinged ofr multi beacon node setups, so all client should implement it
- Nico Flaig
Replying to "can’t this be an opt..." more generally, optional endpoints are not great spec-wise
- Stefan Bratanov
I think it is optional from what I see, I mean VCs can choose to call it or not
- Luca | Vero
Reacted to "I think it is optional from what I see, I mean VCs can choose to call it or not" with 👍
- Nico Flaig
Replying to "I think it is option..." optional from vc, not optional as a beacon node
- Luca | Vero
Reacted to "optional from vc, not optional as a beacon node" with 👍
- Barnabas
Could we time box this pr? I think we have 6-7 more PRs to discuss
- Jihoon
Replying to "Could we time box th..." I do have one more agenda but I don't see other agenda than this on the GitHub issue.
- Barnabas
Replying to "Could we time box th..." https://github.com/ethereum/beacon-APIs/pull/638 https://github.com/ethereum/beacon-APIs/pull/641 https://github.com/ethereum/beacon-APIs/pull/655 https://github.com/ethereum/beacon-APIs/pull/657 https://github.com/ethereum/beacon-APIs/pull/659 https://github.com/ethereum/beacon-APIs/pull/615
- Potuz
same for Prysm
- Nico Flaig
it doesn't fail, if the provided bid is incompatible with our proposer head we reject it and use local or p2p bid instead
- Caleb
Reacted to "it doesn't fail, i..." with 👍
- Nico Flaig
I am curious how bad it is for other client to call produceblockv4 later in the slot, at least in lodestar we only start to build the beacon block when the api is called
- Potuz
doing this on the beacon node does not seem to be too much of a problem to me
- Enrico Del Fante
How much “late” 🙂
- Potuz
as long as we don't need to touch the VC I think it's fine
- Nico Flaig
Replying to "How much “late” 🙂" depends on the timing games
- Potuz
Replying to "How much “late” 🙂" we do the same as Lodestar and not planning on optimizing this
- Jihoon
- https://github.com/ethereum/consensus-specs/pull/5694 - https://github.com/ethereum/consensus-specs/pull/5695
- Potuz
Replying to "How much “late” 🙂" we already cover node operators that want to play timing games only within Prysm
- Nico Flaig
Replying to "How much “late” 🙂" you could cache it at clock tick for slot instead of the call
- Enrico Del Fante
Replying to "How much “late” 🙂" Teku anticipates a bit of the work but a big chink is done at VC calling for block produiction
- Nico Flaig
Replying to "How much “late” 🙂" but also proposer head we only compute once we call the api
- Miguel Tenorio
Replying to "as long as we don't ..." I would change “need” with “must”
- Luca | Vero
Replying to "How much “late” 🙂" I’m fine with not having any optimizations beacon-node side, at least it will force node operators not to push things too far
- Enrico Del Fante
Replying to "How much “late” 🙂" So we will serve that but will add even more delay
- Nico Flaig
Replying to "as long as we don't ..." beacon node need to implement it, but validators are free to not use it
- Miguel Tenorio
Reacted to "beacon node need to implement it, but validators are free to not use it" with ➕
- Barnabas
potuz you happy with 5695?
- Barnabas
would like to hear from LH too
- Barnabas
do we need a new cl spec release?
- james
Regarding @Luca | Vero pr, I heard from my teammate Manu that many node operators have the validators running in an isolated network without access to the internet. If we add your change I assume it disrupts that assumption right.
- Nico Flaig
I spent a lot of time trying to find gaps so I exhausted my abilities on it
- Jihoon
https://github.com/ethereum/beacon-APIs/pull/638 https://github.com/ethereum/beacon-APIs/pull/641 https://github.com/ethereum/beacon-APIs/pull/655 https://github.com/ethereum/beacon-APIs/pull/657 https://github.com/ethereum/beacon-APIs/pull/659 https://github.com/ethereum/beacon-APIs/pull/615
- Potuz
Replying to "do we need a new cl ..." yes
- Potuz
Replying to "Regarding @Luca | Ve..." I think that's up to them, as far as we are concerned I think it's fine to offer it in the beacon
- Pawan Dhananjay
Will take a look at these today and approve/comment
- Miguel Tenorio
Luca’s PR and his proposed flow are intentionally opt-in
- Barnabas
Reacted to "Will take a look at these today and approve/comment" with 👍
- Jihoon
Reacted to "Will take a look at these today and approve/comment" with 👍
- Nico Flaig
Reacted to "Will take a look at ..." with 👍
- Barnabas
Replying to "Will take a look at ..." lets aim to have them merged before sepolia fork tomorrow?
- Barnabas
Replying to "Will take a look at ..." and ideally impl for hoodi
- Nico Flaig
Replying to "Will take a look at ..." yes plan is too have stuff sorted for hoodi so users can rely on it
- Barnabas
Reacted to "yes plan is too have stuff sorted for hoodi so users can rely on it" with 👍
- Barnabas
do we have any other cl clients images for focil?
- Pawan Dhananjay
Replying to "do we have any other..." Hit us up on the steel channel. Eitan might have something cooked up
- Will Corcoran
Thanks Jihoon!
- Miguel Tenorio
glhf
Call summary
Targets
- •Gloas beacon-API PRs merged before Sepolia fork; implementations ready for Hoodi - 00:20:44
- •New CL spec release required after merging consensus-specs #5695 - 00:23:13
Decisions
- •Merge consensus-specs PR #5695 (Nico's request reordering) for missed-slot builder payment - 00:19:40
- •ProduceBlockV4 bid endpoint not merged now; design discussion continues async targeting Hoodi - 00:15:22
Highlights
- Focil Client Images:
- ·FOCIL images available for Lodestar and Teku; Lighthouse working on it; Prysm status pending - 00:23:47
- Gloas Beacon Api Prs:
- ·6 open Gloas-related beacon-API PRs (#638, #641, #655, #657, #659, #615); Nico has approved all and implemented in Lodestar - 00:20:22
- ·Goal: merge before Sepolia fork; implementations ready for Hoodi - 00:20:44
- Produce Block V4 Bid Beacon Api:
- ·Proposal: VC contacts builders directly, supplies bid to connected Beacon nodes via ProduceBlockV4 extension - 00:01:53
- ·Concerns: adds complexity to VC, may enable undesirable off-protocol markets; Nico notes payload attributes timing mismatch and late-slot API call issues - 00:08:37
- ·If bid rejected by Beacon node, falls back to P2P bid or local build (best-effort inclusion) - 00:14:29
- ·No consensus to merge; Jihoon suggests continued async design discussion targeting Hoodi - 00:15:22
- Epbs Missed Slot Payment Ordering:
- ·Two competing PRs (consensus-specs #5694, #5695) address payment when builder wins bid, exits, and slot is missed - 00:16:07
- ·Nico's PR #5695 preferred by Michael (Lighthouse) and accepted by Potuz; stricter request ordering deemed safer for future extensions - 00:17:53
- ·Merging #5695 constitutes a consensus-breaking change; requires new CL spec release; Potuz to open Prysm PR - 00:23:13
Action Items
- •Luca (Vero) - Luca to open async thread for ProduceBlockV4 bid design discussion - 00:15:56
- •All CL teams (Lighthouse, Teku, Prysm) - Review and approve/comment on 6 Gloas beacon-API PRs before Sepolia fork - 00:21:10
Key decisions
Merge consensus-specs PR #5695 (Nico's request reordering) for missed-slot builder payment
IncludedMerging #5695 is a consensus‑breaking change and will require a new CL spec release.ProduceBlockV4 bid endpoint not merged now; design discussion continues async targeting Hoodi
DFIFurther asynchronous design discussion is planned, targeting the Hoodi release.
AI Disclaimer: Some content or metadata on EIPsInsight may be AI-inferred or automatically compiled. If you find any discrepancy, please contact us at dev@avarch.org.