Consensus: Fail closed on Spark batch verification

[reubenyap]

PR intention

Make deferred Spark batch proof verification fail closed before validation state is persisted as accepted.

This PR is the first security-first step toward improving Spark-era reindex performance. It keeps Spark proof batching available for old blocks, where doing every proof immediately is expensive, while ensuring that any deferred batch must be verified successfully before the node writes durable validation state or marks reindexing complete.

Why this is desirable

Reindexing becomes noticeably slower once Spark-era blocks are reached because Spark spend validation has expensive cover-set and proof-verification work. The existing batching mode is intended to reduce that cost by collecting Spark spend proofs from old blocks and verifying them together instead of doing every proof immediately block by block.

That performance direction is desirable, but the deferred-verification boundary needs to be explicit and fail-closed before further optimization. If a node is allowed to continue writing chainstate, block-index state, or the reindex completion flag while Spark proofs are still pending, then the local durable state can get ahead of the proof-verification result. In particular, a crash or restart during a long sync permanently skips verification of the proofs that were pending in memory, because the batch container does not survive the restart while the flushed chainstate does. In addition, the old throwing failure path could be swallowed entirely when batch verification was reached from the network message thread (ProcessMessages() catches and continues), making the previous failure mode effectively fail-open.

This PR makes the invariant visible in the validation layer so future reindex-speed work can build on it safely.

Existing behavior this avoids

In the current codebase, when -batching is enabled and the node is processing blocks older than one day, Spark spends may be collected into the batch container instead of being fully verified immediately. ConnectBlock() finalizes the per-block collection, and ActivateBestChain() only runs the batch verifier when it leaves the old-block batching mode.

That means a long reindex or initial sync can accumulate pending Spark proof work while other validation paths continue. Periodic/full flushes and the reindex completion path did not explicitly require those pending Spark proofs to be verified first. The old batch verifier also reported failure by throwing from batch_spark(), which made failure handling depend on where verification happened rather than on a clear validation-state result.

The old failure path was also unhelpful to the operator: when it did crash the node, a plain restart redid the reindex/sync and ran into the same batched failure again, and the only way to learn which spend was invalid was a manual diagnostic reindex with -batching=0.

The undesirable part is not batching itself. Batching is useful for performance. The undesirable part is that deferred proof verification was not clearly coupled to the persistence boundaries that make validation progress durable, and that failure gave the operator neither the offending transaction nor a working plain-restart path.

Code changes brief

• Make Spark batch verification return success/failure instead of throwing from the batch verifier path; remove the now-unused BatchProofContainer::verify() and make batch_spark() private.
• Add BatchProofContainer::verify_pending() to discard in-progress per-block collection and verify the pending batch explicitly.
• Preserve pending Spark spends on verification failure, and latch the failure (fBatchFailed) so the abort path fails fast at later boundaries instead of re-running full proof verification; removing spends from the pending batch (e.g. by disconnect) clears the latch so the changed batch is re-verified.
• Record the txid alongside each collected proof; when a batch fails, re-verify the retained proofs individually (the cover sets are already built) and log the exact invalid spend transactions to debug.log, so the operator does not need a diagnostic reindex to identify the offender.
• Write a one-shot sparkbatchfailed marker file in the datadir when a pending batch fails; on the next start the node consumes it in AppInitMain (right after fReindex is determined, before any database is opened) and forces -batching=0 for that run, so a restart re-verifies Spark proofs block by block and rejects the invalid block through the normal consensus path instead of looping into the same batched abort. A datadir file rather than a block-tree DB flag so the marker survives the database wipe of a run restarted with -reindex.
• Add VerifyPendingSparkBatch() as a validation-layer guard that aborts the node with a recovery hint if pending Spark proofs fail.
• Require pending Spark batch verification before durable block-index/chainstate/evoDb flushes and the prune flag in FlushStateToDisk().
• Require pending Spark batch verification before connecting a non-batched (recent) block in ActivateBestChainStep().
• Require pending Spark batch verification (under cs_main) before clearing the reindex flag in ThreadImport().
• Share the one-day batching predicate between ConnectBlock() and the new guard via ShouldBatchSparkProofs() so the collector and the guard cannot silently diverge.
• Shutdown needs no separate check: the final FlushStateToDisk() is already guarded and refuses to persist validation state if the pending batch fails, while node teardown still completes cleanly.
• Keep normal batching behavior intact so this PR does not deliberately regress Spark-era reindex speed.

Security and correctness notes

This PR does not change Spark consensus rules, proof construction, cover-set selection, or the underlying Spark verifier. It only changes when a deferred batch must be forced to a verification result and how that result is propagated. Cover sets for the batch are still built with GetCoinSet() exactly as before; supersets are safe because the batch verifier slices each proof's set by its recorded size.

The failure mode is intentionally fail-closed: if a pending Spark batch fails verification, the node logs the invalid spend txids, persists the one-shot sparkbatchfailed marker, and aborts instead of persisting validation progress past that point. On the next start batching is disabled automatically for that run, so the invalid spend is rejected through normal block-by-block verification without operator intervention; restarting manually with -reindex -batching=0 remains available as a diagnostic path.

