feat: assumeutxo M2 — EvoDB multi-chainstate isolation and subsystem gating

[PastaPastaPasta]

Issue being fixed or feature implemented

M1 (#7451) added AssumeUTXO snapshot persistence, but Dash stores deterministic masternode, quorum, MNHF, and credit-pool state in a shared EvoDB. Running the snapshot and background chainstates concurrently therefore requires independent EvoDB transaction state and markers, chain-aware Dash validation, and protection against emitting or signing from the wrong chainstate.

This is milestone 2 of the AssumeUTXO series. It supplies the Dash-specific multi-chainstate foundation required by the later background-completion and loadtxoutset milestones.

What was done?

• Added stable NORMAL and SNAPSHOT EvoDB identities, each with an independent transaction overlay, root batch, and best-block marker while retaining one physical EvoDB.
• Added WriteDerived for immutable block-derived records. Independently derived values must serialize identically, including values pending in the other chainstate's overlay.
• Wired block connect, disconnect, replay, verification, flushing, and snapshot activation to the calling chainstate's EvoDB identity. Snapshot activation now refuses a missing EvoDB marker instead of attaching snapshot coins to inconsistent Dash state.
• Protected shared mined-quorum commitments from cross-chainstate erasure.
• Passed the validating chainstate through Dash special-transaction and quorum processing. MNHF, asset-unlock, and quorum lookups now evaluate membership relative to the caller's chain instead of implicitly borrowing the active chain.
• Suppressed active-tip, wallet, UI, and deterministic-masternode notifications from background validation. BlockChecked remains ungated because it reports validation results rather than active-tip changes.
• Avoided penalizing peers when this snapshot-backed or pruned node cannot serve otherwise plausible masternode-list or quorum-rotation history.
• Disabled DKG participation and quorum signing while an active snapshot remains unvalidated, including a final guard at the signature-share production boundary and clear RPC/status reporting.
• Canonicalized serialization of block-derived masternode-list diffs and MNHF signals so logically identical values cannot produce false EvoDB mismatches.

Review follow-ups (appended commits):

• A WriteDerived mismatch is local EvoDB corruption, never evidence about the block. It now aborts the node with M_ERROR (matching the existing EvoDbInconsistencyMessage convention) instead of marking the block BLOCK_CONSENSUS-invalid and penalizing the relaying peer. A typed EvoDbInconsistencyError preserves that classification through the catch blocks on the miner, RPC, and MNHF-recomputation paths.
• EvoDB access outside a BeginTransaction scope previously always bound to the NORMAL identity, so transaction-less consumers (RPC, mempool, miner, P2P serving) could not see snapshot-chain records pending in the SNAPSHOT overlay. CEvoDB now tracks a default identity that snapshot activation sets to SNAPSHOT and ResetChainstates resets; the background-completion milestone must reset it to NORMAL at marker promotion (TODO noted in code).
• GetListForBlockInternal no longer fabricates an empty "initial snapshot" masternode list when a diff for a DIP3-active block is missing; it throws instead. The message deliberately carries the IsBlockDataUnavailableError sentinel and is deliberately a plain runtime_error rather than EvoDbInconsistencyError: at that layer a missing diff can be benign (pending in the other chainstate's unflushed overlay, e.g. while serving historical mnlistdiff), so it is reported as unavailable history without penalizing the requesting peer, and only definite mismatches abort the node. Scheduler-thread consumers (CActiveMasternodeManager::UpdatedBlockTip, governance trigger creation) catch it and skip the update, since an uncaught exception there would terminate the node.

Second review round (appended commits):

• bls::bls_legacy_scheme is process-wide, but the correct value belongs to the block being validated. ConnectBlock only saved and committed the flag; it never established it, and ProcessSpecialTxsInBlock switches legacy to basic only when crossing V19 forward. With an active post-V19 snapshot, the background chainstate therefore validated pre-V19 blocks under the basic scheme, and a background disconnect across V19 could commit legacy onto the active chain's consumers. ConnectBlock now enters under the scheme the block's parent left behind, and ConnectTip/DisconnectTip commit it only from the active chainstate.
• The scheduler-thread guards caught every std::exception, so the plain runtime_errors that CDeterministicMNList::ApplyDiff raises for missing removals or updates, duplicate masternodes, and duplicate unique properties were logged as benign unavailable history while the active masternode stayed READY. The unavailable-history condition now has its own BlockDataUnavailableError type and is the only thing those guards (and BuildSimplifiedMNListDiff) catch; everything else propagates exactly as before the guards existed.
• CEvoDB::GetCurrentIdentity() resolved to a process-wide active_transaction, so an open background NORMAL transaction redirected every concurrent transaction-less read away from the active snapshot's overlay. An open transaction is one validation execution context, not a process mode, so it now resolves only for the thread that began it.
• Snapshot state could outlive the chainstate it describes in two ways, both fixed: PopulateAndValidateSnapshot commits the SNAPSHOT best-block and dual-chainstate markers as its last step, so abandoning activation afterwards (e.g. WriteSnapshotBaseBlockhash on an unwritable datadir) left a single-chainstate node carrying both; and -reindex/-reindex-chainstate wiped the shared EvoDB, erasing the SNAPSHOT marker while chainstate_snapshot stayed on disk, so startup failed on the erased marker with advice the user had already followed. Markers are now rolled back on abandoned activation, and the persisted snapshot chainstate's on-disk artifacts are discarded alongside the EvoDB wipe -- the Dash-shaped equivalent of the reindex-time cleanup in assumeutxo (2) bitcoin/bitcoin#27596/assumeutxo: Fix -reindex before snapshot was validated bitcoin/bitcoin#29726, which runs before any chainstate has coins views and so needs no mempool transfer or leveldb-lock dance.

The batch contains the original eight focused commits, a rebase fixture adaptation after the txindex removal, and eight review follow-up commits. The partial Bitcoin Core BlockInfo and ChainstateRole prerequisites were intentionally moved to the later loadtxoutset milestone where their APIs are first consumed.

How Has This Been Tested?

• Added focused EvoDB unit coverage for overlay isolation, tombstones, cross-overlay derived-value checks, independent marker flushing, disk mismatch rejection, and preservation of the legacy NORMAL marker key.
• Added dual-chainstate integration coverage for restart consistency, snapshot-only flushing, shared quorum erasure, chain-aware commitment/quorum lookup, cache-order isolation, and suppression of background notifications.
• Added canonical serialization coverage for deterministic masternode-list diffs.
• Added transaction_less_access_uses_default_identity covering default-identity resolution of transaction-less reads and writes. Known gap: the DIP3-active missing-diff throw has no end-to-end unit test because regtest activates DIP3 at height 432, above the unit-test chain heights; it is covered by the serving-path catch and review.
• Before the stack-only relocation of the two unused Bitcoin prerequisite commits, make check passed and the following functional subset passed: feature_mnehf.py, feature_asset_locks.py, feature_dip3_deterministicmns.py (both modes), feature_llmq_signing.py (both modes), feature_llmq_rotation.py, and rpc_quorum.py.
• After the review follow-up commits: full rebuild plus evo_db_tests, evo_deterministicmns_tests, evo_mnhf_tests, evo_assetlocks_tests, and validation_chainstatemanager_tests pass (20 cases), and lint-circular-dependencies is clean.
• After the second review round (rebased onto develop at e829261): full rebuild clean and the complete test_dash suite passes (815 cases). Each new regression test was negative-controlled -- chainstate_connectblock_bls_scheme fails on both halves of the BLS fix independently, open_transaction_does_not_capture_other_threads fails without the thread scoping, and chainstatemanager_snapshot_discarded_on_reindex reproduces the unrecoverable reindex before the fix.
• Every rewritten commit passes git diff-tree --check.

Breaking Changes

No released-interface changes. Internally, ActivateExistingSnapshot becomes fallible so startup can reject a snapshot chainstate whose EvoDB marker is missing. Two RPC-visible additions while a snapshot is active and unvalidated: masternode status gains a quorumParticipation field and appends a "DKG participation and quorum signing disabled" clause to status, and quorum sign fails with an explanatory error. AbstractEHFManager::Signals changed from std::unordered_map to std::map (canonical serialization); the on-disk encoding is unchanged, but iteration order of EHF signals in getblockchaininfo output is now sorted.

Checklist:

• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas
• I have added or updated relevant unit/integration/functional/e2e tests
• I have made corresponding changes to the documentation (the AssumeUTXO documentation update is part of a later milestone)
• I have assigned this pull request to a milestone

[PastaPastaPasta]

See https://gist.github.com/PastaPastaPasta/c5108775f7b126f88856cde20d7a8556 for ai generated commit by commit explanation.

[github-actions]

This pull request has conflicts, please rebase.

[github-actions]

This pull request has conflicts, please rebase.

[knst]

that's not my final review feedback, I am not determined yet how exactly improve or change this PR or keep it as it is

1. New sanitizers requires chainstate to be replaced to chainmanager; I repeat these changes independently, see fix: multiple asan's finding #7513
   These changes are unrelated to content of 7456 [make evodb multi-chainstate] and I'd like to get them merged independently.

2. conceptually 7456 changes should work and it seems fine for me, concept ACK for me for idea as working.
   Though, I think changes here are not full.

There are several components that are logically part of chainstate, but initialized separately and behave differently.
They are:

• credit_pool_manager (part of CChainstateHelper)
• ehf_manager (part of CChainstateHelper)
• mn_payments (part of CChainstateHelper)
• dmnman. It's initialized inside chainstate, has in dependencies only evodb but many piece of validation of blocks are depends on dmnman
• quorumsman. This class seems as a bit over-complex assuming that multiple chains could exist due to keeping caches inside, see: mapQuorumsCache, scanQuorumsCache, quorumBaseBlockIndexCache. Instead having 2 implementation for chain == nullptr and chain != nullptr maybe better to pull out these members to new object that is part of chainstate?

@PastaPastaPasta what is your thoughts on credit_pool_manager, ehf_manager, mn_payments? I think they should be part of ChainState.

And one more things: you have no plans to make evodb a part of assume-utxo, right?
Though, I think credit_pool_manager and ehf_manager probably should be.

=================

EvoDbIdentity - can I get clarification about this one? it means that one physical file with database will keep several logical copies of evo-db, right?
why not move evodb to chainstate in this case?
Alternativly, would not it be better to keep evodb as a just separate file?

-evodb = std::make_unique<CEvoDB>(db_params);
+m_evodb{std::make_unique<CEvoDB>(db_params, snapshot_base ? "evodb" + std::string{node::SNAPSHOT_CHAINSTATE_SUFFIX} : "evodb")},

[github-actions]

This pull request has conflicts, please rebase.

[github-actions]

This pull request has conflicts, please rebase.

[PastaPastaPasta]

@knst Fable's raw response:

The load-bearing fact his review is missing
Every piece of Dash evo state he lists is a pure function of blocks, keyed by block hash: creditPoolCache is Uint256LruHashMap<CCreditPool> looked up by pindex, mnhfCache likewise, dmnman's MN lists are block-keyed diffs, and quorum composition at base block B depends only on B's ancestry. Both chainstates share one global block index, so this state is chainstate-agnostic by construction — the MN list at height h is identical whether the background chain or the snapshot chain derived it.

The only state that is genuinely per-chainstate is tip tracking: which block each chainstate has flushed up to (best-block markers) and the in-flight transaction/undo stacks for the block currently connecting. That's exactly — and only — what EvoDbIdentity splits. Everything else stays shared, and the overlap becomes a feature: WriteDerived verifies that independently derived payloads agree byte-for-byte, aborting the node on divergence.

That's the frame for answering everything below.

Per-question answers
"EvoDbIdentity — one physical file keeping several logical copies of evo-db, right?"
No — this is the key clarification. One physical DB, one shared copy of all block-derived data (MN diffs, commitments, credit pool, EHF signals). Per-identity there are only: a transaction context (pending batches) and a best-block marker. The committed keyspace is not duplicated; cross-identity writes of the same key are disjoint by construction (background validates ≤ base, snapshot validates > base, seed is flushed at activation), and WriteDerived enforces identity when they do overlap. It's closer to "one ledger, two bookmarks" than "two ledgers."

"Why not move evodb into Chainstate / keep it as a separate suffixed file?"
His suffixed-file suggestion mirrors upstream's chainstate_snapshot dir and is a defensible alternative — but it was considered and has concrete costs:

Completion atomicity. Upstream completion renames chainstate_snapshot → chainstate. A second DB means a second rename that cannot be atomic with the first, which squares the crash-recovery matrix M3's RecoverSnapshotCleanup already has to handle for the chainstate rename alone. The single-DB design completes via PromoteSnapshotMarkers — one atomic batch write, no rename.
Lost cross-validation. With a shared keyspace, background validation incrementally re-derives and cross-checks the snapshot's seeded evo state via WriteDerived, catching a bad snapshot early and localizing the divergence. Separate files reduce this to a single holistic compare at completion.
Duplication. Two files store identical derived data for the overlapping range.
Downgrade safety was designed around the single file: released software ignores chainstate_snapshot and reads the legacy b_b4 marker, so the chainstate dir + legacy marker remain a consistent background pair and downgrade mid-snapshot degrades to background IBD (documented at the top of evodb.h).
"Should credit_pool_manager / ehf_manager / mn_payments (and dmnman) be part of Chainstate?"
I'd argue no, as members — and the series is deliberate about the alternative: managers stay singletons and the calling Chainstate& is threaded through validation ("bind block validation to the calling chainstate"). Reasons: (a) their state is block-keyed, so per-chainstate instances would duplicate identical state and forfeit the cross-check; (b) Chainstate objects are created and destroyed across snapshot activation/completion/ResetChainstates — embedding managers there recreates precisely the lifetime hazards #7513 just fixed, now for every consumer holding a manager reference (mempool, miner, RPC, net); (c) mempool/P2P/RPC need MN-list and quorum answers independent of which chainstate is active, so they'd route through ActiveChainstate()'s embedded members anyway — same shape, more indirection; (d) it forks upstream's Chainstate layout, growing the perpetual backport diff. On dmnman specifically: it's initialized in LoadChainstate/CompleteChainstateInitialization (not "inside chainstate") because reindex has to wipe and recreate it in lockstep with pblocktree — it's a per-load singleton, and [#7471](https://github.com/dashpay/dash/pull/7471) already moved its wiring into ChainstateLoadOptions.

"quorumsman is over-complex; pull the caches into a per-chainstate object?"
I think this reads the caches backwards. mapQuorumsCache/scanQuorumsCache/quorumBaseBlockIndexCache are all keyed by quorum-base block hash or pindex — that's what makes them already correct under multiple chainstates, and shared caching dedupes work where the two chains overlap (everything ≤ base). Per-chainstate cache objects would duplicate memory, recompute on the background chain, and add cache-lifecycle churn when the snapshot chainstate is deleted at completion. The chain == nullptr / != nullptr dual paths in ScanQuorums are a fair complexity complaint, but that's an independent refactor opportunity, not something the assumeutxo work requires or worsens.

"You have no plans to make evodb part of assume-utxo, right? Though credit_pool_manager and ehf_manager probably should be."
This one he'll be glad to hear: the plan is the opposite, and it's already built — he's reviewing M2 in isolation. M4 (assumeutxo/m4-evo-snapshot, fork PR PastaPastaPasta#53) defines evo snapshot format v3: the dump embeds the MN list at the base, quorum commitments and rotation cycles, the credit pool, MNHF/EHF signals, and asset-unlock ranges, with an evo_hash commitment in dumptxoutset output; loadtxoutset seeds evodb from it and background validation cross-checks the seed as it catches up. So credit pool and EHF are exactly where he thinks they should be — in the snapshot, not left behind.

This is based on the context of the full WIP assumeutxo implementation. I think it answers your questions well.

[thepastaclaw]

🔍 Review in progress — actively reviewing now (commit 066fca8)

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: bdd5626c20

ℹ️ 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".

[coderabbitai]

Note

GitHub couldn't provide a complete incremental comparison for this pull request, so CodeRabbit is performing a full review instead. This review may take a little longer.

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 066fca8b4f

ℹ️ 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".

[chatgpt-codex-connector]

Move snapshot gate before masternode tip update

This guard runs after nodeman->UpdatedBlockTip(), so an active masternode that is not yet READY during an unvalidated snapshot can enter CActiveMasternodeManager::UpdatedBlockTip()'s Init(pindexNew) path before the gate is checked; InitInternal() calls GetListForBlock(pindexNew) without the new BlockDataUnavailableError catch, and that uncaught exception is on the scheduler validation callback path. In the same missing-history snapshot scenario this gate is meant to suppress, the node can terminate before DKG/signing is disabled, so check IsSnapshotActiveAndUnvalidated() before calling nodeman or catch the unavailable-list exception in the init path as well.

AGENTS.md reference: AGENTS.md:L168-L170

Useful? React with 👍 / 👎.

[coderabbitai]

Actionable comments posted: 3

🧹 Nitpick comments (1)

src/llmq/snapshot.cpp (1)

22-29: 🎯 Functional Correctness | 🔵 Trivial | ⚡ Quick win

Add coverage for unavailability without peer penalization.

GETQUORUMROTATIONINFO already treats is not available (pruned or below an unvalidated snapshot base) as local unavailability, but p2p_quorum_data.py should include a pruned/unvalidated-snapshot request to cover this peer-sparing path.

🤖 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/llmq/snapshot.cpp` around lines 22 - 29, Extend the GETQUORUMROTATIONINFO
coverage in p2p_quorum_data.py with a request for block data that is unavailable
because it is pruned or below an unvalidated snapshot base. Assert that this
local-unavailability response does not penalize the peer, preserving the
existing handling for the error text produced by CheckBlockDataAvailable.

🤖 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/evo/evodb.cpp`:
- Around line 67-74: Update CEvoDB::BeginTransaction so GetContext(identity) and
CEvoDBScopedCommitter construction complete before assigning active_transaction
and active_transaction_thread; only publish transaction state after both
fallible operations succeed, while preserving the existing lock and returned
committer behavior.

In `@src/validation.cpp`:
- Around line 3594-3597: Require this == &m_chainman.ActiveChainstate() in the
UI tip notification conditions for both invalidation handling at
src/validation.cpp lines 3594-3597 and conflicting-chain handling at lines
3699-3702, alongside the existing pindex_was_in_chain checks; leave the
main-signal notifications unchanged.
- Line 2011: Initialize the required pre-disconnect BLS scheme before
UndoSpecialTxsInBlock in src/validation.cpp:2011, while preserving the scheme
transition committed by DisconnectTip; also initialize the pre-connect scheme
before ProcessSpecialTxsInBlock during replay in src/validation.cpp:4655 and
restore the active-chainstate scheme afterward. Add coverage for interrupted
post-V19 snapshot replay and CVerifyDB validation.

---

Nitpick comments:
In `@src/llmq/snapshot.cpp`:
- Around line 22-29: Extend the GETQUORUMROTATIONINFO coverage in
p2p_quorum_data.py with a request for block data that is unavailable because it
is pruned or below an unvalidated snapshot base. Assert that this
local-unavailability response does not penalize the peer, preserving the
existing handling for the error text produced by CheckBlockDataAvailable.

🪄 Autofix

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: 37a9ab73-7488-4e6f-9838-ceae31e6e69a

📥 Commits

Reviewing files that changed from the base of the PR and between e829261 and 066fca8.

📒 Files selected for processing (45)

• src/Makefile.test.include
• src/active/context.cpp
• src/active/context.h
• src/active/dkgsessionhandler.cpp
• src/active/masternode.cpp
• src/dbwrapper.h
• src/evo/assetlocktx.cpp
• src/evo/assetlocktx.h
• src/evo/chainhelper.cpp
• src/evo/chainhelper.h
• src/evo/creditpool.cpp
• src/evo/deterministicmns.cpp
• src/evo/deterministicmns.h
• src/evo/evodb.cpp
• src/evo/evodb.h
• src/evo/mnhftx.cpp
• src/evo/mnhftx.h
• src/evo/smldiff.cpp
• src/evo/smldiff.h
• src/evo/specialtxman.cpp
• src/evo/specialtxman.h
• src/governance/signing.cpp
• src/llmq/blockprocessor.cpp
• src/llmq/blockprocessor.h
• src/llmq/quorumsman.cpp
• src/llmq/quorumsman.h
• src/llmq/signing_shares.cpp
• src/llmq/signing_shares.h
• src/llmq/snapshot.cpp
• src/net_processing.cpp
• src/node/chainstate.cpp
• src/node/miner.cpp
• src/rpc/blockchain.cpp
• src/rpc/masternode.cpp
• src/rpc/quorums.cpp
• src/test/evo_cbtx_tests.cpp
• src/test/evo_db_tests.cpp
• src/test/evo_deterministicmns_tests.cpp
• src/test/util/setup_common.cpp
• src/test/util/setup_common.h
• src/test/validation_chainstate_tests.cpp
• src/test/validation_chainstatemanager_tests.cpp
• src/validation.cpp
• src/validation.h
• src/versionbits.h

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

• src/versionbits.h
• src/Makefile.test.include
• src/llmq/signing_shares.h
• src/test/evo_deterministicmns_tests.cpp
• src/net_processing.cpp
• src/rpc/masternode.cpp
• src/rpc/quorums.cpp
• src/active/context.cpp
• src/node/miner.cpp
• src/llmq/quorumsman.h
• src/dbwrapper.h
• src/governance/signing.cpp
• src/llmq/signing_shares.cpp
• src/rpc/blockchain.cpp
• src/evo/smldiff.cpp
• src/evo/chainhelper.cpp
• src/test/evo_cbtx_tests.cpp
• src/evo/chainhelper.h
• src/evo/creditpool.cpp
• src/evo/assetlocktx.h
• src/evo/mnhftx.cpp
• src/evo/specialtxman.h
• src/active/dkgsessionhandler.cpp
• src/llmq/blockprocessor.h
• src/active/masternode.cpp
• src/evo/deterministicmns.cpp
• src/evo/smldiff.h
• src/test/util/setup_common.cpp
• src/evo/specialtxman.cpp
• src/active/context.h
• src/llmq/quorumsman.cpp
• src/evo/assetlocktx.cpp
• src/test/validation_chainstatemanager_tests.cpp
• src/llmq/blockprocessor.cpp
• src/evo/evodb.h
• src/evo/mnhftx.h

[coderabbitai]

🩺 Stability & Availability | 🟡 Minor | ⚡ Quick win

🧩 Analysis chain

🏁 Script executed:

#!/bin/bash
set -euo pipefail

echo "== locate evodb files =="
fd -a 'evodb\.(cpp|h)$|EvoDb' . || true

echo "== evodb outline =="
ast-grep outline src/evo/evodb.cpp --view expanded || true

echo "== relevant evodb.cpp sections =="
wc -l src/evo/evodb.cpp src/evo/evodb.h
sed -n '1,180p' src/evo/evodb.cpp
echo "== evodb.h =="
sed -n '1,240p' src/evo/evodb.h

echo "== calls to BeginTransaction and active_transaction =="
rg -n "BeginTransaction|active_transaction|active_transaction_thread|CEvoDBScopedCommitter|GetContext|Start|Commit|Rollback" src test contrib -S || true

Repository: dashpay/dash

Length of output: 50369

---

🏁 Script executed:

#!/bin/bash
set -euo pipefail

echo "== evodb.cpp relevant lines =="
wc -l src/evo/evodb.cpp src/evo/evodb.h
sed -n '1,130p' src/evo/evodb.cpp
echo
sed -n '1,220p' src/evo/evodb.h

echo
echo "== focused BeginTransaction/assert usages =="
rg -n "active_transaction|active_transaction_thread|BeginTransaction|GetContext\\(|Commit|Rollback|scoped" src/evo/evodb.* src/test/evo_db_tests.cpp src -g '*.cpp' -g '*.h' -S

echo
echo "== evodb tests relevant sections =="
sed -n '1,120p' src/test/evo_db_tests.cpp
sed -n '120,280p' src/test/evo_db_tests.cpp

Repository: dashpay/dash

Length of output: 50369

---

Set transaction state after fallible construction.

GetContext(identity) and std::make_unique<CEvoDBScopedCommitter> can throw after active_transaction is set. The failed call leaves state without a committer to clear it, so the next BeginTransaction asserts and an in-party transaction may resolve with the stale identity if the caller reuses its thread. Build the context and committer before assigning active_transaction and active_transaction_thread.

🤖 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/evo/evodb.cpp` around lines 67 - 74, Update CEvoDB::BeginTransaction so
GetContext(identity) and CEvoDBScopedCommitter construction complete before
assigning active_transaction and active_transaction_thread; only publish
transaction state after both fallible operations succeed, while preserving the
existing lock and returned committer behavior.

[coderabbitai]

🎯 Functional Correctness | 🟠 Major | 🏗️ Heavy lift

Initialize the BLS scheme in direct replay and verification paths.

ReplayBlocks() and CVerifyDB call DisconnectBlock() directly. ReplayBlocks() also calls RollforwardBlock() directly. These paths bypass the guards in DisconnectTip() and ConnectBlock(). A post-V19 operation can then process BLS data with the scheme left by another chainstate.

• src/validation.cpp#L2011-L2011: establish the required pre-disconnect scheme for direct DisconnectBlock() callers while preserving the transition that DisconnectTip() commits.
• src/validation.cpp#L4655-L4655: establish the required pre-connect scheme before ProcessSpecialTxsInBlock() during replay, then restore the active-chainstate scheme after replay.

Add coverage for interrupted post-V19 snapshot replay and CVerifyDB validation.

📍 Affects 1 file

• src/validation.cpp#L2011-L2011 (this comment)
• src/validation.cpp#L4655-L4655

🤖 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` at line 2011, Initialize the required pre-disconnect BLS
scheme before UndoSpecialTxsInBlock in src/validation.cpp:2011, while preserving
the scheme transition committed by DisconnectTip; also initialize the
pre-connect scheme before ProcessSpecialTxsInBlock during replay in
src/validation.cpp:4655 and restore the active-chainstate scheme afterward. Add
coverage for interrupted post-V19 snapshot replay and CVerifyDB validation.

[coderabbitai]

🎯 Functional Correctness | 🟡 Minor | ⚡ Quick win

Suppress UI tip notifications for background chainstate changes.

GetMainSignals() now checks the active chainstate. The nearby uiInterface.NotifyBlockTip() calls only check pindex_was_in_chain. A background invalidation or chainlock conflict can therefore report its tip as a UI tip update.

• src/validation.cpp#L3594-L3597: require the active-chainstate check in the invalidation UI notification condition.
• src/validation.cpp#L3699-L3702: require the active-chainstate check in the conflicting-chain UI notification condition.

📍 Affects 1 file

• src/validation.cpp#L3594-L3597 (this comment)
• src/validation.cpp#L3699-L3702

🤖 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 3594 - 3597, Require this ==
&m_chainman.ActiveChainstate() in the UI tip notification conditions for both
invalidation handling at src/validation.cpp lines 3594-3597 and
conflicting-chain handling at lines 3699-3702, alongside the existing
pindex_was_in_chain checks; leave the main-signal notifications unchanged.

[knst]

LGTM 066fca8

I'd probably have some comments for code in this PR when I will see assumeutxo M3....assumeutxo M7 but for now I am happy with Fable's responses here: #7456 (comment)

[knst]

I think the name of quorumPparticipation is a bit missleading ; can't figure out better naming.

@thepastaclaw any ideas?