Cerberus [ /’sɜrbʌrʌs/ ] is a deterministic, Byzantine Fault Tolerant (BFT) protocol of state provisioning to create global consensus between shard groups on the correct ordering of software commands (including, but not limited to, transactions). The protocol was first described in a March 2020 paper by Florian Cäsar, Dan Hughes, Josh Primero and Stephen Thornton, and has been designed specifically for Radix’s multi-shard architecture.
DEVELOPMENT | |
Whitepaper | |
LEDGER | |
Sybil Protection | Delegated Proof of Stake |
State Model | Sharded (2^256 shards) |
Fault Tolerance | Byzantine Fault Tolerant |
Execution Environment | Radix Engine v2 |
Validator Node Cap | n/a |
Technology
All distributed ledgers are BFT State Machine Replicators (SMR). Cerberus is an active multi-decree (3-phase commit) consensus mechanism, requiring a supermajority for state commitment and capable of processing transactions in parallel. In contrast, Bitcoin is a single decree mechanism that sacrifices deterministic finality for probabilistic finality with a simpler communication protocol. Bitcoin determines block leadership by hash power, rather than random delegation.
Radix Implementation of Cerberus
Cerberus is the sixth iteration of Radix’s core technology and addresses the Weak Atom problem that was present in Tempo.
Series DLTs such as Bitcoin require all transactions on its ledger to be globally ordered and verified. In contrast, Radix’s ledger will eventually be split into 2^256 mini-blockchains called ‘shards’. Cerberus only requires consensus between related shards, meaning that unrelated commands can be processed in parallel. Commands executed within a shard are governed by ‘local Cerberus’ and related commands between shards are governed by ‘emergent Cerberus’.
Local Cerberus
Local Cerberus manages consensus within a single shard and is split into three phases: Prepare, Pre-Commit, & Commit. Each phase requires a ‘quorum-certificate’ of agreement to be signed by a majority of the nodes assigned to that particular shard. Importantly, multiple local Cerberus instances can exist in parallel.
Emergent Cerberus
Once committed, each local Cerberus instance is collated and added to related local Cerburus instances determined by the Partition function into a ‘merged proposal’. The application layer then adds ‘syncronization primitives’ to ensure correct ordering of commands.
Application Layer
Cerberus includes an application layer that determines how functions within the network operate. The five ‘pure’ functions are:
init: defines the initial state of the application.partition: determines which shards a command must be syncronized with to maintain correct partial ordering.map: collates all intermediate results of a command into an executable.reduce: shares intermediate results to every shard identified bypartition.apply: applies the new shard state.
These functions govern the state of a command from inception to commitment.