The PR also keeps failed batch contents in memory rather than clearing them, so a failure does not silently discard the evidence needed by the current process to remain stopped at the failed deferred-verification boundary.

Tests

• spark_batch_tests (Boost unit test, src/test/spark_batch_test.cpp): drives real wallet-created Spark spends through the deferred path — collection instead of inline verification, successful batch verification of a valid proof, fail-closed behavior with retained proofs when cover sets cannot be rebuilt, the failed-batch latch, and recovery in both removal shapes: removing the only offending spend from a mixed valid/invalid batch (the remaining valid proof verifies again) and removal that empties the batch.
• spark_batching.py (regtest): mines a Spark chain with timestamps older than one day, performs Spark mints and spends, then reindexes with -batching=1 and asserts the node batch-verified the spends (via debug.log) and reached the same tip as a -batching=0 reindex.

Intended follow-up speed optimization

After this fail-closed boundary is reviewed and merged, the real reindex-speed work should focus on reducing repeated Spark anonymity-set history work while preserving the same verification result: resolve each unique cover-set reference once per pending batch instead of once per spend, bind cached entries to the exact group/reference block data they were derived from, invalidate across disconnect/reorg and forced verification boundaries, and keep -batching=0 as the conservative diagnostic path. This PR intentionally prepares the correctness boundary first so the later cache/de-duplication work can optimize without weakening verification integrity.

Scope

This is deliberately minimal: the consensus-code diff is confined to the batch container, the VerifyPendingSparkBatch() guard and its call sites, and the failure-recovery marker consumed at startup. It does not add the larger cover-set metadata cache or broader Spark reindex acceleration yet.

Validation

• git diff --check across the touched files.
• src/batchproof_container.cpp syntax-checked locally; full builds, unit tests, and RPC tests run in CI (the environment used to author this cannot fetch the bls-dash/tor depends).

[coderabbitai]

Note

Reviews paused

It looks like this branch is under active development. To avoid overwhelming you with review comments due to an influx of new commits, CodeRabbit has automatically paused this review. You can configure this behavior by changing the reviews.auto_review.auto_pause_after_reviewed_commits setting.

Use the following commands to manage reviews:

• @coderabbitai resume to resume automatic reviews.
• @coderabbitai review to trigger a single review.

Use the checkboxes below for quick actions:

• ▶️ Resume reviews
• 🔍 Trigger review

Walkthrough

Pending Spark proof verification now returns explicit success or failure, retains failed batches for fail-closed behavior, and runs at validation, flush, shutdown, and reindex boundaries. Unit and RPC tests cover failure recovery and reindex batching.

Changes

Spark Batch Proof Verification Hardening

Layer / File(s)	Summary
BatchProofContainer pending verification API src/batchproof_container.h, src/batchproof_container.cpp	Replaces verify() with verify_pending(), changes batch_spark() to return bool, clears finalized temporary transactions, and retains failed batches after verification errors.
Validation boundary checks src/validation.h, src/validation.cpp	Adds VerifyPendingSparkBatch() and ShouldBatchSparkProofs(). Pending batches are verified before durable flushes and before connecting blocks outside the batching path.
Reindex and shutdown integration src/init.cpp	Defers shutdown verification to the flush path and verifies pending Spark batches before clearing reindex state.
Unit and RPC regression coverage src/test/spark_batch_test.cpp, src/test/CMakeLists.txt, qa/rpc-tests/spark_batching.py, qa/pull-tester/rpc-tests.py	Adds fail-closed unit coverage and reindex batching coverage, including the new RPC test in the default suite.

Estimated code review effort: 3 (Moderate) | ~25 minutes

Suggested labels: Spark

Suggested reviewers: psolstice, levoncrypto, levonpetrosyan93

🚥 Pre-merge checks | ✅ 4 | ❌ 1

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 14.29% which is insufficient. The required threshold is 80.00%.	Write docstrings for the functions missing them to satisfy the coverage threshold.

✅ Passed checks (4 passed)

Check name	Status	Explanation
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Title check	✅ Passed	The title is concise and accurately captures the main change: fail-closed Spark batch verification.
Description check	✅ Passed	The description includes the required PR intention section and a substantial code changes brief, plus extra supporting details.

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch codex/spark-batch-fail-closed

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[coderabbitai]

Actionable comments posted: 2

🧹 Nitpick comments (3)

src/batchproof_container.cpp (1)

28-35: 💤 Low value

Clarify the conditional logic in verify() with a comment.

The current logic returns true (success) when fCollectProofs is true, which skips batch verification. This appears intentional—when proofs are still being collected, there's nothing finalized to verify yet—but the conditional is non-obvious. A brief comment would help future readers understand this is expected behavior rather than a bug.

