Industry Case Study: Radix Distributed Ledger Technology

Published in

Coinmonks

9 min readMar 28, 2022

The following post is the next installment of Boiler Blockchain’s case study series. Last time, we analyzed the Helium Network, an innovative project providing decentralized, wireless connectivity services. Today’s focus is Radix, a distributed ledger technology project aiming to serve the decentralized finance (DeFi) market.

In brief, our analysis of Radix found that:

Radix employs a unique consensus mechanism (Cerberus) that takes advantage of the network’s enhanced sharding capability
Radix’s architecture shows promise for solving the “blockchain trilemma” and overcoming scalability challenges for Layer-1 (L1) protocols
The technical success of Radix will depend on whether the final version of the mainnet can deliver on the theoretical capabilities of the network

Background: The Blockchain Trilemma

In the past year, blockchains such as Ethereum have encountered serious network congestion issues as the amount of users continues to grow past initial expectations. High gas fees and slow transaction finality make the network more difficult to use, limiting the growth of DeFi and other decentralized fields. There have been numerous proposals for fixing Ethereum’s issues: notably, alternative Layer-1 chains, sidechains, Layer-2 solutions such as optimistic and ZK-rollups, and various approaches to sharding. But this simultaneous growth of multiple L2s exponentially grows the attack surface of the ecosystem, likely past what it could be if the L1 were designed for sufficient capability from the outset. In mid-March 2022, Ethereum team lead Péter Szilágyi posted a telling Twitter thread on complexity growth in the Ethereum ecosystem.

Prominent alternative L1s like Solana and Avalanche attempt to scale decentralized activity by moving to a different blockchain entirely, with modified underlying technology that scales better than Ethereum in some way. But alternative L1s generally fail to achieve one of three pillars of a decentralized network, known as the blockchain trilemma.

From Vitalik Buterin’s April 2021 article, “Why Sharding is Great”

The blockchain trilemma identifies three pillars of a decentralized ledger: scalability, security, and decentralization. It states that a blockchain can achieve two of those three attributes using ’simple’ methods, but achieving all three in one network is disproportionately difficult — or even impossible. Solana is scalable and secure, but is centralized into nineteen ’super-nodes’. It uses these super-nodes because running a full Solana node requires powerful computer hardware out of reach of the average consumer.

For an unsharded blockchain with enough throughput to process all the world’s decentralized interactions, the storage and processing power necessary to run a full node almost inevitably results in centralization into a few “super-nodes”.

The Trouble with Blockchain Sharding

Enter Radix. Radix is an in-development distributed ledger technology (DLT) which aims to solve the aforementioned blockchain trilemma. It is important to note that Radix is not a blockchain, as the final design contains no global ordering or discrete network-wide ’blocks’. Radix transactions are designed to be ephemeral and concise, only lasting for as long as needed, and only touching as many network participants as necessary.

The Radix team argues that fatal design flaws in the architecture of blockchain-based distributed ledgers prevent effective scaling.

For starters, consider the storage and message complexity involved in a monolithic ledger. Existing blockchains require each node to store the entire history of the chain, which becomes infeasible as the transaction throughput grows on a successful network. For example, the storage requirement just to start a node for Bitcoin is currently at 400GB while Ethereum is at 600GB. Furthermore, in monolithic ledgers, a single consensus step involving an all-to-all message causes the message latency and required node compute power to grow with the square of the network transaction throughput. For consensus methods which involve multiple all-to-all steps, the latency and compute requirements grow with the cube of the throughput, or worse. Check out Bottlenecks in Blockchain Consensus Protocols for a complexity analysis of several contemporary consensus mechanisms.

Sharding approaches attempt to fix this scalability issue by breaking the monolithic blockchain into smaller parts, or shards. Radix claims that current sharding proposals for monolithic L1s will break atomic composability, which is a monolithic blockchain’s ability to ensure that all steps of a chained transaction will succeed or fail together. For instance, atomic composability has seen use cases in innovative methods of arbitrage involving flash loans. The reason for this breakage may roughly be seen when conventional sharding methods treat each shard as an independent blockchain, and it is difficult to communicate between or synchronize multiple blockchains. See Vitalik Buterin’s comment from 2019 confirming that sharding will make atomic composability ‘difficult‘ (things have arguably not gotten better since then).

An example sharding proposal for Ethereum, from “Why Sharding is Great”: Radix points out (and Vitalik confirms) that storing an essentially-independent blockchain on each shard would make it difficult or impossible to communicate synchronously across shards.

At a conceptual level, the fixes proposed for the issues of storage and message complexity mostly involve sharding a congested L1. But L1s were not necessarily designed with sharding in mind. Effectively applying sharding to increase the scalability of blockchain networks remains a key industry challenge.

The Radix Sharding Model

Radix proposes an unorthodox approach to sharding that purportedly helps overcome the challenge of effective scalability. While most sharding approaches take a monolithic blockchain and break it into some arbitrary number of more manageable chains, Radix’s sharding system pre-shards data into a practically unlimited number of shards. 2^256 shards are in the final design, to be exact. Furthermore, each shard no longer stores an ‘independent’ blockchain. Radix shards store only a minimal amount of data, and each shard corresponds to a single Bitcoin-style unspent transaction output (UTXO).

Figure 22 from the Cerberus whitepaper: Each gray dot and trailing line represents a shard. Green dots represent ’up‘ states while orange dots represent ’down’ states.

