Introducing Cerberus: Scaling Without Trade-offs

Iam Chijamz
4 min readNov 12, 2020

A distributed ledger technology (DLT) platform should provide a working alternative to the global network of traditional financing, simultaneously supporting a large number of decentralized finance (DeFi) apps, generating high throughput and without compromising the ultimate goal of DeFi — decentralization. DeFi platforms should also guarantee the interoperability of apps and assets, often referred to as “composability.”

However, in the present decentralized finance (DeFi) environment, scaling a decentralized application (dApp) across a distributed ledger technology platform appears to be an uphill task. While Bitcoin and Ethereum still struggle with their scalability properties, newer blockchains have emerged, each claiming a higher throughput than the other.

In some of these emerging blockchains, scalability is achieved theoretically, while replicating it practically among users becomes a problem. Some others try to gain a measure of scalability by allowing a trade-off of security, scalability, and/or composability.

Other blockchains employ other methods that will separate apps through the process called “sharding.” This is a method where apps can run faster but without having direct, atomic access to each other. This means that there is less interoperability (a direct conflict between scalability and composability), making true DeFi scalability impossible.

However, Radix takes an entirely different approach, achieving the right stability without sacrificing security, composability, or decentralization.

Scaling Through Parallelism

Scalability solutions may require some form of sharding. The goal is to localize different apps and transactions to separate shards from where they can be run through consensus in parallel. While this enables an increased throughput, communication among fragments becomes increasingly tricky.

Ultimately, the requirements to process these shards become more complex, and slow down transactions renders it error-prone and challenging to be able to be implemented in a smart contract code. Worse still, assigning apps and assets to specific shards is often static or may require a significant network overhead to adjust.

The challenges associated with sharding creates a conflict between scalability and composability. As a result, Radix came up with workable solutions to resolve this conflict and to be able to adequately scale up dApps on Radix while making use of shards.

Radix’s methods are based on three principles. The first is the enablement of a practically unlimited number of shards to achieve as much parallelism as is possible in a global-scale DeFi platform. The second is the need for a consensus protocol that will dynamically conduct synchronous consensus on atomic transactions (including operations on smart contracts) across relevant shards without stalling the rest of the network. The third is an application layer that will efficiently use the unlimited shard space and the multi-shard consensus.

Therefore, to ensure that true, practical scalability could be achieved through shards, Radix employs a unique consensus algorithm known as Cerberus.

Cerberus Consensus

The Cerberus consensus algorithm is designed around a concept known as “pre-sharding.” In this method, instead of adding shards to individual non-variable ledgers, the ledger is split into a “shard space” of many fragments that are so large and practically unlimited. These shards could represent anything, and Cerberus can then “braid” a secure consensus across an arbitrary number of required bits.

Cerberus is a new consensus algorithm designed for large, diverse networks involving simultaneous transactions and applications. Linear scalability is provided through parallelism with Cerberus.

The Cerberus protocol makes use of three significant steps to function. The first is to partition the application layer by formalizing every command’s partial ordering requirements in the coating. The second requires the combination of multiple “local Cerberus” BFT (Byzantine fault-tolerant) instances to form an “emergent Cerberus” instances across shards having similar characteristics. The third step then requires the parallelization of emergent Cerberus instances across shards. This ensures that there is a safe and massive parallelization of the consensus process across the network.

To function effectively, Cerberus requires a specialized application layer. The application layer provides the required interface between the smart contract code and the underlying ledger within any distributed ledger technology. For Radix, this layer is the Radix Engine.

The Radix Engine

The Radix Engine enables a developer to specify a transaction’s functionality in a manner that is asset- oriented. Modelling useful elements of everyday transactions (money, identities, products, properties) are done as functional, separate components that may be independently updated. They are not modelled within unbounded smart contract codes.

The Radix Engine can translate these components into finite state machines, easily translated into a shardable language understood by Cerberus. Thus, transactions are expressed as a command to Cerberus. This application layer also makes possible a highly granular partial ordering, which Cerberus can take advantage of, resulting in massive parallelism of consensus.

Final Words

Scalability is an essential component of every distributed ledger system. And while many distributed ledgers do a trade-off of other features to ensure their network’s practical scalability, Cerberus expertly uses consensus parallelism of shards to scale its network without compromising any element effectively.

Moreso, as the network grows with an influx of users, dApps, and transactions, there will be no compromise of atomic composability because direct concession between shards happens without friction following each transaction.

Share your thoughts about Cerberus in the Comments, I would love to hear from you. For More Information, Visit Cerberus FAQ Page

--

--