Merge beacon payload attributes with relay duties into a slot context - #556
Open
0w3n-d wants to merge 1 commit into
Open
Merge beacon payload attributes with relay duties into a slot context#5560w3n-d wants to merge 1 commit into
0w3n-d wants to merge 1 commit into
Conversation
The beacon node supplies the consensus fields and the relay supplies the proposer. Neither alone is enough to build. Take the fee recipient and gas limit from the duty. The event carries a `suggested_fee_recipient`, but it is the local validator's. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
6 tasks
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Issue: #550 (step 2 of 6)
What this PR does
Adds
SlotTracker, which merges the beacon node'spayload_attributesSSEevents with the relay's proposer duties and emits one
SlotContextper slotworth building. Neither source alone is enough: the beacon node gives the
parent, timestamp,
prev_randao, withdrawals andparent_beacon_block_root,and the relay gives the proposer pubkey, fee recipient and registered gas
limit.
The building role now runs. It subscribes, polls duties every 12s, and logs
each slot it would build for. Nothing is built or submitted yet.
The fee recipient and gas limit are taken from the duty, never from the
event's
suggested_fee_recipient— that field is the local validator's, andpaying it would produce a block the relay rejects.
What this PR deliberately does not do
No block assembly, no submission. The
SlotContextreceiver inmain.rsis adrain until step 3.
SlotContextcarries#[allow(dead_code)]until then.Duties are deserialized into the relay's own
BuilderGetValidatorsResponserather than a local struct, which keeps the two in lockstep but means this
builder targets Helix, not any mev-boost relay.
Tests
11 new, written before the implementation and signed off first. The merge
logic is pure and carries all of them; the SSE and HTTP calls stay thin and
are exercised by running the role.
recipient and gas limit come from the duty, not the event; an event with no
duty is skipped.
node re-emits whenever it recomputes; a new parent for the same slot is
not a duplicate and must rebuild, because the relay keys attributes by
(parent_hash, slot); an older slot is discarded, as an SSE reconnectreplays; a missing
parent_beacon_block_rootskips the slot, since EIP-4788makes it mandatory.
duties do not accumulate across epochs.
get_validatorsresponse and a realbeacon SSE payload.
The
get_validatorsfixture already earned its place — it caught thatFilteringserializes as"global", not0.114 pass in the crate.
Reviewer checklist
lint,unit-test) is green