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.
Delegated Proof of Stake
Sharded (2^256 shards)
Byzantine Fault Tolerant
Radix Engine v2
Validator Node Cap
The Radix Programmer's Guild
RadGuild is a member-directed community of designers and developers who are building core software building blocks (aka blueprints) and key distributed applications (aka Dapps) for the Radix Decentralized Ledger which we believe will emerge as the key enabling technology for the free world's digital economy.
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 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.
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.
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 by
apply: applies the new shard state.
These functions govern the state of a command from inception to commitment.