Consensus (QBFT)

SciChain finalizes blocks in about five seconds using QBFT — a Byzantine-fault-tolerant consensus protocol. Every committed block is final the instant it lands: no reorgs, no probabilistic confirmations, no waiting for depth.

How QBFT works

QBFT (a variant of the Istanbul BFT family) is a proof-of-authority protocol in which a permissioned set of validators takes turns producing blocks. It inherits from SciChain's Hyperledger Besu (25.x lineage) foundation and runs on Java 21.

Each block moves through a short, structured agreement cycle:

1. Proposal. Validators are ordered in a round-robin. The proposer for the current round assembles a block and broadcasts it to the other validators.
2. Prepare. Validators that accept the proposed block broadcast a PREPARE message, signaling they have the same candidate block.
3. Commit. Once a validator sees enough prepares, it broadcasts a COMMIT. When a validator collects commits from a supermajority — at least 2f + 1 of the n validators — the block is committed and appended to the chain.

If the round's proposer is offline or faulty, validators trigger a round change: they move to the next round, and the next validator in the rotation becomes proposer. This keeps the chain producing blocks even when individual validators fail.

Finality

QBFT provides deterministic, immediate finality. The moment a block collects its commit supermajority, it is irreversible — there is no competing fork that can later replace it, and no notion of "12 confirmations" before you can trust a payment.

This is a sharp contrast with Nakamoto-style consensus (proof-of-work, e.g. classic Bitcoin/Ethereum PoW), where finality is only probabilistic: a block becomes exponentially less likely to be reorganized as more blocks are built on top, but is never mathematically final. For settlement, exchange integrations, and cross-chain messaging, deterministic finality means an application can act on a transaction as soon as it appears in a committed block.

Fault tolerance

QBFT tolerates Byzantine faults — validators that are offline, buggy, or actively malicious — as long as they stay below one third of the set. Formally, the network must satisfy n >= 3f + 1, where n is the number of validators and f is the number it can tolerate. Committing a block requires agreement from at least 2f + 1 validators.

SciChain currently runs 4 validators, so it tolerates one faulty or offline validator (f = 1) and needs 3 commits to finalize a block. Growing the validator set raises the fault-tolerance ceiling; because n >= 3f + 1, each additional tolerated fault requires three more validators.

The validator set

SciChain is a permissioned network: the validators are a curated set of known operators, not an open, stake-weighted pool. This is not proof-of-stake — there is no bonding, slashing, or economic staking to join. Each validator is identified by its account address, and only addresses in the current validator set may propose and commit blocks.

The permissioned model fits SciChain's target: a high-assurance, post-quantum settlement layer where validator identity and accountability matter more than open, anonymous participation. Validators produce ~5 second blocks in rotation, and the active set is itself recorded on-chain, so anyone can audit who is currently securing the network.

Managing validators

The validator set is changed on-chain, by vote. Existing validators propose to add or remove an address, and a change takes effect once it has been voted for by more than 50% of the current validators. No hard fork or coordinated restart is required.

Proposing a vote

Each validator casts its vote with qbft_proposeValidatorVote. The parameters are the target address and a boolean: true to add, false to remove.

# Vote to ADD a validator
curl https://rpc.scimatic.net \
  -X POST -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","method":"qbft_proposeValidatorVote",
       "params":["0x1a2b3c4d5e6f708192a3b4c5d6e7f8091a2b3c4d", true],"id":1}'

# Vote to REMOVE a validator (same call, false)
curl https://rpc.scimatic.net \
  -X POST -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","method":"qbft_proposeValidatorVote",
       "params":["0x1a2b3c4d5e6f708192a3b4c5d6e7f8091a2b3c4d", false],"id":1}'

A validator can retract a vote it has cast with qbft_discardValidatorVote, and inspect the votes currently in flight with qbft_getPendingVotes. Once the proposed change crosses the >50% threshold, the set updates automatically at a block boundary and the new list is returned by the query methods below.

Reading the current set

Anyone — validator or not — can read the active validator set for any block:

curl https://rpc.scimatic.net \
  -X POST -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","method":"qbft_getValidatorsByBlockNumber",
       "params":["latest"],"id":1}'

# => { "result": [ "0xabc…", "0xdef…", "0x123…", "0x456…" ] }

Consensus RPC reference

QBFT exposes a dedicated qbft_ namespace over JSON-RPC.