ContBFT

ConfBFT is designed for consensus over deterministic blocks

Overview

ContBFT is the consensus layer for the Continuum sequencer, implemented as a modified HotStuff protocol in /contBFT/hotstuff_rs/. It provides Byzantine fault-tolerant finality of transactions and the state transition function.

Key Architectural Choices

Let's refer back to the diagram from the overview:

Block Production

"Blocks" in continuum are pre-defined sections of ticks that upon which A deterministic State Transition Function (STF) has been executed:

$$S_2 \;=\; \mathrm{STF}\!\left(S_1,\; \overrightarrow{\mathcal{T}}\right)$$

Where,

$$S_1:\ \text{initial state}, S_2:\ \text{final state},$$

$$\overrightarrow{\mathcal{T}} \;=\; \{\, t_1, t_2, \ldots, t_n \,\} \quad\text{(ordered set of transactions)}$$

Determinism

The block application process is purely deterministic, and the leader has no discretion as the ordered list of transactions has already been produced and shared in real time. Due to Proof of Sequence, reordering or proposing alternate timelines to different validators constitutes a faulty STF - leading to leader rotation (and potentially slashing).

Deterministic blockchains have an interesting property - all full nodes can compute the next block simultaneously (given only their network latency from the ContSEQ stream). This allows us to skip the "propose block" step in consensus, and go directly to voting on the root hash calculated by every validator.

Finality

Effective Finality: Due to the deterministic execution design, validators and full nodes recieving the POSq transaction stream can build the execution layer and updated state themselves. This leads to real-time effective finality, subject only to the physical latency between the Validator/Full node from the leader. This is a stronger guarantee than soft confirmations, as not respecting the POSq stream is considered a protocol level fault. Economic Finality Economic Finality is designed as a consensus backstop to misbehavior, rather than actively making choices (such as fork choice) in the usual hot path. Deterministic blocks are voted on every 100 ms and "finalized". Importantly, this doesnt prevent users from reacting in real time to the transaction stream. Consensus based rollbacks are designed as a backstop only in rare cases, where there is equivocation or misbehavior (or potentially liveness fault) on the part of the leader. In regular operations, all users can essentially treat proof of inclusion as a binding proof of order.

Safety Guarantees

1. No conflicting commits: Locked PhaseCertificate mechanism prevents forks.

2. Liveness: On-fault Sequencer rotation is active on testnet v2. Since the other properties of sequencer rotation (i.e. Censorship resistance, MEV distribution) are achieved by other mechanisms (i.e.

3. Deterministic finality No probabilistic confirmation; committed is final