📝 Suggested comment

 bool BatchProofContainer::verify() {
     if (fCollectProofs) {
+        // Still in collection mode; nothing finalized to verify yet.
         fCollectProofs = false;
         return true;
     }
 
     return batch_spark();
 }

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@src/batchproof_container.cpp` around lines 28 - 35, The verify() method in
BatchProofContainer has a non-obvious conditional that returns true when
fCollectProofs is true, which skips batch verification. Add a clarifying comment
above or within the if (fCollectProofs) block explaining that this early return
is intentional because when proofs are still being collected, there is nothing
finalized to verify yet, so the function returns success without performing the
actual batch verification that happens in the batch_spark() call.

src/validation.cpp (2)

2237-2246: ⚡ Quick win

Document the aborting verification boundary.

VerifyPendingSparkBatch is now a cross-layer helper with non-obvious side effects: it verifies pending proofs, aborts the node, starts shutdown, and mutates state on failure. Please add a Doxygen contract that captures the guarded boundary and caller preconditions.

Suggested documentation

+/**
+ * Verify any deferred Spark proof batch before crossing a durable validation boundary.
+ *
+ * `@param` state Validation state populated when verification fails.
+ * `@param` reason Human-readable operation being guarded, used in diagnostics.
+ * `@return` true if no pending batch exists or verification succeeds; false after aborting the node.
+ * `@pre` Call before persisting or publishing state that depends on the pending Spark batch.
+ */
 bool VerifyPendingSparkBatch(CValidationState& state, const std::string& reason)

As per coding guidelines, “Use Doxygen-compatible comments with @param, @return, and @pre tags for function documentation.”

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@src/validation.cpp` around lines 2237 - 2246, Add Doxygen documentation to
the VerifyPendingSparkBatch function that documents its contract and side
effects. Include tags for `@param` describing the CValidationState reference and
reason string parameter, `@return` describing the boolean return value indicating
success or failure, and `@pre` describing caller preconditions. The documentation
should clearly capture that this function verifies pending Spark proofs, may
abort the node and trigger shutdown on verification failure, and will mutate the
state parameter when verification fails, so callers understand the cross-layer
behavior and non-obvious side effects involved.

Source: Coding guidelines

---

3098-3099: 🏗️ Heavy lift

Avoid doing Spark batch verification inside the disk-flush lock scope.

FlushStateToDisk holds cs_main and cs_LastBlockFile from Line 3051, so Line 3098 can now run expensive Spark proof verification while blocking validation and block-file operations. Consider restructuring this into a smaller scoped lock/retry boundary: compute that a durable write is needed, release the locks for VerifyPendingSparkBatch, then reacquire/recompute before writing so the fail-closed guarantee is preserved without extending the critical section.

