Appendix B: Consensus Specification
Specter's consensus layer is built on CometBFT (formerly Tendermint Core), integrated through the Cosmos SDK v0.53+ application framework. This appendix details the consensus parameters, fault-tolerance guarantees, and finality properties of the network.
Consensus Engine
| Parameter | Value |
|---|---|
| Engine | CometBFT |
| SDK version | Cosmos SDK v0.53+ |
| Chain ID | 5446 |
| Target block time | ~5 seconds |
| Finality model | Instant (deterministic) |
Byzantine Fault Tolerance
CometBFT provides BFT safety under the standard assumption:
The network tolerates f < n/3 Byzantine validators, where n is the total number of validators weighted by stake.
As long as fewer than one-third of the total voting power is controlled by faulty or malicious validators, the protocol guarantees that:
- No two conflicting blocks are committed at the same height.
- Every committed block is final and will never be reverted.
If the Byzantine threshold is exceeded, the protocol halts (liveness failure) rather than committing conflicting state (safety is preserved).
Three-Phase Commit
Each block progresses through three sequential phases:
Phase 1: Propose
A designated proposer (selected via weighted round-robin) assembles a candidate block from the mempool and broadcasts it to all validators.
Phase 2: Prevote
Each validator evaluates the proposed block against application-level validity rules (including ZK proof verification, nullifier uniqueness, and Merkle root consistency). If the block is valid, the validator broadcasts a prevote for the block. Otherwise, it prevotes nil.
Threshold: A block advances to precommit only after receiving prevotes from validators representing 2/3+ of total voting power.
Phase 3: Precommit
After observing sufficient prevotes, each validator locks on the block and broadcasts a precommit. If a validator has not seen 2/3+ prevotes, it precommits nil.
Threshold: The block is committed only after receiving precommits from validators representing 2/3+ of total voting power.
Once 2/3+ precommits are collected, the block is appended to the chain and the application state is finalized.
Instant Finality
Unlike proof-of-work or longest-chain proof-of-stake protocols, CometBFT provides instant deterministic finality. A transaction included in a committed block is final from the moment the block is committed — there is no probabilistic confirmation period, no reorganization risk, and no need to wait for additional block confirmations.
This property is critical for the Ghost Protocol, where:
- Merkle roots must be authoritative the instant they are published; clients generate ZK proofs against a specific root and cannot tolerate that root being reverted.
- Nullifiers must be permanently recorded on first appearance; a chain reorganization could re-enable a spent nullifier, breaking double-spend protection.
- Commitment cooldowns (5 seconds per address) align naturally with the block time, ensuring at most one commitment per address per block.
Validator Set
The validator set is managed through the Cosmos SDK staking module. Validators bond GHOST tokens and participate in consensus proportional to their bonded stake. Validator additions, removals, and stake changes take effect at epoch boundaries following the standard CometBFT validator update protocol.