Skip to main content

Consensus — Simplex + Falcon

Quantum replaces Ethereum's proof-of-stake consensus with Simplex, the single-slot-finality BFT protocol from Commonware. Validator votes are signed with Falcon-512, chosen for the smallest PQ signature size on the consensus critical path.

The execution and consensus layers are tightly integrated, communicating directly without an external beacon client.

Why Simplex​

The choice is shaped by three constraints:

  1. A short critical path. Simplex reaches notarization in 2 hops and finalization in 3 hops. Sub-second finality on devnet today.
  2. Operational clarity. The protocol is simple enough that operators can reason about leader election, vote dissemination, and fork resolution without an ML-engineering team. A long critical path with deep recursion (DAG-style designs) was rejected.
  3. PQ-friendly byte budget. Simplex's quorum proofs ship validator signatures. With Falcon at ≤ 666 B each, a 100-validator quorum proof is around 44.6 KB — manageable. With ML-DSA-44, the same proof would be roughly 162 KB.

Why Falcon at consensus​

Falcon-512 has the smallest signature size among standardized PQ candidates and is selected by NIST for a future standard (FN-DSA / FIPS 206 IPD).

The trade-off is on the signing side: Falcon signing is more complex than ML-DSA (rejection-sampling-based and harder to make constant-time). For the consensus role — server-side validators with controlled environments — this is acceptable. Userland keeps ML-DSA-44 because userland devices are heterogeneous and side-channel-resistant signing matters more than maximum byte efficiency.

Quorum proof scaling​

In BFT-style consensus, finality requires a quorum (often 2f+1) of validator approvals. If a quorum proof contains the set of signatures, then:

quorum-proof signature bytes  ≥  (2f + 1) × signature_size
                                + signer IDs / bitmap + framing overhead

For Falcon-512 (≤ 666 B max):

  • n = 100 ⇒ f = 33 ⇒ 2f+1 = 67 ⇒ ≥ 44,622 bytes (~44.6 KB)
  • n = 200 ⇒ f = 66 ⇒ 2f+1 = 133 ⇒ ≥ 88,578 bytes (~88.6 KB)

This is workable at the validator counts we target today. Future scaling — to hundreds or thousands of validators — likely requires threshold signatures with DKG to compress quorum proofs into a single signature. See "Threshold research" below.

Block lifecycle​

The full sequence is:

  1. Propose — Simplex elects a leader. The leader canonicalizes the parent, builds the block payload from the mempool, verifies it locally, and returns the block to Simplex for dissemination.
  2. Verify — Simplex broadcasts the block. Each validator decodes the payload, canonicalizes the parent (fire-and-forget), and verifies the payload against the execution layer. Result: Valid / Accepted, Syncing → bounded retry, or Invalid / Error.
  3. Notarize — Once ≥ 2f+1 validators vote yes, Simplex notarizes. A canonicalize-head update is applied at the execution layer (fire-and-forget — Simplex's voter loop is not blocked).
  4. Finalize — Simplex finalizes. The execution layer applies the forkchoice update with the finalized block hash.

The detailed step-by-step (with mermaid diagrams) lives in Transaction and block lifecycle.

Block header — timestampMillisPart​

Quantum block headers wrap a standard Ethereum header and prepend one extra field:

RLP(QuantumHeader) = RLP([timestampMillisPart, ...standard 21 header fields...])
  • timestamp (seconds) — standard, EVM-compatible.
  • timestampMillisPart (u64, 0–999) — sub-second component for consensus ordering.
  • RPC responses include a computed timestampMillis = timestamp * 1000 + timestampMillisPart.

Block hash = keccak256(rlp(QuantumHeader)). Any indexer that recomputes block hashes from standard header fields alone will get mismatches. See Indexer architecture.

Marshal and backfill​

Simplex disseminates blocks via the Commonware Marshal layer. For small networks (N = 1) the engine selects marshal::standard; for N ≥ 4 it selects marshal::coding (erasure-coded dissemination). N ∈ {2, 3} is intentionally rejected by localnet init because the Coding variant requires N ≥ 4 and the Standard variant is only meaningful at N = 1.

If a validator falls behind, marshal backfill recovers gaps by fetching the missing blocks from peers.

For dev mode and multi-node localnet setup, see JSON-RPC and dev mode.

Threshold research (post-v1)​

We are actively researching post-quantum threshold signatures with DKG to compress quorum proofs into a single signature. The constraints:

  • Must not erase Simplex's fast-path advantages.
  • Must remain side-channel-resistant.
  • Must be implementable in a way that's auditable.

Ringtail is a candidate scheme with message-independent preprocessing and reported signature / communication sizes that scale well at large thresholds. It is explicitly exploratory and benchmark-gated. This is separate from Mithril, which targets institutional custody (≤ 6 parties) and is not suitable for validator-scale quorums.