As per coding guidelines, “Scope lock regions carefully with braces to minimize critical sections,” and the PR context identifies Spark proof verification as expensive.

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@src/validation.cpp` around lines 3098 - 3099, The VerifyPendingSparkBatch
call at line 3098 is executing while holding the cs_main and cs_LastBlockFile
locks (acquired at line 3051), which blocks validation and block-file operations
during expensive Spark proof verification. Restructure the FlushStateToDisk
function to move the VerifyPendingSparkBatch call outside the critical section:
first determine whether a durable write is needed with the locks held, then
release both cs_main and cs_LastBlockFile, execute VerifyPendingSparkBatch
outside the locks, and finally reacquire the locks before performing the actual
disk write operations. Ensure the fail-closed guarantee is preserved by
recomputing conditions after reacquiring the locks to verify the state has not
changed.

Source: Coding guidelines

🤖 Prompt for all review comments with AI agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In `@src/batchproof_container.cpp`:
- Around line 84-86: The LogPrintf call with the message "Spark batch
verification failed." in the conditional block checking !passed is missing a
trailing newline character, while other LogPrintf calls in the same function
include it for consistent formatting. Add a `\n` character at the end of the log
message string in the LogPrintf call to match the formatting convention used
elsewhere in the function.

In `@src/validation.cpp`:
- Around line 3814-3818: The batch proof verification check via
batchProofContainer->verify() is occurring too late in the validation flow.
Currently it happens after ActivateBestChainStep() returns, which means
ConnectBlock() has already written to pblocktree and ConnectTip() has already
updated wallet/listener state. Move the batchProofContainer->verify() check to
occur before these side effects happen, either by moving it earlier in the code
flow before ActivateBestChainStep() is called, or by restructuring the logic to
defer the durable index writes and state updates until after batch verification
succeeds. This ensures that if verification fails, no side effects like
pblocktree writes or wallet state changes have already been applied.

---

Nitpick comments:
In `@src/batchproof_container.cpp`:
- Around line 28-35: The verify() method in BatchProofContainer has a
non-obvious conditional that returns true when fCollectProofs is true, which
skips batch verification. Add a clarifying comment above or within the if
(fCollectProofs) block explaining that this early return is intentional because
when proofs are still being collected, there is nothing finalized to verify yet,
so the function returns success without performing the actual batch verification
that happens in the batch_spark() call.

In `@src/validation.cpp`:
- Around line 2237-2246: Add Doxygen documentation to the
VerifyPendingSparkBatch function that documents its contract and side effects.
Include tags for `@param` describing the CValidationState reference and reason
string parameter, `@return` describing the boolean return value indicating success
or failure, and `@pre` describing caller preconditions. The documentation should
clearly capture that this function verifies pending Spark proofs, may abort the
node and trigger shutdown on verification failure, and will mutate the state
parameter when verification fails, so callers understand the cross-layer
behavior and non-obvious side effects involved.
- Around line 3098-3099: The VerifyPendingSparkBatch call at line 3098 is
executing while holding the cs_main and cs_LastBlockFile locks (acquired at line
3051), which blocks validation and block-file operations during expensive Spark
proof verification. Restructure the FlushStateToDisk function to move the
VerifyPendingSparkBatch call outside the critical section: first determine
whether a durable write is needed with the locks held, then release both cs_main
and cs_LastBlockFile, execute VerifyPendingSparkBatch outside the locks, and
finally reacquire the locks before performing the actual disk write operations.
Ensure the fail-closed guarantee is preserved by recomputing conditions after
reacquiring the locks to verify the state has not changed.

🪄 Autofix (Beta)

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro

Run ID: 5a7a95f0-1604-4511-a070-ca6ac125bb75

📥 Commits

Reviewing files that changed from the base of the PR and between 7fabe1e and a4d9f1a.

📒 Files selected for processing (5)

• src/batchproof_container.cpp
• src/batchproof_container.h
• src/init.cpp
• src/validation.cpp
• src/validation.h

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: a4d9f1a1b0

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[codeant-ai]

User description

PR intention

Make deferred Spark batch proof verification fail closed before validation state is persisted as accepted.

This PR is the first security-first step toward improving Spark-era reindex performance. It keeps Spark proof batching available for old blocks, where doing every proof immediately is expensive, while ensuring that any deferred batch must be verified successfully before the node writes durable validation state or marks reindexing complete.

Why this is desirable

Reindexing becomes noticeably slower once Spark-era blocks are reached because Spark spend validation has expensive cover-set and proof-verification work. The existing batching mode is intended to reduce that cost by collecting Spark spend proofs from old blocks and verifying them together instead of doing every proof immediately block by block.

That performance direction is desirable, but the deferred-verification boundary needs to be explicit and fail-closed before further optimization. If a node is allowed to continue writing chainstate, block-index state, or the reindex completion flag while Spark proofs are still pending, then the local durable state can get ahead of the proof-verification result. Even if a later verification failure would eventually stop the node, that is the wrong security shape for consensus-sensitive validation: pending privacy-spend proofs should be treated as unaccepted until the deferred batch has passed.

This PR makes that invariant visible in the validation layer so future reindex-speed work can build on it safely.

Existing behavior this avoids

In the current codebase, when -batching is enabled and the node is processing blocks older than one day, Spark spends may be collected into the batch container instead of being fully verified immediately. ConnectBlock() finalizes the per-block collection, and ActivateBestChain() only runs the batch verifier when it leaves the old-block batching mode.

That means a long reindex or initial sync can accumulate pending Spark proof work while other validation paths continue. Periodic/full flushes and the reindex completion path did not explicitly require those pending Spark proofs to be verified first. The old batch verifier also reported failure by throwing from batch_spark(), which made failure handling depend on where verification happened rather than on a clear validation-state result.

The undesirable part is not batching itself. Batching is useful for performance. The undesirable part is that deferred proof verification was not clearly coupled to the persistence boundaries that make validation progress durable.

Code changes brief

• Make Spark batch verification return success/failure instead of throwing from the batch verifier path.
• Add BatchProofContainer::verify_pending() to finalize any collected Spark spends and verify the pending batch explicitly.
• Preserve pending Spark spends on verification failure and clear them only after successful batch verification.
• Add VerifyPendingSparkBatch() as a validation-layer guard that aborts the node with a recovery hint if pending Spark proofs fail.
• Require pending Spark batch verification before durable block-index/chainstate flushes.
• Require pending Spark batch verification before clearing the reindex flag.
• Check pending Spark batch verification during shutdown before the final flush path.
• Keep normal batching behavior intact so this PR does not deliberately regress Spark-era reindex speed.

Security and correctness notes

This PR does not change Spark consensus rules, proof construction, cover-set selection, or the underlying Spark verifier. It only changes when a deferred batch must be forced to a verification result and how that result is propagated.

The failure mode is intentionally fail-closed: if a pending Spark batch fails verification, the node aborts instead of persisting validation progress past that point. The recovery hint remains to restart with -reindex -batching=0, which forces block-by-block verification and helps identify the invalid Spark spend.

The PR also keeps failed batch contents in memory rather than clearing them, so a failure does not silently discard the evidence needed by the current process to remain stopped at the failed deferred-verification boundary.

Intended follow-up speed optimization

After this fail-closed boundary is reviewed and merged, the real reindex-speed work should focus on reducing repeated Spark anonymity-set history work while preserving the same verification result.

The likely next step is to introduce a validation-owned, in-memory Spark batch context/cache for old-block reindex and IBD paths. Instead of having each Spark spend independently walk block history and reconstruct the same cover-set metadata, the batch path should collect the unique Spark cover-set references needed by the pending spends, keyed by the coin group and the referenced accumulator/block hash. The node can then resolve each unique reference once, derive the cover-set size and representation from chain state once, and reuse that derived metadata for all spends in the pending batch.

The batch verifier should likewise avoid rebuilding the same full cover sets repeatedly. For each unique group/reference needed by the pending batch, it should construct or fetch the corresponding derived cover-set data once, then pass those deterministic chain-derived results into the existing Spark proof verifier for the collected spends.

Important security constraints for that follow-up:

• Do not skip Spark proof verification; only avoid repeated derivation of identical inputs to the verifier.
• Do not treat cached data as consensus-authoritative. The cache should be derived from the current chain state and safe to discard/rebuild.
• Bind cached entries to the exact group/reference block data they were derived from, not just to a loose height or mutable tip assumption.
• Clear or invalidate cached entries across disconnect/reorg paths and at forced verification boundaries.
• Preserve the current fail-closed behavior from this PR before any durable validation state is written.
• Keep -batching=0 as the conservative diagnostic path that verifies spends without the deferred batch optimization.

That follow-up is expected to address the practical slowdown around Spark activation much more directly than this PR. This PR intentionally prepares the correctness boundary first so the later cache/de-duplication work can optimize without weakening verification integrity.

Scope

This is deliberately minimal. It does not add the larger cover-set metadata cache or broader Spark reindex acceleration yet. Those optimizations should be easier to reason about after this fail-closed boundary is in place.

Validation

• git diff --check origin/master...HEAD -- src/batchproof_container.cpp src/batchproof_container.h src/init.cpp src/validation.cpp src/validation.h
• Build/tests not run locally because cmake and ninja are not available on PATH in this environment.

---

CodeAnt-AI Description

Fail closed on deferred Spark proof verification before reindex, flush, and shutdown

What Changed

• Spark proof batches are now verified before the node writes durable chainstate or block index updates, clears the reindex flag, or finishes shutdown
• If deferred Spark proof verification fails, the node stops with a clear message telling the user to restart with -reindex -batching=0 to find the invalid spend
• Reindexing no longer completes until any pending Spark proof batch has been checked
• Spark batch verification now reports failure cleanly instead of throwing an exception

Impact

✅ Fewer silent consensus failures during reindex
✅ Safer chainstate and block index writes
✅ Clearer recovery after invalid Spark spends

💡 Usage Guide

Checking Your Pull Request

Every time you make a pull request, our system automatically looks through it. We check for security issues, mistakes in how you're setting up your infrastructure, and common code problems. We do this to make sure your changes are solid and won't cause any trouble later.

Talking to CodeAnt AI

Got a question or need a hand with something in your pull request? You can easily get in touch with CodeAnt AI right here. Just type the following in a comment on your pull request, and replace "Your question here" with whatever you want to ask:

@codeant-ai ask: Your question here

This lets you have a chat with CodeAnt AI about your pull request, making it easier to understand and improve your code.

Example

@codeant-ai ask: Can you suggest a safer alternative to storing this secret?

Preserve Org Learnings with CodeAnt

You can record team preferences so CodeAnt AI applies them in future reviews. Reply directly to the specific CodeAnt AI suggestion (in the same thread) and replace "Your feedback here" with your input:

@codeant-ai: Your feedback here

This helps CodeAnt AI learn and adapt to your team's coding style and standards.

Example

@codeant-ai: Do not flag unused imports.

Retrigger review

Ask CodeAnt AI to review the PR again, by typing:

@codeant-ai: review

Check Your Repository Health

To analyze the health of your code repository, visit our dashboard at https://app.codeant.ai. This tool helps you identify potential issues and areas for improvement in your codebase, ensuring your repository maintains high standards of code health.

[coderabbitai]

♻️ Duplicate comments (1)

src/validation.cpp (1)

3816-3822: ⚠️ Potential issue | 🟠 Major | 🏗️ Heavy lift

Spark batch verification is still placed after connect-side durable effects.

Line 3818 verifies the batch only after ActivateBestChainStep() has completed block connection work. A failed verification at this point can still happen after connection-time persisted/index side effects have already advanced, which weakens the intended fail-closed boundary. The verification gate needs to be enforced before those writes/commits in the connect path, not after step completion.

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@src/validation.cpp` around lines 3816 - 3822, The Spark batch verification
using `batchProofContainer->verify(pindexNewTip->nHeight)` is currently
positioned after `ActivateBestChainStep()` has already persisted block
connection side effects to disk, which violates the fail-closed boundary. Move
the batch verification logic and the fCollectProofs assignment for the
BatchProofContainer instance to occur before the `ActivateBestChainStep()` call
completes, ensuring that the verification gate is enforced before any durable
writes or index commits happen in the connect path rather than after step
completion.

