Skip to main content

Consensus

Monolythium uses CometBFT (formerly Tendermint) for Byzantine Fault Tolerant consensus. This guide explains how consensus works.

Overview​

PropertyValue
Consensus engineCometBFT
Block time2 seconds (target)
FinalityDeterministic (instant)
Active validators53
Byzantine tolerance1/3

CometBFT Consensus​

How It Works​

CometBFT uses a multi-round voting process:

1. Propose    → Selected validator proposes a block
2. Prevote    → Validators vote on the proposal
3. Precommit  → Validators commit if 2/3+ prevoted
4. Commit     → Block finalized if 2/3+ precommitted

Deterministic Finality​

Unlike probabilistic finality (Bitcoin, Ethereum PoW):

  • Blocks are final once committed
  • No reorganizations or reversions possible
  • Safe to trust immediately after 1 block

This enables faster confirmation times for exchanges and applications.

Validator Set​

Active Set​

Only the top 53 validators by total stake participate in consensus:

Rank 1-53:  Active (earn rewards, sign blocks)
Rank 54+:   Inactive (no rewards, waiting)

Selection Criteria​

Validators are ranked by total stake:

Total Stake = Self-Delegation + Delegations from Others

Dynamic Updates​

The active set updates each block:

  • Stake changes can move validators in/out
  • No minimum stake to enter (just top 53)
  • Transitions are immediate

Block Production​

Proposer Selection​

Each block has a designated proposer selected deterministically:

Proposer = Weighted random selection based on voting power

Higher-staked validators propose more frequently.

Block Contents​

A block contains:

  • Header (chain ID, height, time, hashes)
  • Transactions (Cosmos and EVM)
  • Evidence (of validator misbehavior)
  • Last commit (signatures from previous round)

Block Size​

Maximum block size: 4 MB (4,194,304 bytes)

This limits transactions per block based on their size.

Voting Power​

Calculation​

Voting Power = Validator's Total Stake / Total Staked

Example with 390M total staked:

ValidatorStakeVoting Power
A39M LYTH10%
B19.5M LYTH5%
C7.8M LYTH2%

Significance​

Voting power determines:

  • Probability of being selected as proposer
  • Weight of votes in prevote/precommit
  • Share of block rewards

Liveness and Safety​

Safety Guarantee​

No conflicting blocks are finalized if:

Byzantine validators < 1/3 of voting power

With 53 validators, up to 17 can be Byzantine without breaking safety.

Liveness Guarantee​

The chain continues producing blocks if:

Online honest validators > 2/3 of voting power

At least 36 honest validators must be online.

Block Time​

Target: 2 Seconds​

# In config.toml
[consensus]
timeout_commit = "2s"

Actual Times​

Block times vary based on:

  • Network latency between validators
  • Proposal propagation time
  • Voting round duration

Typical range: 1.8 - 2.5 seconds.

Rounds and Timeouts​

If a round fails (proposer offline, network issues):

Round 0: timeout_propose = 3s
Round 1: timeout_propose = 3s + 500ms
Round 2: timeout_propose = 3s + 1s
...

Timeouts increase to allow recovery while maintaining progress.

Network Halts​

When Does the Chain Halt?​

The chain stops if:

  • More than 1/3 voting power offline/unresponsive
  • Network partition prevents 2/3 agreement

Recovery​

When the issue is resolved:

  1. Validators reconnect
  2. Consensus resumes automatically
  3. No manual intervention required

!!! important "No State Reversions" Monolythium does not support chain state reversions. Recovery is always forward-only through continued block production.

Slashing​

Consensus violations result in slashing:

Downtime​

Missing too many blocks:

Penalty: 0.01% slash
Jail: 10 minutes minimum
Recovery: Unjail transaction after jail period

Double-Signing​

Signing conflicting blocks:

Penalty: 5% slash
Jail: Permanent (tombstoned)
Recovery: None - validator must re-register

Monitoring Consensus​

Check Node Status​

curl -s localhost:26657/status | jq '.result.sync_info'

View Validators​

# Current validator set
curl -s localhost:26657/validators | jq

# Via CLI
monod query staking validators --status=BOND_STATUS_BONDED

Check Consensus State​

curl -s localhost:26657/consensus_state | jq

Configuration​

Key Parameters​

# config.toml [consensus]
timeout_propose = "3s"
timeout_prevote = "1s"
timeout_precommit = "1s"
timeout_commit = "2s"

Validator-Specific​

# Signing configuration
double_sign_check_height = 10

# Block proposal
create_empty_blocks = true
create_empty_blocks_interval = "0s"

Comparison to Other Consensus​

AspectCometBFTNakamoto (PoW)Ethereum PoS
FinalityInstantProbabilistic~15 min
Block time2s~10min~12s
Validators53Unlimited miners~500k
EnergyLowVery HighLow

FAQ​

What happens if my validator misses a block?

Missing occasional blocks has no penalty. Extended downtime (configurable window) triggers jail.

Can finalized blocks be reversed?

No. CometBFT provides deterministic finality - committed blocks cannot be reversed without breaking >1/3 Byzantine assumption.

Why only 53 validators?

Balance between decentralization and performance. More validators increase latency; fewer reduces decentralization. 53 provides good security with sub-3-second finality.

What if 2/3 of validators collude?

They could halt the chain or double-spend. This is the fundamental trust assumption of BFT consensus. Stake-based incentives make this economically irrational.

How do I know a block is final?

Immediately. Once you see a block at height N, it's final. No confirmations needed.