metrics, node: lean_block_proposal attestation build metrics#914
Merged
Conversation
Instrument getProposalAttestations with cross-client lean_* phase timing, build/child-payload counters, and attestation-data/aggregate histograms. Distinct from zeam_compact_attestations_* (compactAttestations FFI only).
Align phase label with leanSpec #753; compact is spec-level recursive merge, not an FFI-specific step name.
2 tasks
anshalshukla
previously approved these changes
May 21, 2026
CI stalled finalization at slot 12 so node3 never emitted its own new_finalization within 480s. Accept head-event progress after the delayed node3 start (original #484 approach) while still honoring node3 finalization or a later global finalization when they occur. Remove the per-event SUCCESS log that fired before assertions.
CI records ~25 new_head events by first finalization and only one more before the chain stalls; requiring +5 never tripped got_node3_sync. Use strictly-more-than baseline and re-check at timeout exit.
anshalshukla
approved these changes
May 22, 2026
MegaRedHand
pushed a commit
to lambdaclass/ethlambda
that referenced
this pull request
Jun 3, 2026
…ction (#414) ## 🗒️ Description / Motivation Ports the five `lean_block_proposal_*` observability metrics from [leanSpec PR #753](leanEthereum/leanSpec#753) into the ethlambda block builder. These metrics give cross-client visibility into the block-proposal attestation-selection path (`build_block`): how long each phase takes, how many proposal builds run, how many child payloads are greedily consumed, and how many distinct `AttestationData` / aggregated proofs end up in the proposed block. They align with [zeam #914](blockblaz/zeam#914 `getProposalAttestations` instrumentation and the leanSpec naming so the [leanMetrics](https://github.com/leanEthereum/leanMetrics) dashboards work across clients. ## What Changed **`crates/blockchain/src/metrics.rs`** — five new metrics registered with the existing `LazyLock` + `register_*!` pattern, a `BLOCK_PROPOSAL_ATTESTATION_BUILD_PHASES` label constant, registration in `init()`, public API functions, and a unit test: | Metric | Type | Buckets / Labels | |--------|------|------------------| | `lean_block_proposal_attestation_build_phase_seconds` | HistogramVec | `phase` = `select_payloads`, `compact`, `stf_simulate`; buckets `0.001…8` | | `lean_block_proposal_attestation_builds_total` | Counter | one per proposal attempt | | `lean_block_proposal_child_payloads_consumed_total` | Counter | greedily-picked proofs before compaction | | `lean_block_proposal_attestation_data_selected` | Histogram | buckets `0, 1, 2, 4, 8, 16, 32` | | `lean_block_proposal_aggregates_selected` | Histogram | buckets `0, 1, 2, 4, 8, 16, 32, 64, 128` | **`crates/blockchain/src/block_builder.rs`** — instruments `build_block`: times the `select_attestations`, `compact_attestations`, and STF (`process_slots` + `process_block`) phases, and emits the counters/histograms after a successful build. **`docs/metrics.md`** — documents all five in the Block Production Metrics table. ## Correctness / Behavior Guarantees - **No behavior change.** Only metric observations were added around existing logic; block contents, selection order, and the state-transition path are untouched. - **Architectural divergence from leanSpec, documented.** leanSpec re-runs the STF inside a fixed-point loop and observes `stf_simulate` per round. ethlambda projects justification/finalization incrementally during selection and runs the STF exactly **once** at the end, so its `stf_simulate` is a single observation per build. This is noted on the `BLOCK_PROPOSAL_ATTESTATION_BUILD_PHASES` doc comment, consistent with the upstream PR's own caveat that phase timings are not directly comparable across clients. - `attestation_data_selected` and `aggregates_selected` are observed from the post-compaction body (one merged proof per distinct `AttestationData`), matching the spec's intent. - Metrics are only emitted on a **successful** build; a build that errors out in the STF is already counted by the existing `lean_block_building_failures_total`. ## Tests Added / Run - New unit test `metrics::tests::block_proposal_attestation_build_metrics_are_usable` — verifies the phase metric registers and accepts every label in `BLOCK_PROPOSAL_ATTESTATION_BUILD_PHASES`, and that the companion counters/histograms are callable. Guards against drift between the label constant and the strings passed at the `build_block` call sites. - Existing `block_builder` tests (`build_block_*`, `compact_attestations_*`, `extend_proofs_greedily_*`) now exercise the new metric paths and pass unchanged. Commands run: - `make fmt` — clean - `cargo clippy -p ethlambda-blockchain --all-targets -- -D warnings` — clean - `cargo test -p ethlambda-blockchain --lib` — 23 passing ## Related Issues / PRs - Ports [leanEthereum/leanSpec#753](leanEthereum/leanSpec#753) - Related to [blockblaz/zeam#914](blockblaz/zeam#914) - Follows the metrics pattern from #406 (per-subnet attestation aggregate coverage) ## ✅ Verification Checklist - [x] Ran `make fmt` — clean - [x] Ran `make lint` (clippy with `-D warnings`) — clean - [ ] Ran `cargo test --workspace --release` — only `ethlambda-blockchain` lib suite run (23 passing); full workspace release run not yet executed
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
2 participants
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
Adds cross-client
lean_block_proposal_*metrics for block-proposal attestation selection ingetProposalAttestationsUnlocked, aligned with leanSpec #753:lean_block_proposal_attestation_build_phase_seconds{phase}—select_payloads,compact_ffi,stf_simulatelean_block_proposal_attestation_builds_totallean_block_proposal_child_payloads_consumed_totallean_block_proposal_attestation_data_selectedlean_block_proposal_aggregates_selectedThese are not the same as
zeam_compact_attestations_*(per-compactAttestationsFFI time and attestation row in/out only).lean_block_building_payload_aggregation_time_secondsremains the wall-clock total for the whole call.Test plan
zig build test