🧹 Nitpick comments (1)

src/validation.cpp (1)

3832-3833: Use pre-increment for the loop iterator.

Line 3832 uses i++; project style here is ++i.

Suggested patch

-            for (unsigned int i = 0; i < block.vtx.size(); i++)
+            for (unsigned int i = 0; i < block.vtx.size(); ++i)
                 GetMainSignals().SyncTransaction(*block.vtx[i], pair.first, i);

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@src/validation.cpp` around lines 3832 - 3833, The for loop iterating through
block.vtx uses post-increment (i++) for the loop iterator, but the project style
requires pre-increment (++i). Change the increment expression in the for loop
condition from i++ to ++i to match the project's coding standards.

Source: Coding guidelines

🤖 Prompt for all review comments with AI agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Duplicate comments:
In `@src/validation.cpp`:
- Around line 3816-3822: The Spark batch verification using
`batchProofContainer->verify(pindexNewTip->nHeight)` is currently positioned
after `ActivateBestChainStep()` has already persisted block connection side
effects to disk, which violates the fail-closed boundary. Move the batch
verification logic and the fCollectProofs assignment for the BatchProofContainer
instance to occur before the `ActivateBestChainStep()` call completes, ensuring
that the verification gate is enforced before any durable writes or index
commits happen in the connect path rather than after step completion.

---

Nitpick comments:
In `@src/validation.cpp`:
- Around line 3832-3833: The for loop iterating through block.vtx uses
post-increment (i++) for the loop iterator, but the project style requires
pre-increment (++i). Change the increment expression in the for loop condition
from i++ to ++i to match the project's coding standards.

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro

Run ID: faa25d77-bcde-4c05-874f-0e23f049fbd0

📥 Commits

Reviewing files that changed from the base of the PR and between a4d9f1a and a92b713.

📒 Files selected for processing (4)

• src/batchproof_container.cpp
• src/batchproof_container.h
• src/validation.cpp
• src/validation.h

🚧 Files skipped from review as they are similar to previous changes (1)

• src/batchproof_container.h

[codeant-ai]

User [email protected] does not have a PR Review subscription.

Go to Team management and add this email to the PR Review subscription.

[coderabbitai]

Actionable comments posted: 2

🧹 Nitpick comments (1)

src/batchproof_container.cpp (1)

28-31: 📐 Maintainability & Code Quality | 🔵 Trivial | 💤 Low value

Use Linux braces for the new method definitions.

Move each opening function brace to its own line. As per coding guidelines, use Linux brace style: new line for function definitions.

Also applies to: 45-85

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@src/batchproof_container.cpp` around lines 28 - 31, Update the new method
definitions in BatchProofContainer, including verify_pending and the methods in
the additional referenced range, to use Linux brace style by placing each
opening function brace on its own line. Preserve the existing method bodies and
behavior.

