VTA Benchmark
HomeVTA vs BTCDashboardBlock ExplorerTX ExplorerConsensus
Deep Technical Audit

Chain State + UTXO Database / LevelDB Consistency

This audit follows the relationship between the active chain, block index, UTXO state and persistent on-disk database state. The focus is consistency: a node should be able to connect and disconnect blocks while keeping its spendable-output view synchronized with the selected chain.

Chain State

CORE STATE

The active chain and most-work chain determine which blocks form the node's current chain view.

UTXO State

CONSENSUS STATE

Connecting a block consumes referenced outputs and creates new outputs; disconnecting reverses those state transitions.

Disk Consistency

TEST REQUIRED

A full corruption/recovery test needs controlled interruption and direct database verification on the exact VTA release.

Chain State → UTXO State Flow

Block Indexknown blocks Active Chainselected chain Connect Blockconsume/create UTXOs UTXO Viewspendable state Persistent DBon-disk state Consistency invariant The UTXO view must correspond to the currently selected chain, not merely every block the node has ever seen. A reorganization therefore requires both disconnecting old-chain state and connecting new-chain state. Previously verified source paths chainActive / chainMostWork ConnectBlock / DisconnectBlock concepts Evidence gap Controlled LevelDB corruption/recovery and crash-consistency tests not executed.

Audit Matrix

AreaFindingStatus
Block indexThe reviewed VTA source maintains a block index and tracks chain state used for active-chain selection.Source verified
Most-work selectionThe previously reviewed chain comparator orders candidates by chain work, with sequence ordering used as a secondary field.Source verified
Active chainchainActive represents the selected active chain in the reviewed source.Source verified
UTXO connectBlock connection updates spendable-output state by consuming inputs and adding new outputs.Architecture/source path
UTXO disconnectReorganization handling requires reversing old-chain state before applying the competing chain.Architecture/source path
Persistent databaseVTA's wallet/data directories include persistent blockchain state, but this audit does not claim a live forensic inspection of the user's chainstate database.Not directly inspected
LevelDB internalsExact database key schema, batching and flush semantics require release-pinned source tracing.Needs source pin
Crash consistencyNo controlled process-kill / restart experiment was performed during a block-state update.Not measured
Corruption recoveryNo deliberate chainstate corruption or recovery/reindex test was executed.Not measured
Snapshot consistencyA copied database should only be treated as a valid snapshot if the copy procedure and node state are controlled.Operational rule

Release-Pinned Consistency Test Plan

1. Pin exact VTA Core release / commit.
2. Identify chainstate DB implementation and key schema.
3. Start from a disposable synchronized test node.
4. Record active-chain tip and selected UTXO set.
5. Connect a controlled test block.
6. Verify expected UTXO additions/removals.
7. Perform a controlled reorg on a private test network.
8. Verify DisconnectBlock reverses old state.
9. Verify ConnectBlock applies new state.
10. Stop/restart during controlled state updates.
11. Run reindex/recovery procedure.
12. Compare final chain tip + UTXO state with the clean reference node.
Important: This page does not claim that a real VTA chainstate database is corrupted or healthy. It documents the consistency model and identifies the experiments needed to verify crash/recovery behavior.
VTA-specific claims are limited to previously reviewed source paths. Direct LevelDB forensics and crash-consistency behavior require a disposable test node and exact VTA release.