Radix’s whitepaper on Cerberus describes the sharding model using particle physics terms. UTXOs are represented by “particles”, each of which is in a “neutral” state if a UTXO has not been assigned to the particle, an “up” state if the assigned UTXO has been constructed from the outputs of a transaction, and a “down” state if the UTXO has been destructed by using it as the input for another transaction. Each shard only ever contains a single particle, and the finite “up” or “down” state model for active particles should ensure that double-spends are impossible. Transactions are then created by destructing “up” UTXOs on one or more particles, turning them to “down” states, and consuming the UTXOs to turn other particles into “up” states: this new particle could represent, for instance, a new owner of the UTXO.

Cerberus Consensus Mechanism

Radix’s sharding model gets rid of the concept of “blocks” or global ordering of transactions. In a normal blockchain, transactions do not become final until the block containing the corresponding data is finalized (or committed). By contrast, Radix uses a massively-sharded data store where transactions only touch affected shards. As a result, transactions can proceed in parallel, vastly enhancing the potential throughput of the network.

Cerberus, the consensus mechanism designed by Radix, takes advantage of the enhanced sharding capability. Cerberus arranges familiar blockchain primitives in a specific way to ensure parallel transaction processing. Cerberus also allows for dynamic validator sets, each of which contains a tunable number of nodes. Each validator set is assigned to some set of shards.

A basic understanding of Cerberus can be built on three levels.

First, a single validator set uses some generic blockchain consensus mechanism to conduct consensus over a single shard under their management. The Cerberus whitepaper uses the HotStuff Byzantine fault tolerant mechanism as an example, but any mechanism meeting a few basic requirements should suffice.

Figure 3 from the Cerberus whitepaper: Local consensus, conducted by a validator set on a single shard. This local consensus can be achieved using any consensus mechanism capable of producing a Quorum Certificate, e.g. HotStuff as described in the Cerberus whitepaper.

Next, a group of validator sets operates on several shard groups in parallel. This perspective is comparable to existing blockchain sharding proposals, in which a monolithic blockchain is broken down into a set of independent but essentially separate ledgers. The validators and shards would not be able to move freely between groups [shards] if they were tied together as in blockchain architectures: with Radix’s sharding model, however, validators can move to different validator sets as needed.

Figure 4 from the Cerberus whitepaper: Multiple Cerberus validator sets running parallel consensus across multiple shard sets.

Finally, Cerberus takes advantage of the dynamic validator/shard sets enabled by its sharding model to massively parallelize consensus over its shard space. Validator and shard sets are dynamically allocated across the shard space as necessary in order to conduct consensus when transactions affect some group of shards. Cerberus is therefore able to conduct unrelated transactions in parallel, removing a key scalability limit of modern blockchains, which forces transactions to wait for other unrelated transactions because of the blockchain’s inherent global ordering requirement.

Figure 20 from the Cerberus whitepaper: Cerberus consensus runs across shards as necessary to process transactions, and unrelated transactions can be processed in parallel because each emergent Cerberus instance only needs to touch the shards involved in its own transaction.

Evaluating the Future of Radix

Radix’s solution clearly possesses the potential to do what no blockchain can for DeFi. However, it is also undeniable that multiple technical breakthroughs will be necessary to implement a minimum-viable version of the final Radix design. (To say nothing of the marketing and community building required for a successful L1 project.)

Radix acknowledges that the current version of the mainnet is far from complete. The final design is currently planned for release (perhaps optimistically) in 2023. Radix is testing and demonstrating “some of the possible implementations of sharded Cerberus” on its Cassandra test network, but the ultimate success of these efforts is not guaranteed.

For example, a recent stress test conducted by Jepsen, a respected distributed systems verification team, highlighted several concerning issues. The Jepsen report analyzed seven months of testing on Radix’s Olympia mainnet, during which Jepsen discovered eleven safety errors including “stale, aborted, and intermediate reads; partial or total loss of committed transactions; … liveness issues with indeterminate transactions; and performance degradation during single-node faults”.

Jepsen’s report casts doubt on the functionality of Radix’s current network. However, a few additional points of context are helpful when considering Jepsen’s results. First, the bugs found in the stress test seemed to be acute, fixable, and mostly due to implementation. None of the features which failed were intended to be ‘firsts’, as they have already been proven in existing blockchains. Second, the report was derived from the Radix Olympia mainnet which does not reflect the final Radix design (as noted above). On a related note, Jepsen did not refute any planned features of the final design. The final design features — most importantly static pre-sharding and parallel consensus — are where the true innovations of Radix should come into play.

The Boiler Blockchain research team needs additional time to fully understand the inner workings of Cerberus and Radix’s final design. Several of the project’s components are complex, including static pre-sharding, parallel consensus, and dynamic validator sets. A thorough understanding of all the components is critical for a holistic understanding of how Radix aims to work. The process of understanding Radix is akin to onboarding web2 ’natives’ into Bitcoin: it requires a fairly different way of thinking, and initially may seem counterintuitive.

Three additional points are worth highlighting before concluding:

Radix is easily the most complex L1 design the research team has seen, but even the final design should still be less complex than a fully sharded and “L2’ed” version of Ethereum or a similar, existing blockchain.
Our team is cautiously optimistic on Radix’s ability to reach the claimed throughput capabilities, as we did not discover any hard analyses disproving the feasibility of the final design. We note that implementation and execution is another story. If Radix is to take over the world’s decentralized activity, it must do so before existing solutions build enough of a competitive moat to make it impossible for Radix to achieve network effects.
A full understanding of Radix and its place in the DLT space requires a) further research on other scaling solutions for an apples-to-apples comparison to Radix, and b) a detailed analysis on the inner workings of Cerberus itself.

***

Contributors: Andrew Chen, Will Delaney, Haris Hasan, Devan Park, Max Moncaster

Join Coinmonks Telegram Channel and Youtube Channel learn about crypto trading and investing