Skip to content

perf(rpc): preserve coinbase precomputation when ZIP 234 reissuance starts #1086

Description

@evan-forbes

Motivation

Preserve the getblocktemplate long-poll fast path when ZIP 234 reissuance starts. This is deferred performance work, not a blocker for NU7 activation.

The current NU7 stack schedules the default mainnet reissuance start around February 2031. Before that start, the stack retains coinbase precomputation. Configured test networks can activate reissuance earlier. Recheck the schedule and accounting rules before implementing this fix.

On split/859-reissuance-rpc at 54094c64a, crates/zakura-rpc/src/methods.rs:2987 disables coinbase precomputation when is_zip234_active(precomputed_height) is true. After a tip change, the RPC then builds the provisional empty-block coinbase inline. Shielded rewards require proof generation, so miners must wait for that build before receiving work on the new tip. We have not benchmarked the added latency on the current stack.

Proposed fix

Predict the next tip's issuance deficit while waiting for a tip change. Validate that prediction against committed state before reusing the precomputed coinbase.

For a child that claims its full available reward, including fees, with no additional burn, the current accounting gives:

child_deficit = parent_deficit - reissuance_bonus(parent_deficit)

Before reissuance starts, the bonus is zero. Before NU7, the deficit accounting records no change. The predictor therefore carries the parent deficit through both regimes.

  1. Add full_claim_child_issuance_deficit(network, child_height, parent_deficit) beside parent_issuance_deficit in crates/zakura-chain/src/parameters/network/subsidy.rs. Use the existing bonus calculation and checked amount arithmetic.
  2. At tip height h, predict the deficit after the child at h+1. Pass that prediction to the zero-fee coinbase build for height h+2.
  3. Carry the prediction alongside the precomputed coinbase through the long-poll wait.
  4. After fetching chain information on wakeup, reuse the coinbase only if the candidate height and actual parent deficit match the prediction. Extend the existing wrong-height discard in methods.rs.
  5. Fall back to the existing inline build when prediction fails or either check mismatches. Preserve error propagation. Do not require a deficit before the subsidy calculation needs one.

Underclaims, unclaimed fees, burns, and unexpected tip changes can invalidate the prediction. The committed-state check makes prediction accuracy a performance concern rather than a validity assumption.

With the same network, height, miner parameters, zero fees, and parent deficit, the precomputed coinbase remains valid for the new template. Shielded construction uses randomness, so a fresh inline build need not produce identical bytes. Construct the template roots from the selected coinbase and the actual chain information, as the existing path does.

This change should add no state request and change no consensus validation rule.

Testing

  • Compare the predictor with block accounting for full-claim blocks before NU7, after NU7 but before reissuance, and after reissuance starts.
  • Cover the reissuance start boundary explicitly: the new tip's height controls its deficit change; the candidate height controls the candidate subsidy.
  • Cover zero deficit and rounding at small deficits.
  • Verify that an active-height long poll reuses the precomputed coinbase after a matching full-claim tip. Assert reuse of that specific transaction, rather than equality with an independently randomized build.
  • Verify that underclaims or burns cause a deficit mismatch and a valid inline fallback.
  • Retain coverage for wrong-height notifications and reorgs.
  • Measure shielded tip-change response latency before and after the fix on a network configured for active reissuance.

Related work

The issue tracks a follow-up to split/859-reissuance-rpc. The published ZIP 234 draft describes issuance smoothing and still lists its deployment height as TBD. The February 2031 timing and deficit-based bonus described here refer to this stack's implementation.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions