IBFT 2.0 Consensus

BESC Hyperchain uses Istanbul Byzantine Fault Tolerant v2 (IBFT 2.0) consensus — an enterprise-grade BFT protocol that delivers instant, deterministic finality with known, authorized block producers. It is the same consensus protocol used by major enterprise blockchain deployments worldwide and is the reason BESC Hyperchain can guarantee settlement in 3 seconds with no reorganizations.

Relayers vs. Validators — Two Different Things

The 4 IBFT nodes described on this page are consensus relayers — their job is to produce blocks and forward block rewards + gas fees into the Validator Registry. They are not the governance validators.

The Validator Registry (28+ participants) holds the real validator set — the entities who vote on Validator Court cases, vote to admit or remove validators, and govern the network. See Validators → for that layer.

How IBFT 2.0 Works

Each block goes through a multi-round voting process among the 4 consensus nodes (relayers):

Round Start (every 3 seconds)
       │
       ▼
  [PROPOSE]   One node is selected as proposer (round-robin rotation)
       │       The proposer assembles and broadcasts a block proposal
       ▼
  [PREPARE]   Other validators verify the proposal and broadcast PREPARE messages
       │       A block requires 2/3 + 1 PREPARE votes to proceed (threshold: 3 of 4)
       ▼
  [COMMIT]    Validators broadcast COMMIT messages with their signatures
       │       A block requires 2/3 + 1 COMMIT votes to be sealed
       ▼
  [SEALED]    Block is finalized and added to the chain
              No rollback is possible — this is deterministic finality

Key Properties

Instant Finality — The Biggest Difference from Public Chains

This is what separates BESC Hyperchain from Ethereum, BNB Chain, Polygon, and virtually every other public blockchain.

Nakamoto consensus (Bitcoin, early Ethereum) and probabilistic PoS (Ethereum post-Merge, BNB Chain) provide finality only in a statistical sense — there is always some probability that a longer chain could emerge and reorganize your block. In practice:

• Ethereum requires waiting for 2 epochs (~12 minutes) for "safe" finality. A transaction in a block can technically be reorganized before that point.
• BNB Chain uses Parlia consensus; practical finality is ~45 seconds (15 confirmations), but it's still probabilistic
• Polygon PoS checkpoints to Ethereum every ~256 Polygon blocks (~5 minutes) for true finality; before checkpointing, blocks are final-but-not-really

IBFT 2.0 delivers deterministic finality. The moment a block is committed by 3 of 4 nodes, it is mathematically irreversible. There are no chain reorganizations, no competing forks, no uncle blocks. 1 block = final. Forever.

For financial applications, this matters enormously. A payment that appears in a BESC Hyperchain block is settled — not probabilistically, not eventually, but immediately and permanently.

Fault Tolerance

With 4 consensus nodes, IBFT 2.0 can tolerate 1 Byzantine-faulty node:

n = 4 nodes
f = floor((n - 1) / 3) = 1 faulty node tolerated

The network continues producing blocks even if one consensus node is offline, crashed, or acting maliciously. The remaining 3 nodes form a quorum (2/3 + 1 = 3) and continue sealing blocks without interruption.

Round-Robin Proposer Rotation

The block proposer rotates deterministically through the 4 consensus nodes. This has two important consequences:

1. No MEV: No single node has disproportionate influence over transaction ordering. There is no competitive incentive to front-run or sandwich user transactions. Compare this to Ethereum, where validators can and do reorder transactions for personal profit.
2. Predictable throughput: Block production is steady and predictable — no hash-rate competition, no difficulty adjustment, no stochastic delay.

Known, Authorized Block Producers

On Ethereum, any entity that stakes 32 ETH becomes a validator — anonymously. On Bitcoin, any entity with sufficient hash power can mine a block. BESC Hyperchain's 4 IBFT consensus nodes are known, vetted, authorized entities. They cannot join or leave without a governance process. This creates clear accountability for block production that no public chain can match.

Epoch Length

IBFT 2.0 uses epochs of 30,000 blocks (~25 hours at 3-second block times). At the end of each epoch, relayer set changes take effect. Adding or removing a relayer node requires a governance process and takes effect at the next epoch boundary. This makes the validator set change process deliberate and auditable, not sudden.

IBFT 2.0 vs Other Consensus Mechanisms

Feature	IBFT 2.0 (BESC)	Ethereum PoS	BNB Chain	Polygon PoS
True finality	3 seconds — deterministic	~12 min (2 epochs)	~45s (15 blocks)	~5 min (checkpoint)
Block time	3s	~12s	~3s	~2s
Reorg possible?	No — mathematically impossible	Yes, before 2 epochs	Yes, technically	Yes, before checkpoint
Validator type	Known, vetted entities	Anonymous (32 ETH)	Top 21 by stake	Anonymous stakers
MEV / front-running	✅ Zero	❌ Significant	❌ Significant	❌ Significant
Fault tolerance	1 of 4 nodes	1/3 of all stake	1/3 of 21 validators	1/3 of stakers
Block producers	4 relayers	~1,000,000	21	Open

Block Parameters

From the genesis configuration:

{
  "ibft2": {
    "blockperiodseconds": 3,
    "epochlength": 30000,
    "requesttimeoutseconds": 20,
    "blockreward": "2000000000000000"
  }
}

• blockperiodseconds: 3 — target block time; in practice, blocks arrive every 3 seconds within milliseconds of the target
• requesttimeoutseconds: 20 — if a round does not complete in 20 seconds (e.g. a proposer is down), a new round starts with a new proposer; this is the failover mechanism
• blockreward: 2000000000000000 — 0.002 BESC per block, forwarded to the Validator Registry after each block