Summary
Mining pools typically strip redundant block validation from their submitblock path as standard practice — they have already validated the block during construction and want to propagate it as fast as possible. Zebra currently re-validates on receipt. We should provide a way for pool operators to skip this redundant validation to reduce submission latency.
Current behaviour
When a pool calls submitblock, Zebra validates the block before propagating it. This adds latency in the critical path between a miner finding a valid nonce and the block reaching the network.
Desired behaviour
Pool operators can opt out of Zebra re-running checks the pool has already performed during block construction. The block is accepted and propagated without the redundant overhead.
Motivation
This is standard practice across the mining industry: pools construct and validate blocks themselves during the block building process, so re-running the same checks at the node adds latency with no benefit. Supporting this natively in Zebra removes a friction point for mining pools migrating from zcashd, and aligns Zebra with how production mining infrastructure actually operates.
Scope — what "skipping validation" does and does not mean
To be explicit: this proposal is about skipping redundant checks that the pool has already performed during block construction — not consensus-critical validation.
The following must continue to run regardless:
- Proof verification (Groth16 / proof system checks)
- Commitment hash checks (block commitments, note commitments)
- Chain context validation (connection to chain tip, reorg handling)
- Any structural integrity checks protecting against malformed input
The intention is to avoid re-running checks the pool operator has provably already performed, not to create a path that bypasses security-relevant validation. The exact set of checks that are safe to skip should be determined during implementation.
Suggested approach
A few implementation options, in rough order of complexity:
- Boolean parameter on
submitblock — e.g. submitblock "hexdata" [skipredundantvalidation=false]. Pools pass true to skip redundant checks. Low disruption, backwards-compatible.
- Zebra config flag — a
mining.skip_redundant_submitblock_validation = true option in zebrad.toml. Pool operators set it once at node configuration time.
- Separate RPC method — e.g.
submitblocklight. More explicit but adds API surface.
Whichever option is chosen, the feature should be restricted to local connections (localhost / unix socket) only. It should not be callable over a remote RPC endpoint even with authentication.
Security considerations
Given that recent vulnerability disclosures have involved validation checks, any implementation of this feature requires:
- A security review identifying exactly which checks would be skipped, with explicit confirmation that none of the skipped checks are relevant to known or suspected vulnerability classes
- The feature restricted to localhost / unix socket to limit the attack surface
- Prominent logging when a block submitted via this path is subsequently found invalid by the network, so pool operators are alerted to construction bugs immediately
References
- Related: similar behaviour is standard in Bitcoin mining pools (BIP22).
Summary
Mining pools typically strip redundant block validation from their
submitblockpath as standard practice — they have already validated the block during construction and want to propagate it as fast as possible. Zebra currently re-validates on receipt. We should provide a way for pool operators to skip this redundant validation to reduce submission latency.Current behaviour
When a pool calls
submitblock, Zebra validates the block before propagating it. This adds latency in the critical path between a miner finding a valid nonce and the block reaching the network.Desired behaviour
Pool operators can opt out of Zebra re-running checks the pool has already performed during block construction. The block is accepted and propagated without the redundant overhead.
Motivation
This is standard practice across the mining industry: pools construct and validate blocks themselves during the block building process, so re-running the same checks at the node adds latency with no benefit. Supporting this natively in Zebra removes a friction point for mining pools migrating from zcashd, and aligns Zebra with how production mining infrastructure actually operates.
Scope — what "skipping validation" does and does not mean
To be explicit: this proposal is about skipping redundant checks that the pool has already performed during block construction — not consensus-critical validation.
The following must continue to run regardless:
The intention is to avoid re-running checks the pool operator has provably already performed, not to create a path that bypasses security-relevant validation. The exact set of checks that are safe to skip should be determined during implementation.
Suggested approach
A few implementation options, in rough order of complexity:
submitblock— e.g.submitblock "hexdata" [skipredundantvalidation=false]. Pools passtrueto skip redundant checks. Low disruption, backwards-compatible.mining.skip_redundant_submitblock_validation = trueoption inzebrad.toml. Pool operators set it once at node configuration time.submitblocklight. More explicit but adds API surface.Whichever option is chosen, the feature should be restricted to local connections (localhost / unix socket) only. It should not be callable over a remote RPC endpoint even with authentication.
Security considerations
Given that recent vulnerability disclosures have involved validation checks, any implementation of this feature requires:
References