Source: Coding guidelines

🤖 Prompt for all review comments with AI agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In `@qa/rpc-tests/spark_batching.py`:
- Around line 36-41: Update the reindex wait loop in the batching test to
require both the expected block height and the final batch-verification success
marker when batching=True. Poll both conditions under the existing deadline
before proceeding to the final block count and hash assertions, while preserving
the current height-only behavior for non-batching cases.

In `@src/batchproof_container.h`:
- Around line 35-37: Update BatchProofContainer::remove() to clear fBatchFailed
only when the removal actually erases an element from the pending-proofs vector.
Leave the failure latch unchanged when no proof matches, while preserving the
existing proof-removal behavior.

---

Nitpick comments:
In `@src/batchproof_container.cpp`:
- Around line 28-31: Update the new method definitions in BatchProofContainer,
including verify_pending and the methods in the additional referenced range, to
use Linux brace style by placing each opening function brace on its own line.
Preserve the existing method bodies and behavior.

🪄 Autofix (Beta)

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro Plus

Run ID: 626b5807-bc41-4dc0-89db-a235cc5966d8

📥 Commits

Reviewing files that changed from the base of the PR and between c605406 and a643d13.

📒 Files selected for processing (9)

• qa/pull-tester/rpc-tests.py
• qa/rpc-tests/spark_batching.py
• src/batchproof_container.cpp
• src/batchproof_container.h
• src/init.cpp
• src/test/CMakeLists.txt
• src/test/spark_batch_test.cpp
• src/validation.cpp
• src/validation.h

[reubenyap]

@CodeAnt-AI review

[codeant-ai]

CodeAnt AI is running the review.

[codeant-ai]

CodeAnt AI finished running the review.

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: b872ab9129

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[reubenyap]

CI status on 6140fc0 — the two red checks are infrastructure/flake, not related to this PR's changes:

