VordiumBFT consensus

VordiumBFT is a Byzantine fault tolerant consensus protocol. The network names its model in its spec: BFT with two voting rounds per view (prepare, commit).

A block is final once the validators certify it.

There are no reorganisations and no confirmation count: a client never waits for "enough blocks".

Heights, blocks and batches

• A height is a slot with a leader. A height holds a block only when its leader produced one; otherwise the height is empty, and eth_getBlockByNumber answers null for it.
• A batch is a fixed run of consecutive heights (16 on the main network). The validators agree on a batch as a whole.
• The network's rates count heights. The count of produced blocks is published beside it.

Scroll sideways to see the whole diagram

Right now: —, and —.

Voting power and the quorum

Each seated validator has voting power. A batch is agreed when validators holding a quorum of the voting power agree on it — more than two thirds. No single validator can hold more than a set share of the power (—), and the set rules are published in the validator registry.

Two voting rounds

The validators agree on each batch in two voting rounds. A view is one leader's turn: the leader of the view proposes the next batch, and the validators vote on it twice.

Scroll sideways to see the whole diagram

1. Prepare. Each validator checks the proposed batch and votes for it. Once validators holding a quorum of the voting power have voted, the batch is prepared. A quorum cannot prepare two different batches for the same place in the same view, because any two quorums share validators holding more than a third of the power.
2. Commit. The validators then vote a second time, to commit the prepared batch. Once a quorum has voted to commit, the batch is certified, and every block in it is final.

Why two rounds: the first makes sure a quorum agrees on one batch; the second makes sure a quorum knows that it agreed. If a view ends before its batch is committed, the next view's leader starts from what a quorum prepared, so a batch that a quorum committed stays the batch at its place in every later view. This holds as long as validators holding at least two thirds of the voting power follow the protocol.

A validator signs one vote per round. Signing two different votes in the same round is double-signing, and it is recorded (faults and jailing).

From an accepted operation to a block

An operation the network accepts is passed to every validator over the validator network. There is no public mempool to watch and no fee auction to win: whichever validator leads the next height can include it.

Each batch carries more than the blocks' own operations: the oracle prices, the batch clock, bridge credits and the work the engine does at the boundary (matching, liquidation, funding). All of it is agreed together, so every validator applies exactly the same work.

State roots

The chain keeps one state root per batch. It is a keyed Merkle root: updating it costs in proportion to what changed, not to the size of the state. The market WebSocket's commit frames carry the height, the batch height and the state root, so a client can follow the chain's progress (WebSocket).

Epochs

The validator set changes only at epoch boundaries. An epoch is —; a change that is accepted names the epoch it takes part from, and a validator that has just been unjailed is seated from the next epoch.

Faults and jailing

Two kinds of fault are recorded:

• a leader publishing two different blocks for one slot — logged; it is not a vote and it is not penalised;
• a validator signing two different votes for the same batch at the same step — double-signing.

Vordium never takes a validator's stake. There is no slashing — not for downtime, not for double-signing, not at any rate. A validator that misbehaves or goes offline is jailed: it stops earning until it is unjailed.

A validator proven to have signed two different votes in the same round is jailed too. Missing — jails a validator for downtime. See Jail and unjail.