Raft determines which commands commit, and in what order. Verify mode adds a requirement: a voting follower must verify execution of the commands it acknowledges before confirming replication. The same requirement applies to non-voting replicas that may later be promoted.

Verify mode: simulate, verify, commit and apply. Simulation leaves business state unchanged. Each node applies committed commands; the leader returns the final result after its entire batch is applied.
Verify mode: simulate, verify, commit and apply. Simulation leaves business state unchanged. Each node applies committed commands; the leader returns the final result after its entire batch is applied.

Simulation results can be reused only when the starting state, inputs and expected results match exactly. A follower that fails verification cannot acknowledge replication; the cluster does not silently fall back to weaker checking.

Commit and apply are separate steps. Commit means a quorum has durably stored the command at a fixed position in the log. Apply means a node has executed the command and updated its business state. Clients receive final results after apply.

A learner that the initial cluster configuration permanently bars from promotion may acknowledge durable replication before executing business logic. Its acknowledgment does not count toward the quorum, but it still executes and validates every committed command. Learners that may be promoted perform the same pre-acknowledgment verification as voting followers.

One linearizable transaction history per cluster

Transactions from all clients enter one ordered history. A completed transaction precedes transactions invoked after its completion; Raft orders concurrent transactions. Replicas may temporarily lag, but replaying the same committed history with the same plugin version yields the same state.

This guarantee covers the transaction core. Reads from a lagging replica or an asynchronously updated query view may return stale data. Raft establishes the order; Verify mode checks execution.

A verifiable chain of transaction history

Each transaction in the committed history has a global sequence number (tx_seq) and a chain hash (tx_chain_hash). The chain hash works like the hash links between blocks in a blockchain: it is computed from the previous chain hash, the transaction’s sequence number, an identifier bound to its original input, and a hash of its result. Altering an earlier input or result changes every subsequent chain hash, assuming a collision-resistant hash function.

Previous chain hash＋Sequence number, input identifier & result hash→Next chain hash

To audit, replay the archived inputs with the matching plugin versions and compare each recomputed chain hash with the recorded one. Verify mode has followers compare results before commit; Performance mode computes the chain when it executes committed commands. The chain covers global transaction history, while a record revision tracks changes to a single record.

Auditing needs an independently trusted starting state and hash, plus archived inputs and plugin versions. A hash alone cannot reconstruct discarded history.

Verify mode detects divergence between replicas. It does not detect a business-logic defect shared by all replicas and does not defend against malicious replicas. A single-voter cluster has no independent follower verification. The replication log is still synced to disk as required; writes from a single Raft processing step may be combined, but syncs are not delayed to wait for later client batches. Power-loss safety still requires suitable storage and testing.