Skip to main content

Consensus

If you have ever tried to get a group of friends to agree on where to eat dinner, you have an intuitive sense of the consensus problem. Now imagine those friends might be lying to you. That is Byzantine fault tolerance — and it is the foundation of how Specter keeps everyone honest.

CometBFT: The Short Version​

Specter uses CometBFT (formerly known as Tendermint), one of the most battle-tested consensus engines in the blockchain world. It powers dozens of production chains in the Cosmos ecosystem and has processed billions of dollars in transactions.

The headline number: approximately 5-second finality. When your transaction is confirmed on Specter, it is final — no waiting for 12 confirmations, no worrying about chain reorganizations. Your transaction is settled before you can blink twice.

How a Block Gets Made​

Every consensus round follows a three-phase process. Let's walk through it:

Phase 1: Propose​

A designated proposer (selected in a round-robin fashion, weighted by stake) assembles a block of pending transactions and broadcasts it to all validators. Think of this as someone at the dinner table saying, "How about pizza?"

Phase 2: Prevote​

Each validator examines the proposed block. If the block is valid — transactions are well-formed, the state transitions are correct, the proposer followed the rules — the validator broadcasts a prevote in favor. If more than two-thirds of validators prevote for the same block, the round advances. This is like everyone at the table saying, "Yeah, pizza sounds good."

Phase 3: Precommit​

Once a validator sees that more than two-thirds have prevoted, it broadcasts a precommit — a stronger commitment that it will accept this block. When more than two-thirds of validators precommit, the block is finalized and appended to the chain. Dinner is booked. No take-backs.

Byzantine Fault Tolerance​

The "Byzantine" in BFT refers to the Byzantine Generals Problem — a classic computer science puzzle about reaching agreement when some participants might be actively trying to sabotage the process.

CometBFT provides BFT safety as long as fewer than one-third of validators are malicious:

Safety guarantee: The network tolerates f < n/3 Byzantine (arbitrarily malicious) validators, where n is the total number of validators weighted by stake.

In plain language: as long as more than two-thirds of the staked GHOST is controlled by honest validators, no attacker can cause the network to finalize an invalid block, reverse a finalized transaction, or create a fork. Even if the remaining validators are not just offline but actively trying to break things.

This is a strong guarantee. It means:

  • No double-spending. A finalized transaction stays finalized.
  • No censorship (in the long run). A malicious proposer can delay your transaction for one round, but the next honest proposer will include it.
  • No secret forks. Unlike proof-of-work chains, there is no scenario where two competing chains exist simultaneously without validators being provably at fault (and losing their stake).

Why CometBFT for Privacy?​

You might wonder why the consensus mechanism matters for a privacy-focused chain. The answer is finality.

Privacy systems that use commit/reveal patterns need transactions to be final. If a chain could reorganize after you reveal a commitment, an attacker could observe the reveal, then force a reorg that replays the commitment on a different fork — potentially learning the link between your commit and reveal.

CometBFT's instant finality eliminates this entire class of attacks. Once your commit is in a block, it is permanent. Once your reveal is in a block, it is permanent. No reorgs, no uncertainty, no race conditions. The privacy guarantees of Ghost Protocol rest on this foundation.

Staking and Validator Economics​

Validators secure the network by staking GHOST tokens. The economics are straightforward:

  • Stake to participate. Validators (and their delegators) lock GHOST tokens as collateral.
  • Earn rewards. Honest validators earn a share of transaction fees and block rewards.
  • Risk slashing. Validators who misbehave — double-signing blocks or going offline for extended periods — have a portion of their stake burned. This is the penalty that makes attacks economically irrational.

Delegators can stake their GHOST with a validator they trust, sharing in the rewards (and the risks) without running infrastructure themselves. This makes the network more decentralized by lowering the barrier to participation.