Skip to main content

4. QuantumDAG Consensus

4.1 What Is Implemented​

Quantos contains a DAG graph and ordering layer, committee management, a fast-path module, pipelining and optimistic-responsiveness modules, view-change logic, checkpoint finality, and slashing evidence handling. These modules are composed by the Rust node, but their presence should not be read as proof that every design claim has been validated in a live multi-validator production network.

The DAG stores vertices with parent references and supports tip selection and ordering. The consensus code uses stake-weighted validator records, authorization checks, quorum accounting, and checkpoint signatures. The implementation is inspired by Narwhal/Bullshark and HotStuff; “derived from” is more accurate than claiming a formal implementation of those protocols.

4.2 Synchrony and Liveness​

The safety argument is stated under partial synchrony: safety must not depend on a timely network, while liveness requires eventual bounded message delay and sufficient honest participation. Timeout and view-change code adapts to observed conditions, but production latency and liveness guarantees require multi-node adversarial testing.

4.3 Committees and Checkpoints​

Committee membership is stake-weighted and uses the repository's VRF-style selection module. The default sizes and thresholds are configuration choices, not universal mainnet parameters. Checkpoints contain state and DAG commitments and collect unique signatures from active, non-jailed validators. The finality layer uses a dedicated finality key and checks it against the validator registry.

The official repository documents ML-DSA-65 checkpoint/finality signatures and a 1000-committee × 21-validator reference topology. These values are repository reference configuration, not a guarantee that every deployment runs at that scale.

4.4 Safety Scope​

The code contains validation and slashing paths for invalid blocks, equivocation, duplicate signers, inactive validators, and malformed evidence. These are executable checks and useful safety controls, but they are not a machine-checked proof of the complete distributed protocol. The repository also contains local bootstrap behavior, configurable components, and incomplete accounting paths; safety claims must therefore be limited to the checked invariants and tested execution paths.

4.5 Shards and Cross-Shard Operations​

The consensus and sharding modules support per-shard processing and cross-shard coordination designs. The number of shards, committee topology, and cross-shard protocol are configurable. Aggregate throughput, fault tolerance, and finality under re-sharding remain deployment properties to be demonstrated by a reproducible multi-validator testnet.