Permissioned QBFT Consensus

Nigo Protocol provides QBFT-family instant-finality consensus for enterprise permissioned networks. The consensus layer has validators re-execute and agree on transaction results, then atomically commits only finalized blocks and state.

The current implementation is Nigo QBFT Profile Revision 1. Its message format, block-header representation, and network transport follow the Nigo Protocol specification; this does not imply wire-format or extraData compatibility with Besu QBFT.

Execution and consensus boundary

Consensus does not replace the execution engine. Each validator independently executes identical inputs and verifies that the proposed state and receipt roots match deterministic results. A proposal whose execution result differs cannot become a valid finalized block.

Revision 1 profile

Area	Current rule
Validator set	Static set fixed by genesis and operating configuration
Validator identity	secp256k1 key and 20-byte validator ID
Proposer selection	Deterministic round-robin by block height and round
Messages	PROPOSAL, PREPARE, COMMIT, ROUND_CHANGE
Locking	Round lock based on a prepared certificate
Commit certificate	Signature set sorted by validator ID
Crash recovery	Persist-before-broadcast using a WAL
Node roles	Validator or observer

Dynamic validator admission and removal and on-chain governance are not active Revision 1 features. Changes to the validator set require a separate network operating procedure and, in the future, a protocol revision.

Quorum and fault tolerance

For n validators:

quorum = ceil(2n / 3)
maximum Byzantine faults = floor((n - 1) / 3)

For example, four validators require a quorum of three and tolerate at most one Byzantine fault. A production topology should consider not only the node count but also whether organization, region, and key-custody boundaries are independent.

Normal round

1. The proposer for the height and round proposes a candidate block.
2. Validators verify its signature, parent, round, transactions, and execution result.
3. They persist and propagate PREPARE for a valid proposal.
4. A PREPARE quorum forms the prepared state and lock, after which validators propagate COMMIT.
5. A COMMIT quorum finalizes the block with a commit certificate.

A finalized block does not require probabilistic confirmation depth. Under the validation rules, two different blocks at the same height cannot both become finalized.

Round change and locking

If a proposer fails to respond or sends an invalid proposal, validators move to the next round after a timeout. A ROUND_CHANGE message may carry the validator's prepared certificate.

The new proposer collects quorum round-change evidence. If it contains a valid prepared certificate, the proposer must select the block from the highest prepared round. This lock rule preserves safety across round changes.

Messages from old heights or rounds, duplicate votes, and invalid signatures are rejected. Equivocation—one validator signing different blocks at the same stage and round—is also detectable.

WAL and crash recovery

Before sending a consensus message, a validator durably records its intent in a local write-ahead log (WAL). This persist-before-broadcast order allows a restarted process to recover its prior votes and locks even if it crashed immediately after transmission.

On recovery, a node reconstructs state including:

• the current block height and round;
• proposals or votes it already sent;
• its prepared lock and certificate; and
• a commit certificate in progress.

The WAL is a local consensus-safety record, not a database that replaces operational backup. Disaster-recovery policy must cover it together with block and state storage.

Network permissioning and consensus identity

Nigo treats mTLS peer authentication and consensus-message signatures as separate security boundaries.

• mTLS restricts P2P channel access to permitted nodes.
• Validator signatures prove that a particular validator is accountable for a consensus message.
• Possession of a TLS certificate does not make a node a validator.
• A validator with a consensus key must still pass network access policy and certificate validation.

This separation allows certificate rotation, node access revocation, and consensus-key custody to be controlled independently.

Validators and observers

Role	Validate blocks	Vote in consensus	Serve state and RPC
Validator	Yes	Yes	Depending on configuration
Observer	Yes	No	Yes

An observer validates and synchronizes finalized blocks without contributing to quorum. It is appropriate for separating read-heavy workloads such as query RPC, audit, and indexing from validator nodes.

Finality and storage

Only a block with a completed commit certificate enters the canonical chain. Commit processing must store the following as one consistent unit:

• block header and body;
• commit certificate;
• transaction receipts and logs;
• StateCell and EVM state changes; and
• state roots and related indexes.

If a node stops mid-process, it must not expose a partial commit as canonical state after restart.

Catch-up and state synchronization

A lagging node retrieves finalized blocks and certificates from a trusted peer and validates them sequentially.

local finalized height
  → request next block and commit certificate
  → validate parent link and quorum signatures
  → deterministic execution or validated state synchronization
  → atomic commit
  → repeat through the latest finalized height

Invalid synchronization data or a broken chain link must fail closed. Unvalidated remote state must never be promoted to canonical state.

Current validation scope

Revision 1 validation for a static validator set focuses on:

• proposal, prepare, and commit in a normal round;
• round changes and preservation of prepared locks;
• rejection of duplicates, stale messages, and invalid signatures;
• quorum and deterministic ordering of commit certificates;
• WAL-based restart recovery; and
• observer synchronization and finalized-block validation.

Boundaries to verify before production

Production use requires operational validation beyond implementation conformance:

• memory, disk, and WAL growth under sustained load;
• seamless mTLS certificate rotation and revocation;
• cleanup and retry policy for corrupt or malicious synchronization responses;
• integration of HSMs or external signing devices for consensus keys;
• validator placement across organizational and regional fault domains; and
• a separate protocol and governance design if dynamic membership is required.

Mathematical QBFT safety does not automatically solve these concerns. BXDL release criteria must include key management, change management, monitoring, backup, and recovery runbooks.

Next

• Architecture overview
• EVM compatibility layer
• Native Program
• Operator guide