feat(blockchain): pre-build proposer block one interval early

[MegaRedHand]

What

Proposers do the heavy leanVM block-building work (attestation compaction + the Type-1 → Type-2 merge, ~1–2s) synchronously at interval 0 today, squeezed into the slot's first interval. This builds the next slot's block one interval early — at the previous slot's interval 4, synchronously on the blockchain actor — and publishes it at interval 0 after a revalidation. On any mismatch or failure it falls back to the existing synchronous build, so there is no regression.

How

• Interval 4 (of slot S-1): if one of our validators proposes slot S, prebuild_block builds + signs + merges the full block against the current (read-only) head and stashes it as a PreparedBlock.
• Interval 0 (of slot S): propose_block publishes the prepared block iff it is still valid (prebuilt_block_is_usable: same slot/proposer, parent still the canonical head, and the built justified slot not behind the store's). Otherwise it rebuilds synchronously.
• Shared assemble_signed_block / process_and_publish_block helpers back both the pre-build and the fallback path.
• Signing stays on the actor throughout: XMSS keys are stateful (sign_block_root takes &mut self), so the build cannot be moved off-thread without risking OTS-index reuse.

Finalization fix (included)

Capturing the pre-build head via get_proposal_head — which is not read-only, it ticks the store clock — one interval early advanced the clock prematurely and stalled finalization. Fixed by capturing the head read-only via store.head().

Validation (local devnet: 4 ethlambda nodes, 1 aggregator)

• Finalization healthy (finalized lag ~3 slots).
• Near-100% pre-build hit rate; zero stale discards, zero skipped ticks, zero errors.

Tradeoff

Building synchronously blocks the actor for the build duration at interval 4. This is acceptable: between interval 4 and the next slot the actor has no other consensus-critical duty, and the devnet run showed zero skipped ticks.

Tests

make fmt + cargo clippy -p ethlambda-blockchain --all-targets -- -D warnings clean; lib tests pass, including the new block_builder::prebuild_tests covering the usability predicate.

[greptile-apps]

Greptile Summary

This PR pre-builds the next slot's block at interval 4 of the previous slot, stashing a PreparedBlock that the proposer can publish at interval 0 after a lightweight revalidation, with a full synchronous rebuild as fallback. It also fixes a clock-skew regression where get_proposal_head advanced the store prematurely when called one interval early.

• PreparedBlock / prebuilt_block_is_usable in block_builder.rs encapsulate the pre-built state and the usability predicate, well-tested by new prebuild_tests.
• propose_block in lib.rs is refactored into three shared helpers (build_signed_block, assemble_signed_block, process_and_publish_block) used by both the fast and fallback paths; the interval-4 pre-build uses store.head() read-only while the interval-0 proposal still ticks the clock via get_proposal_head.
• store.rs extracts produce_block_on_head so the pre-build can produce a block against a known head without side effects on the store clock.

Confidence Score: 3/5

The fallback path can call sign_block_root for the same slot twice — once at interval 4 and again at interval 0 — and the has_proposal flag change alters store attestation-promotion for syncing nodes; both need to be resolved before merging.

The core block-builder refactor and the PreparedBlock predicate are clean and well-tested. However, ValidatorSecretKey::sign is non-mutating (&self), using the slot number as the deterministic OTS leaf index with no guard against reuse. When the fallback path triggers — which happens on any head change between interval 4 and interval 0 — the same XMSS OTS leaf is used to sign two distinct block roots, violating the single-use guarantee the rest of the codebase is built around. Additionally, the refactor accidentally dropped the sync_status.duties_allowed() filter from the has_proposal flag passed to store::on_tick, causing syncing nodes to eagerly promote attestations at interval 0 when they will not actually propose.

crates/blockchain/src/lib.rs — the fallback signing path and the has_proposal flag change both need attention

Important Files Changed

Filename	Overview
crates/blockchain/src/lib.rs	Core actor refactor: introduces pre-build at interval 4, fallback at interval 0, and three shared helpers. The is_proposer flag passed to store::on_tick no longer filters by duties_allowed() (behavioral regression), and the shared build_signed_block helper signs for slot S at interval 4 and potentially again at interval 0 (XMSS OTS reuse risk in the fallback path).
crates/blockchain/src/block_builder.rs	Adds PreparedBlock struct and prebuilt_block_is_usable predicate with thorough unit tests. Logic is clean and well-exercised; no issues found.
crates/blockchain/src/store.rs	Splits produce_block_with_signatures into a new produce_block_on_head variant that accepts an already-resolved head root without ticking the store clock. get_proposal_head is made pub(crate) with clear documentation. Changes are correct and well-scoped.

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart TD
    A[Slot S-1 Interval 4] --> B[prebuild_block next_slot=S]
    B --> C[produce_block_on_head READ-ONLY store.head]
    C --> D[sign_block_root vid slot=S root_A OTS index S consumed]
    D --> E[stash PreparedBlock slot=S]
    E --> F[advance_keys_to S]
    F --> G[Slot S Interval 0]
    G --> H[get_proposal_head ticks store clock]
    H --> I{prebuilt_block_is_usable?}
    I -->|yes| J[process_block prepared]
    J -->|ok| K[publish pre-built block FAST PATH]
    J -->|fail| L[fallback build_signed_block]
    I -->|no - head moved| L
    L --> M[sign_block_root vid slot=S root_B WARNING same OTS index S reused]
    M --> N[publish fallback block]

Loading

%%{init: {'theme': 'base', 'themeVariables': {"darkMode": true, "background": "#0d1117", "primaryColor": "#21262d", "primaryTextColor": "#e6edf3", "primaryBorderColor": "#8b949e", "lineColor": "#8b949e", "textColor": "#e6edf3", "edgeLabelBackground": "#161b22", "actorBkg": "#21262d", "actorBorder": "#8b949e", "actorTextColor": "#e6edf3", "actorLineColor": "#8b949e", "signalColor": "#8b949e", "signalTextColor": "#e6edf3", "noteBkgColor": "#373320", "noteBorderColor": "#d4a72c", "noteTextColor": "#f0e6c0", "labelBoxBkgColor": "#21262d", "labelBoxBorderColor": "#8b949e", "labelTextColor": "#e6edf3", "loopTextColor": "#e6edf3", "activationBkgColor": "#30363d", "activationBorderColor": "#8b949e"}}}%%
flowchart TD
    A[Slot S-1 Interval 4] --> B[prebuild_block next_slot=S]
    B --> C[produce_block_on_head READ-ONLY store.head]
    C --> D[sign_block_root vid slot=S root_A OTS index S consumed]
    D --> E[stash PreparedBlock slot=S]
    E --> F[advance_keys_to S]
    F --> G[Slot S Interval 0]
    G --> H[get_proposal_head ticks store clock]
    H --> I{prebuilt_block_is_usable?}
    I -->|yes| J[process_block prepared]
    J -->|ok| K[publish pre-built block FAST PATH]
    J -->|fail| L[fallback build_signed_block]
    I -->|no - head moved| L
    L --> M[sign_block_root vid slot=S root_B WARNING same OTS index S reused]
    M --> N[publish fallback block]

Loading

Prompt To Fix All With AI

Fix the following 3 code review issues. Work through them one at a time, proposing concise fixes.

---

### Issue 1 of 3
crates/blockchain/src/lib.rs:560-562
**XMSS OTS key reuse in fallback path**

`prebuild_block` at interval 4 calls `sign_block_root(validator_id, slot=S, &block_root_A)`, then if `prebuilt_block_is_usable` returns false at interval 0, the fallback calls `build_signed_block` → `sign_block_root(validator_id, slot=S, &block_root_B)` — same `slot` argument, different message. `ValidatorSecretKey::sign` takes `&self` (non-mutating) and calls `LeanSignatureScheme::sign(&self.inner, slot, …)` deterministically from the OTS leaf at index `slot`, with no internal "already used" guard. Two distinct messages signed under the same OTS leaf violates the W-OTS+/XMSS single-use guarantee; if both signatures are ever visible to an attacker (e.g., via in-memory recovery or a future change that inadvertently publishes the pre-build), signing keys are compromisable. The PR's own description flags OTS-index reuse as a non-negotiable constraint, yet this fallback path triggers it whenever the head changes between interval 4 and interval 0.

### Issue 2 of 3
crates/blockchain/src/lib.rs:259-265
**`has_proposal` flag now ignores sync status**

The old code filtered `scheduled_proposer` through `sync_status.duties_allowed()` before passing the flag to `store::on_tick`. The new code passes `is_proposer = scheduled_proposer.is_some()` without that filter, so a syncing node that happens to be the scheduled proposer now passes `has_proposal = true`, causing `store::on_tick` to call `accept_new_attestations` at interval 0 even though no block will be built. The old behavior deliberately withheld this early promotion while syncing.

```suggestion
        let scheduled_proposer = (interval == 0 && slot > 0)
            .then(|| self.get_our_proposer(slot))
            .flatten();
        let is_proposer = scheduled_proposer.is_some()
            && self.sync_status.duties_allowed();

        // Tick the store first - this accepts attestations at interval 0 if we have a proposal
        store::on_tick(&mut self.store, timestamp_ms, is_proposer);
```

### Issue 3 of 3
crates/blockchain/src/lib.rs:460-464
**Double `coverage::emit_proposal_coverage` emission**

`build_signed_block` calls `coverage::emit_proposal_coverage` unconditionally. This function is invoked at interval 4 (pre-build) and potentially again at interval 0 (fallback). If the pre-built block passes `prebuilt_block_is_usable` but `process_and_publish_block` returns false (local import failure), the fallback calls `build_signed_block` a second time, emitting proposal-coverage metrics twice for the same slot. Consider moving the coverage emission into `process_and_publish_block` (after a successful local import) so it fires exactly once per published block.

_{Reviews (1): Last reviewed commit: "feat(blockchain): pre-build proposer blo..." | Re-trigger Greptile}