• linux-cmake-Release (run 30193325400): single failure, llmq-is-cl-conflicts.py — "wait_for_chainlock timed out". This is a timing flake: the sibling run on the exact same commit passed linux-cmake-Release fully, the other four LLMQ tests (llmq-chainlocks, llmq-cl-evospork, llmq-is-retroactive, llmq-signing) passed within the failing run itself, and this PR touches only Spark batch verification — no llmq/ or evo/ code.
• guix-x86_64-linux-gnu: git.savannah.gnu.org is returning 502 on the Guix installer download (ongoing upstream outage, same as previous runs). The other guix jobs got past that step and are still building.

Everything else is green on this commit: mac + windows Release/Debug, and the full RPC suite on the passing linux-cmake-Release run (including the new spark_batching.py). linux-cmake-Debug is still in progress.

I don't have permission to re-run failed jobs, so a maintainer re-run of the two failed jobs would clear the red checks.

---

Generated by Claude Code

[codeant-ai]

🤖 CodeAnt AI — Review Status

Status	Commit	Started (UTC)	Finished (UTC)
✅ Incremental review completed	0195f12	Aug 14, 2026 · 15:27	15:28

[codeant-ai]

User description

PR intention

Make deferred Spark batch proof verification fail closed before validation state is persisted as accepted.

This PR is the first security-first step toward improving Spark-era reindex performance. It keeps Spark proof batching available for old blocks, where doing every proof immediately is expensive, while ensuring that any deferred batch must be verified successfully before the node writes durable validation state or marks reindexing complete.

Why this is desirable

Reindexing becomes noticeably slower once Spark-era blocks are reached because Spark spend validation has expensive cover-set and proof-verification work. The existing batching mode is intended to reduce that cost by collecting Spark spend proofs from old blocks and verifying them together instead of doing every proof immediately block by block.

That performance direction is desirable, but the deferred-verification boundary needs to be explicit and fail-closed before further optimization. If a node is allowed to continue writing chainstate, block-index state, or the reindex completion flag while Spark proofs are still pending, then the local durable state can get ahead of the proof-verification result. In particular, a crash or restart during a long sync permanently skips verification of the proofs that were pending in memory, because the batch container does not survive the restart while the flushed chainstate does. In addition, the old throwing failure path could be swallowed entirely when batch verification was reached from the network message thread (ProcessMessages() catches and continues), making the previous failure mode effectively fail-open.

This PR makes the invariant visible in the validation layer so future reindex-speed work can build on it safely.

Existing behavior this avoids

In the current codebase, when -batching is enabled and the node is processing blocks older than one day, Spark spends may be collected into the batch container instead of being fully verified immediately. ConnectBlock() finalizes the per-block collection, and ActivateBestChain() only runs the batch verifier when it leaves the old-block batching mode.

That means a long reindex or initial sync can accumulate pending Spark proof work while other validation paths continue. Periodic/full flushes and the reindex completion path did not explicitly require those pending Spark proofs to be verified first. The old batch verifier also reported failure by throwing from batch_spark(), which made failure handling depend on where verification happened rather than on a clear validation-state result.

The old failure path was also unhelpful to the operator: when it did crash the node, a plain restart redid the reindex/sync and ran into the same batched failure again, and the only way to learn which spend was invalid was a manual diagnostic reindex with -batching=0.

The undesirable part is not batching itself. Batching is useful for performance. The undesirable part is that deferred proof verification was not clearly coupled to the persistence boundaries that make validation progress durable, and that failure gave the operator neither the offending transaction nor a working plain-restart path.

Code changes brief

• Make Spark batch verification return success/failure instead of throwing from the batch verifier path; remove the now-unused BatchProofContainer::verify() and make batch_spark() private.
• Add BatchProofContainer::verify_pending() to discard in-progress per-block collection and verify the pending batch explicitly.
• Preserve pending Spark spends on verification failure, and latch the failure (fBatchFailed) so the abort path fails fast at later boundaries instead of re-running full proof verification; removing spends from the pending batch (e.g. by disconnect) clears the latch so the changed batch is re-verified.
• Record the txid alongside each collected proof; when a batch fails, re-verify the retained proofs individually (the cover sets are already built) and log the exact invalid spend transactions to debug.log, so the operator does not need a diagnostic reindex to identify the offender.
• Write a one-shot sparkbatchfailed marker file in the datadir when a pending batch fails; on the next start the node consumes it in AppInitMain (right after fReindex is determined, before any database is opened) and forces -batching=0 for that run, so a restart re-verifies Spark proofs block by block and rejects the invalid block through the normal consensus path instead of looping into the same batched abort. A datadir file rather than a block-tree DB flag so the marker survives the database wipe of a run restarted with -reindex.
• Add VerifyPendingSparkBatch() as a validation-layer guard that aborts the node with a recovery hint if pending Spark proofs fail.
• Require pending Spark batch verification before durable block-index/chainstate/evoDb flushes and the prune flag in FlushStateToDisk().
• Require pending Spark batch verification before connecting a non-batched (recent) block in ActivateBestChainStep().
• Require pending Spark batch verification (under cs_main) before clearing the reindex flag in ThreadImport().
• Share the one-day batching predicate between ConnectBlock() and the new guard via ShouldBatchSparkProofs() so the collector and the guard cannot silently diverge.
• Shutdown needs no separate check: the final FlushStateToDisk() is already guarded and refuses to persist validation state if the pending batch fails, while node teardown still completes cleanly.
• Keep normal batching behavior intact so this PR does not deliberately regress Spark-era reindex speed.

