feat(das-guardian): surface Gloas proposer preferences in scan modal#712
Open
barnabasbusa wants to merge 8 commits into
Open
feat(das-guardian): surface Gloas proposer preferences in scan modal#712barnabasbusa wants to merge 8 commits into
barnabasbusa wants to merge 8 commits into
Conversation
eth-das-guardian now sniffs SignedProposerPreferences off the Gloas `proposer_preferences` gossip topic and attaches the observations to each scan result. Pull them through the JSON API and render a small table in the DAS Guardian modal showing validator, proposal slot, fee recipient (truncated, full value on hover), gas limit and the receive timestamp. Bumps github.com/ethpandaops/eth-das-guardian to a pre-release SHA from ethpandaops/eth-das-guardian#6.
Pulls in the fix for "incorrect offset: first offset 56 does not match expected 356" when scanning a Gloas peer — adds the post-EIP-7732 sidecar layout (slot + beacon_block_root, no signed_block_header / kzg_commitments / kzg_commitments_inclusion_proof) and normalises it back into the existing scan pipeline. See ethpandaops/eth-das-guardian#6.
Adds a fourth scan type alongside Random/Specific Slots/Metadata Only: "Proposer Preferences" — runs a metadata-only DAS Guardian scan and keeps the Gloas `proposer_preferences` gossip subscription open for a caller-configurable wait window (default 24s, capped at 60s server side) so the gossipsub mesh has time to deliver SignedProposerPreferences messages from the scanned peer. - API request gains wait_for_proposer_preferences_seconds (int, 0–60). - services.NewDasGuardian now accepts functional options; the API handler enables WithProposerPreferencesWait when the new field is set. - Scan timeout is extended by the wait window so the HTTP request doesn't time out before the gossip listener. - Modal shows a friendly empty state when the explicit Preferences scan returns zero observations (expected pre-Gloas, or when none of the peer's validators were about to propose). Pulls in ethpandaops/eth-das-guardian@67ee99d which exposes the ProposerPreferencesWaitDuration knob.
…l observation log)
… pre-fork subscribe)
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
1 participant
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.
Summary
github.com/ethpandaops/eth-das-guardianto the pre-release SHA from feat: sniff Gloas SignedProposerPreferences gossip eth-das-guardian#6, which adds a Gloasproposer_preferencesgossip sniffer.APIDasGuardianScanResultwithproposer_preferences[](validator_index, proposal_slot, fee_recipient, gas_limit, dependent_root, received_at, from) and maps the observations from the underlying scan result.templates/clients/clients_cl.htmlthat renders a small table when any preferences are observed: validator →/validator/{index}, proposal slot →/slot/{slot}, truncated fee recipient (full value on hover), formatted gas limit, RFC3339 receive timestamp.Depends on ethpandaops/eth-das-guardian#6 — needs to be re-pinned to a tagged version once that PR lands.
Why this is a section, not a table column
SignedProposerPreferences are per-validator and broadcast a slot or two before each proposal. A single scan window may catch zero, one or several messages, so a fixed column in the mass-scan grid would be empty most of the time. The detail modal already groups status / metadata / DAS check; a fourth grouped table fits the same shape and stays out of the way on pre-Gloas networks (the section is hidden entirely when the array is empty).
Test plan
go build ./...go vet ./...