Cassandra [ /kəˈsændrə/ ] is a Radix testnet and R&D project to explore the challenges and capabilities of a fully sharded version of the Cerberus consensus mechanism in a non-production environment. Cassandra incorporates elements of Cerberus, but is distinct from it. Part of the project was to create a decentralized test version of Twitter with the ability to tip users in $XRD. The project is a collaboration between an unofficial organization called ‘Radix Labs’, the University of California Davis’ ExpoLab, and community members running nodes.
DEVELOPMENT | |
State Model | Sharded (2^256) |
Sybil Protection | Hybrid (Proof of Work / Proof of Stake) |
Consensus Mechanism | |
Max. TPS | 6312 (2021-02-22) |
dApp Repo |
History
Cassandra evolved out of Dan Hughes’ Flexathon project in January 2021 and was designed to answer two questions:
- What happens if there is a liveness break (i.e. an outage of validators) in a sharded network?
A technical demonstration using Twitter data was premiered on Twitch on March 13th, 2021. 40% of the project was described as ‘new code’.
Etymology
Cassandra was named after the mythological Trojan priestess who would accurately prophesy to her master, Apollo, but was never believed.
State Model
Cassandra exists on a fixed shardspace of 2^256 shards and uses blocktrees for data availability. Transactions are processed on a first-come, first-served basis and in parallel if the transactions use different inputs. The network scales linearly as more nodes are added.
Consensus
Cassandra uses a hybrid deterministic / probabilistic consensus, where round leaders within shard groups are determined by proof of work.
- Proposal (e.g. transaction) initiated by client (e.g. wallet).
initfunction defines the initial state of the ledger within each shard involved in the transaction.partitionfunction determines which shards must be syncronized to maintain correct partial ordering.- State changes batched into a proposal (batch of state changes) and sent to relevant shard groups (validator + replicator sets).
- Assessment stage:
- Local Cerberus - Prepare:
- Validators provision (lock) their relevant state.
- Relevant shard groups gossip internally to determine well-formedness of the proposal (signatures, variable constraints, etc).
- If a supermajority (2f+1) of validators (measured by stake) agree, each shard group adds a quorum signature to a state certificate with:
- Proposal hash.
- State inputs.
- State outputs.
- Merkle root hash.
- Vote participants.
- Validator stakes.
- Local Cerberus - Pre-Commit:
mapfunction collates state certificate into an executable ‘promise’.- Replicators call the
reducefunction to share relevant state inputs with every shard group identified bypartition. - State certificate signed by shard group.
- Local Cerberus - Commit:
applyfunction applies the new shard state within shard groups.- Shard groups vote on the new state.
- Shard groups exchange state certificates within a default timeout window.
- Event certificate formed as an aggregation of state certificates.
- If one of the state certificates disagrees with the rest, the operation is aborted.
- Emergent Cerberus:
- Emergent ‘shard’ created by braided local Cerberus instances.
- Commit stage:
- Event certificate added to the consensus queue.
- Event certificate committed to the ledger.
That requires a consensus round and takes a couple of seconds, then the provisioning happens and the gossip of the state objects.
Once provisioned validators then execute, and the result of the execution is agreed upon, which takes another round of consensus.
between the first and second consensus phases, provisioning, execution, certificate generation etc are asyncronous from consensus itself.
Therefore other transactions are being prepared for provisioning, or being completed in other consensus phases while our latent transaction is being processed.
Further Reading
TPS Results
DATE | SHARD GROUPS | TPS | LINK |
2021-02-22 | 8 | 6312 |