Security and correctness notes

This PR does not change Spark consensus rules, proof construction, cover-set selection, or the underlying Spark verifier. It only changes when a deferred batch must be forced to a verification result and how that result is propagated. Cover sets for the batch are still built with GetCoinSet() exactly as before; supersets are safe because the batch verifier slices each proof's set by its recorded size.

The failure mode is intentionally fail-closed: if a pending Spark batch fails verification, the node logs the invalid spend txids, persists the one-shot sparkbatchfailed marker, and aborts instead of persisting validation progress past that point. On the next start batching is disabled automatically for that run, so the invalid spend is rejected through normal block-by-block verification without operator intervention; restarting manually with -reindex -batching=0 remains available as a diagnostic path.

The PR also keeps failed batch contents in memory rather than clearing them, so a failure does not silently discard the evidence needed by the current process to remain stopped at the failed deferred-verification boundary.

Tests

• spark_batch_tests (Boost unit test, src/test/spark_batch_test.cpp): drives real wallet-created Spark spends through the deferred path — collection instead of inline verification, successful batch verification of a valid proof, fail-closed behavior with retained proofs when cover sets cannot be rebuilt, the failed-batch latch, and recovery in both removal shapes: removing the only offending spend from a mixed valid/invalid batch (the remaining valid proof verifies again) and removal that empties the batch.
• spark_batching.py (regtest): mines a Spark chain with timestamps older than one day, performs Spark mints and spends, then reindexes with -batching=1 and asserts the node batch-verified the spends (via debug.log) and reached the same tip as a -batching=0 reindex.

Intended follow-up speed optimization

After this fail-closed boundary is reviewed and merged, the real reindex-speed work should focus on reducing repeated Spark anonymity-set history work while preserving the same verification result: resolve each unique cover-set reference once per pending batch instead of once per spend, bind cached entries to the exact group/reference block data they were derived from, invalidate across disconnect/reorg and forced verification boundaries, and keep -batching=0 as the conservative diagnostic path. This PR intentionally prepares the correctness boundary first so the later cache/de-duplication work can optimize without weakening verification integrity.

Scope

This is deliberately minimal: the consensus-code diff is confined to the batch container, the VerifyPendingSparkBatch() guard and its call sites, and the failure-recovery marker consumed at startup. It does not add the larger cover-set metadata cache or broader Spark reindex acceleration yet.

Validation

• git diff --check across the touched files.
• src/batchproof_container.cpp syntax-checked locally; full builds, unit tests, and RPC tests run in CI (the environment used to author this cannot fetch the bls-dash/tor depends).

---

CodeAnt-AI Description

Fail closed on deferred Spark proof verification before validation state is saved

What Changed

• Deferred Spark proofs are verified before the node writes chain state, completes reindexing, or records pruning progress.
• Failed batches stop validation, retain the failed proofs, and prevent repeated verification attempts until the affected spend is removed.
• Failure logs identify the invalid Spark transaction IDs, and the next restart automatically disables batching so proofs are checked individually.
• Added unit and end-to-end coverage for successful batches, invalid proofs, reindexing, and recovery after removing a failed spend.

Impact

✅ No durable validation state after failed Spark verification
✅ Clearer logs identifying invalid Spark spends
✅ Safer reindex recovery after a batch failure

💡 Usage Guide

Checking Your Pull Request

Every time you make a pull request, our system automatically looks through it. We check for security issues, mistakes in how you're setting up your infrastructure, and common code problems. We do this to make sure your changes are solid and won't cause any trouble later.

Talking to CodeAnt AI

Got a question or need a hand with something in your pull request? You can easily get in touch with CodeAnt AI right here. Just type the following in a comment on your pull request, and replace "Your question here" with whatever you want to ask:

@codeant-ai ask: Your question here

This lets you have a chat with CodeAnt AI about your pull request, making it easier to understand and improve your code.

Example

@codeant-ai ask: Can you suggest a safer alternative to storing this secret?

Preserve Org Learnings with CodeAnt

You can record team preferences so CodeAnt AI applies them in future reviews. Reply directly to the specific CodeAnt AI suggestion (in the same thread) and replace "Your feedback here" with your input:

@codeant-ai: Your feedback here

This helps CodeAnt AI learn and adapt to your team's coding style and standards.

Example

@codeant-ai: Do not flag unused imports.

Retrigger review

Ask CodeAnt AI to review the PR again, by typing:

@codeant-ai: review

Check Your Repository Health

To analyze the health of your code repository, visit our dashboard at https://app.codeant.ai. This tool helps you identify potential issues and areas for improvement in your codebase, ensuring your repository maintains high standards of code health.