Add Lodestar EIP-7732 builder proposal#161
Conversation
|
Reminder: We should replace the docs placeholder links once docs are ready. |
taxmeifyoucan
left a comment
taxmeifyoucan
left a comment
There was a problem hiding this comment.
Thanks a lot guys! This is a great proposal, really glad to see you leading by example.
I highlighted couple of things just as symptoms of my main problem - it's pretty long and verbose. As I mentioned, this proposal should be digestible by human, getting straight to point so anyone with technical context can understand it. That's my only criticism and my comments generally reflect that it could be shorter, just helping you find places to trim it a bit. No need to overthink it guys, don't make it too complicated, it's really good :)
|
|
||
| Build an honest-path `lodestar builder` for EIP-7732 / Gloas that can produce local execution payloads, submit signed p2p bids, detect winning bids, and reveal matching payload envelopes. The Deathstar project is tracked as a builder-focused adversarial notebook from the start, with implementation only if the core Builder path is stable. FOCIL / Heze is tracked as future-fork compatibility context, with a possible adaptation pass only if FOCIL merges to `unstable` and the Builder work is far enough along. | ||
|
|
||
| **At a glance** |
There was a problem hiding this comment.
Nice overview but maybe bit unnecessary in the intro section, scope and goals are explain multiple times actually, best to keep this for project/roadmap section
There was a problem hiding this comment.
Moved the overview out of the intro and trimmed it to a four-row Scope summary in b9a219e.
| F --> G["Weeks 19-21+<br/>docs + report + handoff"] | ||
| ``` | ||
|
|
||
| **Week 5 -- Proposal checkpoint.** Publish proposal + living note; align with Marko and Nico on scope, base branch, and the FOCIL/Deathstar stances; start the notebook. *Deliverable: accepted proposal and mentor-aligned scope.* |
There was a problem hiding this comment.
roadmap going week by week is pretty dense! It's not bad, totally ok if you prefer more detailed roadmap plan. This section should serve also like milestones for you and stuff can slip easily, specs change etc, the flowchart on top is great, just highlighting this to give yourself some space and maybe also save on details
There was a problem hiding this comment.
Grouped the roadmap into broader phases while keeping the flowchart in b9a219e.
|
|
||
| ## Possible challenges | ||
|
|
||
| **Moving EIP-7732 / Gloas specs.** EIP-7732 is still Draft; roughly fifteen builder-adjacent spec changes landed in June alone (including `PAYLOAD_BUILDER_VERSION` and forced reorg of late payloads), beacon-APIs changed payload attributes as recently as July 2, consensus-specs #5410 reopens the Heze bid shape, draft EIPs 8237 and 8146 would each change the bid container itself (replacing `execution_requests_root` with an accumulator; adding a `block_access_list_hash` for a BAL sidecar), and a proposed merkleization change (EIP-7688) would shift every signing root. The builder must stay modular and absorb churn. |
There was a problem hiding this comment.
You can just keep it as evolving specs without going into too many details on June update. Sure stuff changes and it will be challenge during the project, important point
There was a problem hiding this comment.
Reduced this to a concise evolving-specs challenge in b9a219e.
|
|
||
| **Minimum success:** an architecture note; a builder service/command skeleton with configuration and key-handling design; proposer-preference lookup; a local payload-construction path; bid construction, signing, and p2p publication; the bid -> payload cache; winning-bid detection; envelope construction, signing, and publication; tests covering the core bid and reveal path; documentation of spec gaps, Lodestar gaps, devnet assumptions, and FOCIL base-branch context; and a Deathstar notebook of builder-specific adversarial cases. | ||
|
|
||
| **Strong success:** a reproducible local end-to-end demo, a real local execution client, a configurable bid policy, logs and metrics for bid/win/reveal/timing, one or more PRs merged or in review, a Heze / FOCIL adaptation pass if FOCIL has merged to `unstable` and mentor guidance makes it useful, and a final write-up of what existed, what was added, and what remains. |
There was a problem hiding this comment.
Couple of times I notice stuff open based on mentor input. It's not a problem if something is tbd but also it shouldn't just rely on mentor, you can future proof the article a bit and refer to like, ongoing implementation details in discussions with lodestar team
There was a problem hiding this comment.
Reworded these as ongoing implementation discussions with the Lodestar team, while leaving the Mentors section itself untouched, in b9a219e/aea02e2.
Update lodestar-eip-7732-builder.md
|
@markolazic01 I removed the dead HackMD placeholder link for now. The living technical note link will be added before this leaves draft / goes ready for review, and the presentation link will be added once that exists. |
krisoshea-eth
left a comment
krisoshea-eth
left a comment
There was a problem hiding this comment.
Submitting the remaining review-thread replies.
| To create a project, write your proposal based on [template](./project-template.md), open PR to add it to this directory and list it below with a relative link. No newline at end of file | ||
| To create a project, write your proposal based on [template](./project-template.md), open PR to add it to this directory and list it below with a relative link. | ||
|
|
||
| ## Project proposals |
There was a problem hiding this comment.
We will create table with all projects once they are submitted. But maybe we can keep it here for now
There was a problem hiding this comment.
Leaving this as-is for now per your note; the project entry can be removed later when the consolidated project table is created.
| | [Keshav](https://www.github.com/keshavsharma25) | | | | | | ||
| | [Kimi](https://github.com/KimiWu123) | [Update 3](https://hackmd.io/@kimiwu/r1rDNxSmMx) | | | | | ||
| | [Kris](https://github.com/krisoshea-eth/) | [Update 3](https://hackmd.io/@krisos/BkiFy_KXMx) | | | | | ||
| | [Kris](https://github.com/krisoshea-eth/) | [Update 3](https://hackmd.io/@krisos/BkiFy_KXMx) | | | [Proposal](projects/lodestar-eip-7732-builder.md) | |
There was a problem hiding this comment.
Small thing - don't name the cell Proposal, add the name directly
| | [Kris](https://github.com/krisoshea-eth/) | [Update 3](https://hackmd.io/@krisos/BkiFy_KXMx) | | | [Proposal](projects/lodestar-eip-7732-builder.md) | | |
| | [Kris](https://github.com/krisoshea-eth/) | [Update 3](https://hackmd.io/@krisos/BkiFy_KXMx) | | | [Lodestar 7732 builder](projects/lodestar-eip-7732-builder.md) | |
taxmeifyoucan
left a comment
taxmeifyoucan
left a comment
There was a problem hiding this comment.
Thank you for all updates! This is more straightforward and digestible, I think it's ready
| | [Kris](https://github.com/krisoshea-eth/) | [Update 3](https://hackmd.io/@krisos/BkiFy_KXMx) | | | [Proposal](projects/lodestar-eip-7732-builder.md) | | ||
| | [Mario](https://github.com/taxmeifyoucan/) | | | | | | ||
| | [Marko](https://github.com/markolazic01) | [Update 3](https://hackmd.io/@lqzic/week-3-update) | | | | | ||
| | [Marko](https://github.com/markolazic01) | [Update 3](https://hackmd.io/@lqzic/week-3-update) | | | [Proposal](projects/lodestar-eip-7732-builder.md) | |
There was a problem hiding this comment.
| | [Marko](https://github.com/markolazic01) | [Update 3](https://hackmd.io/@lqzic/week-3-update) | | | [Proposal](projects/lodestar-eip-7732-builder.md) | | |
| | [Marko](https://github.com/markolazic01) | [Update 3](https://hackmd.io/@lqzic/week-3-update) | | | [Lodestar 7732 builder](projects/lodestar-eip-7732-builder.md) | |
There was a problem hiding this comment.
same thing that Mario pointed out just on my entry
| - Configurable bid policy plus bid/win/reveal/timing logs and metrics. | ||
| - One or more PRs merged or in review, a Heze / FOCIL adaptation pass if FOCIL has merged to `unstable` and Lodestar team discussions make it useful, and a final write-up of what existed, what was added, and what remains. | ||
|
|
||
| **Stretch success:** |
There was a problem hiding this comment.
another stretch goal to add here is implementing the server-side of the builder api and serve trustless bids via api, this could be useful for further spec exploration and testing, goes without saying that we will not support serving trusted bids
for now, this first needs client-side work which is not yet implemented in lodestar ChainSafe/lodestar#9594, and the builder-specs aren't fully finalized yet and need more review/exploration of implementation to find potential gaps
|
|
||
| EIP-7732 removes the direct execution payload, blob commitments, and execution requests from the beacon block body; the body instead carries a `signed_execution_payload_bid` and payload attestations, with the full payload revealed later through a signed envelope. The [Gloas honest-builder spec](https://github.com/ethereum/consensus-specs/blob/master/specs/gloas/builder.md) describes the builder as a staked actor that submits bids and later submits payloads; accepted bids commit the builder to pay the proposer whether or not the payload is submitted. The [p2p spec](https://github.com/ethereum/consensus-specs/blob/master/specs/gloas/p2p-interface.md) defines the gossip surface (`execution_payload_bid`, `execution_payload`, `payload_attestation_message`, `proposer_preferences`) and its validation rules. | ||
|
|
||
| On the Lodestar side, the current code can already produce a block with a provided builder bid, and the self-build path constructs a bid with `BUILDER_INDEX_SELF_BUILD` (defined as `Infinity` in `packages/params`). The remaining gap is the external builder. The builder is an actor that owns a builder key, observes preferences, builds a payload, signs and publishes a bid, remembers the exact payload package the bid commits to, detects a win, and reveals the envelope. |
There was a problem hiding this comment.
nit: We don't want to blindly reveal envelope when there is a win. If we detect proposer's block is weak, we may choose withhold the envelope to avoid payload getting stolen.
There was a problem hiding this comment.
payload getting stolen
since we do not include any private tx or mev, this isn't relevant, there is no unbundling attack, all transactions in our payload are from the public mempool.
however, I like the idea from a research perspective and exploration, since this is what "real" builders will have to do, good idea @ensi321
could be added as a stretch goal
|
|
||
| **Week 5 -- Proposal and scope.** Finalize the proposal, living note, base-branch assumptions, and FOCIL/Deathstar scope. *Deliverable: accepted proposal and agreed scope.* | ||
|
|
||
| **Weeks 6-7 -- Architecture and builder skeleton.** Map Gloas codepaths, confirm current PR state, choose the service boundary, and build the first configuration/key-handling skeleton. *Deliverable: builder skeleton that starts and connects.* |
There was a problem hiding this comment.
Note that builder key is different from validator key, so probably want to go into more detail into key-handling skeleton. Probably need a separate keystore. And remote-signer support would be great. See ethereum/remote-signing-api#28
There was a problem hiding this comment.
Good point -- #191 adds the separate builder keystore and remote-signer support to the Weeks 6-7 deliverable, and we've noted ethereum/remote-signing-api#28 for the key-handling design.
|
|
||
| **Builder service boundary.** The cleanest home for `lodestar builder` is not obvious; the first prototype may need to live near existing beacon-node or validator-client services to reuse code. | ||
|
|
||
| **Base branch uncertainty.** `unstable`, a Glamsterdam devnet branch, or FOCIL-related work based on discussions with the Lodestar team -- kept open deliberately. |
There was a problem hiding this comment.
I think base branch is unstable with constant rebase albeit not much left. We are probably on the last (or second last) devnet, and focil branch should be merged to unstable soon
There was a problem hiding this comment.
Thanks -- #191 removes the base-branch uncertainty challenge on that basis; we'll track the FOCIL merge via ChainSafe/lodestar#7342 for the adaptation-pass timing.
|
|
||
| The builder needs valid proposer preferences before it can submit a trustless bid for a slot. These preferences come from the proposer/validator side and specify values the builder must respect, such as the proposer's `fee_recipient` and `target_gas_limit`. The builder should read them from gossip, an event stream, or Lodestar's internal pool, match them by `proposal_slot` and `dependent_root`, and skip the slot if no matching preferences are available. | ||
|
|
||
| Once the preferences are known, the builder can prepare a payload for that slot using Lodestar's existing Engine API / self-build preparation path, including `engine_getPayloadV6`. One open implementation detail is how to pass the proposer's `target_gas_limit` into the local execution client on a per-payload basis, since a static execution-client gas-limit setting cannot follow different proposer preferences slot by slot. The first version can start with the simplest local payload source that exercises the full bid -> reveal loop, then move toward a real execution client such as Ethrex or Nethermind and eventually a Glamsterdam devnet. For comparison and devnet testing, `ethereum-package` can also run buildoor as a dedicated per-participant ePBS builder. |
There was a problem hiding this comment.
Once the preferences are known, the builder can prepare a payload for that slot
I think there can be some prediction involved on our side.
On a normal network condition, proposer will likely build on FULL of parent block, so we can start calling EL ahead of time to prepare the payload. If we observe parent block's payload is late, we can probably predict proposer will likely build on EMPTY and we can prepare payload accordingly.
There was a problem hiding this comment.
sophisticated builders will prepare two (or more) payloads, they even prepare for parent block today in case the proposer reorgs the block
for this project, I would suggest to go in the direction that @ensi321 noted, but worth pointing out that lodestar itself doesn't even do this currently for local execution payloads, the way we emit payload attributes and call FCU is currently not ideal
There was a problem hiding this comment.
Will add prediction / multiple payload strategy to stretch goals.
| T0["slot start<br/>block carries bid commitment"] | ||
| TA["ATTESTATION_DUE_BPS<br/>beacon block attested"] | ||
| TR["builder reveal window<br/>payload envelope + data columns"] | ||
| TP["PAYLOAD_DUE_BPS<br/>PTC timeliness vote"] |
There was a problem hiding this comment.
I think this is PAYLOAD_ATTESTATION_DUE_BPS
There was a problem hiding this comment.
PAYLOAD_DUE_BPS is for payload timeliness and more relevant here, but unless we implement something like #161 (comment), I think we can just publish asap, like we do for local payloads, so the timeliness deadlines won't matter or at least for now don't have to be explicitly considered
There was a problem hiding this comment.
Checked the specs -- both constants exist: PAYLOAD_ATTESTATION_DUE_BPS is when the PTC vote is due, PAYLOAD_DUE_BPS is the payload-timeliness deadline, which is the one the builder cares about, so keeping it in the diagram per Nico's point. For now we'd publish asap after win detection, so the deadline isn't explicitly handled unless the withholding stretch goal happens.
5 participants
Adds the Lodestar EIP-7732 Builder project proposal for Kris O'Shea and Marko Lazic.
This draft PR:
Validation:
Draft note: