List view
Build a proposer-duty observability baseline for Anchor before making further QBFT or proposer-path changes. Why this exists: - Anchor has clear evidence that proposer timing is fragile under a tight slot budget, including `#758` and the broader fetch-before-consensus concern. - We currently have useful `tracing` and Prometheus coverage, but not one coherent proposer-duty view from pre-QBFT fetch/build through QBFT, post-consensus threshold/reconstruction, and publish. - We should measure the duty path end to end before changing consensus behavior. How this relates to SSV: - SSV has already shipped relevant observability and proposer-path work: duty-flow tracing (`ssvlabs/ssv#2076`, `ssvlabs/ssv#2272`), QBFT stage duration logging (`ssvlabs/ssv#2609`), smart proposal selection (`ssvlabs/ssv#2648`), and proposer timing budget documentation (`ssvlabs/ssv#2416`). - SSV still has open proposer-liveness and timing work: fetch-before-consensus / async fetch (`ssvlabs/ssv#1825`, `ssvlabs/ssv-spec#371`) and timeout alignment (`ssvlabs/SIPs#37`, `ssvlabs/ssv-spec#352`). - Anchor does not need a literal port of `ssvlabs/ssv#2076`. It needs a proposer-focused observability slice that lets us decide whether the next optimization belongs in pre-QBFT fetch/build, QBFT round behavior, post-consensus signing, or publish. Desired outcome: - one canonical proposer-duty root span - stable event / checkpoint vocabulary - low-cardinality metrics suitable for dashboards and alerting - enough data to attribute missed or slow proposer duties to the dominant phase Non-goals: - protocol redesign - leaderless consensus work - changing timeout logic in the same PRs as instrumentation - a repo-wide OpenTelemetry rollout on day one
No due date•1/5 issues closed