The crypto industry has struggled for its entire history to overcome issues around scalability. As the rapid expansion of decentralized applications on Ethereum – especially DeFi apps – has shown us, the platform is unable to cope with higher amounts of traffic.
That’s not good because if DeFi is ever to emerge as a genuine alternative to traditional finance, it’s going to need to reach the same kind of scale. Unfortunately, at present it’s not even close.
A number of solutions have been proposed, and already implemented. Ethereum for example is in the process of upgrading to “Ethereum 2.0”, while other blockchain projects like Fantom, Avalanche and Solana have all proposed alternative techniques to increase throughput, which is generally measured in “transactions-per-second”.
However, DeFi cannot scale on just TPS alone. That’s because DeFi also relies on something called “atomic composability” to enable interoperability throughout its growing ecosystem.
Interoperability is vital for DeFi apps. It’s usually referred to as “composability”, and can be thought of as the ability of a dApp to “compose” a single transaction that makes use of multiple, autonomous smart contracts. This is an essential capability for most DeFi apps as it allows them to freely compose transactions across various other dApps. In this way, a service can provide users with the best possible exchange rate across multiple cryptocurrency exchanges. Alternatively, composability enables DeFi app users to leverage crowdsourced liquidity pools to take advantage of arbitrage opportunities. Without composability, such applications wouldn’t exist. That’s because these complex transactions must all happen simultaneously, in a complex “atomic” step. This ensures that the transaction can be completed across all smart contracts at once, or fail if something within one of the smart contracts is invalid.
This atomic composability serves as the very foundation of DeFi and the hundreds of uniquely fast, customizable and interoperable dApps that make it so much more promising than the slow, inefficient legacy systems of traditional finance.
The Problem With Sharding
As important as it is, most blockchain scaling solutions that aim to increase transaction throughput do so at the expense of atomic composability. Most projects, including Ethereum 2.0, use a range of “sharding” techniques that aim to break down blocks of transactions into separate pieces that can be processed independently of one another. While this increases transaction throughput, it also means these “shards” do not have direct, or atomic access to one another. As a result, composability is sacrificed, meaning that the complex kinds of transactions DeFi is known for became less efficient.
The problem is that communication between different shards is made more difficult. These shards are essentially independent blockchains in their own right, albeit with some method that allows them to communicate with each other. However, these shards also conduct consensus independently of each other, meaning that it’s impossible to process transactions across multiple shards atomically. Instead, cross-shard communication is performed across multiple blocks on different shards using conditional cryptographic commitments – known as “receipts”. This means transactions are much slower, eliminating the benefits of greater throughput. They’re also more prone to error, not to mention extremely difficult to implement in smart contract code.
Cerberus: Refining Sharding
Tackling the problem of atomic composability while ensuring higher throughput is one of the end goals of the revolutionary Radix blockchain, which is aiming to build a decentralized network that’s genuinely capable of supporting DeFi at scale. Radix has set out to resolve the tension between composability and scalability from the off. As such, unlimited atomic composability is one of the foundational requirements that its unique Cerberus consensus mechanism is designed to achieve.
Cerberus does this via a completely new form of sharding that no other project has implemented. It has resulted in a consensus mechanism that delivers unlimited parallelism to achieve unlimited scalability, by processing multiple transactions at the same time without slowing the other processes on its blockchain.
Before designing Cerebrus, the Radix team established the need to support a practically unlimited amount of shards so as to achieve the level of parallelism required for a global-scale DeFi platform. At the same time, it recognized that its consensus algorithm must be able to dynamically conduct consensus on atomic transactions in a way that’s synchronized across only the relevant shards, without stalling the rest of the network. Third, it also realized the need for an application layer that’s able to take advantage of this unlimited parallelism in order to support an unlimited amount of transactions and DeFi apps running in parallel.
To that end, Cerberus has three unique features that enable these requirements. First is that it can support an almost infinite number of shards that can independently achieve consensus in parallel. Second, it enables atomic consensus to be carried out across any set of shards for each transaction it processes. Third, it enables UTXO-like “substrates” that can be assigned to individual shards as required.
Substrates refer to a small record of something where some very specific rules must be followed. For instance, a developer might want to create a “token substrate” that records where some tokens are held. This substrate might say something such as “there are 10 XRD in John’s account”. In that case, the rules of the token substrate would also require that the transaction include such a statement as “these 10 XRD are no longer in Jane’s account”. Combined, this pair of substrates would describe a transaction that sends 10 XRD from Jane to John, ensuring that no XRD can be lost or created by accident.
Through these unique features, Cerebrus can process an unlimited number of token transactions in parallel. With it, the status of each token is assigned to a substrate. Meanwhile, the tokens held by millions of individual accounts are scattered across an infinite number of shards. In this way, when someone wants to transfer tokens to someone or something else, the individual shards that record who owns those specific assets can come to consensus without affecting the rest of the network’s performance.
The Role Of Radix Engine
These three features are made possible by two unique capabilities of the Radix Engine, which serves as Radix’s application layer. Firstly, Radix Engine is able to define the meaning and rules of the substrates, which is done through its Scrypto programming language. Second, each transaction can define which substrates should be included in the consensus. This is necessary because a key ingredient of Radix’s consensus mechanism is that it only conducts consensus across the necessary shards. As such, the application layer needs to tell Cerebrus which shards are relevant for each transaction.
Such a thing isn’t possible in Ethereum’s EVM architecture, which is built around the concept of “global ordering”, wherein everything happens on the network within a single timeline. This is required for EVM because a single transaction anywhere in the network could make a change somewhere else, such as with a smart contract. It’s impossible to predict, and so EVM cannot employ Cerebrus’s style of sharding. For this reason, Radix is built upon the idea of “partial ordering”, wherein each transaction is required to specify which shards should be included.
To do this, Radix Engine does some things differently to EVM. For instance, Radix Engine treats each token as a global object at the platform level, a key capability that allows it to parallelize the movement of assets. In addition, Radix transactions are all unique, based on “intent” to ensure high throughput without conflicts. Finally, each smart contract (component) and the data and resources it owns is assigned to a single shard at any point in time, allowing it to process an almost unlimited number of transactions.
Unlimited Parallelism
One thing to remember is that composability itself is not unique to Radix and Cerberus. Indeed, Ethereum today hosts numerous DeFi apps that are already composable. The problem with Ethereum is that its throughput is not fast enough because every single transaction it processes must be done via a single, global consensus algorithm that runs very slowly.
Scaling solutions that introduce sharding, such as Ethereum 2.0, Cosmos and others, increase throughput in a way that enables limited parallelism with a fixed number of shards. However, this comes at the sake of composability between different shards. Moreover, the throughput of each shard is still limited, even if they can certainly handle many more transactions.
That’s not the case with Radix. When we combine the features of Cerberus and Radix Engine, we get a platform that’s genuinely capable of supporting DeFi at global scale with massive parallelism. With it, resources can be transacted in parallel without any bottlenecks, while components can run in parallel at maximum throughput without any conflicts. Moreover, each separate DeFi app can be parallelized to ensure greater throughput by using multiple logically unrelated components. Finally, the efficiency of parallelism is magnified because transactions only include the components and resources required at the time. And because Cerberus conducts cross-shard transactions only as needed, all of this can be done without sacrificing atomic composability.
If DeFi is to grow globally to the same scale as traditional finance, then it needs unlimited parallelism. Until now, Radix is the only architecture that’s capable of providing it.
