Cassandra [ /kəˈsændrə/ ] is a research project spearheaded by Dan Hughes to address two critical issues that could arise in a sharded network, specifically Radix’s forthcoming Xi'an release:

1. What happens if a subset of validators cease processing transactions, leading to a liveness failure?
2. How can validator sets be dynamically adjusted in case of liveness failures?

Radix Technical AMA #2: Cassandra Overview

Radix Technical AMA #2: Cassandra Overview

Overview

Cassandra is a collaboration between an unofficial organization called Radix Labs, the University of California Davis’ ExpoLab, and community members running nodes.

Part of the project was to create a decentralized test version of Twitter with the ability to tip users in $XRD.

Etymology

Cassandra was named after the mythological Trojan priestess who would accurately prophesy to her master, Apollo, but was never believed.

Background

Cassandra evolved out of Dan Hughes’ Flexathon project in January 2021. A technical demonstration using Twitter data was premiered on Twitch on March 13th, 2021. 40% of the project was described as ‘new code’.

Implementing the Xi'an upgrade to a fully sharded network is necessary for Radix to scale to “support the needs of the $400 trillion global financial market”. However, transitioning to an explicitly sharded system introduces significant security, decentralization, and liveless challenges. Sharding enables the ledger to process transactions in parallel across multiple shards, but raises questions around how validators across different shards can remain in consensus on the global state.

To study these issues, Hughes started the Cassandra research project from scratch, setting aside existing consensus algorithms like Cerberus and HotStuff that Radix currently uses. The objective was to take a blue sky approach to determine what components are necessary to create a secure, decentralized, and live sharded environment.

https://x.com/fuserleer/status/1495901628439879690?s=20

Question 1: Liveness in Sharded Networks

In a sharded environment, it is possible for a subset of validators across different shards to stop processing transactions, leading to a liveness failure where parts of the network stall. This can happen unintentionally due to technical issues or intentionally by adversaries looking to disrupt the network.

Liveness failures are especially problematic in networks like Radix that use deterministic consensus algorithms to achieve transaction finality. These algorithms require approval from 2/3 of validators to finalize transactions. If 1/3 or more validators stop participating, the network cannot make progress.

Existing consensus algorithms lacked strong provisions to ensure liveness in sharded environments. Hughes wanted to find a solution that would allow the Radix network to maintain weak liveness during partial liveness failures, so that the live parts of the network could continue making progress.

Question 2: Dynamically Adjusting Validator Sets

In decentralized networks, validator sets are determined algorithmically through ‘sybil protection’ mechanisms like staking. However, liveness failures may require proactively removing non-participating validators from the active set. This raises a challenge: How can validators be removed without centralized control of the ledger? In addition, any validator set adjustment process could be vulnerable to malicious validators looking to attack the network without needing 1/3 of the total stake. Hughes wanted to find a solution that would allow validator sets to be adjusted in response to liveness issues, but prevent adversaries from manipulating this process to their advantage.