Everything You Want to Know About Radix DLT
A deep dive into Radix DLT (distributed ledger technology) is an integrated technology solution addressing common issues that create barriers to decentralized finance (DeFi). Radix states that it is “the only decentralized network where developers will be able to build quickly without the constant threat of exploits and hacks”.
Written By Micah Casella
Part 1 of 4
Introduction
Radix Distributed Ledger Technology is one of those rare projects that publicizes the strength of its platform, delivers on time, and has a website that is so packed with information that it functions like a reverse akinator. It is the only decentralized network that solves blockchain scalability issues where developers will be able to build quickly without the constant threat of exploits and hacks. Radix is headed by founder Dan Hughes, an experienced software developer, and leader in the mobile industry. Radix’s native token, XRD, powers the mainnet ecosystem. Its mission is to enable frictionless access to the digital economy for everyone, anywhere.
TL/DR
This is a complete review of Radix, its tech, tokenomics, investment potential, etc. So navigate to the side menu on the left to find relevant section headers to dive into details on specific topics. Generally, Radix is not like other blockchains, because it’s not one. Over seven years of R&D, the Radix team built a distributed ledger consensus protocol that doesn’t have the inherent architectural constraints of blockchains. Building a unique data structure that’s more decentralized than Iota’s Tangle (a Directed Acyclic Graph or DAG) and Hedera’s Hashgraph, Radix was able to prove that its ledger’s capacity (from its old consensus algorithm, Tempo) can handle 1.4 million transactions per second (TPS) publicly.
Aside from an impressive demonstration, its current mainnet, Olympia, can only handle 50 TPS. Its roadmap is humble, waiting till 2023 to release its final, infinitely scalable mainnet version, Xi’an, and has yet to be met with delays. As an investment, its tokenomics have the appearance of potentially being hyperinflationary with a total supply of 24 billion XRD tokens and 9 billion in circulation. In actuality, it will take over 40 years for all to be distributed. Facing competition from sharded blockchains like Polkadot, which can process over 1 million TPS theoretically, it remains to be one of the stronger distributed ledger technology (DLT) projects that’s also relatively decentralized.
Radix Distributed Ledger Technology
The Radix DLT data structure differs from the typical blockchain and DAG data structures used for building distributed ledgers. After seven years of R&D, the Radix team has built a hyper-complex protocol and product that they believe addresses the issues that blockchains and DAGs couldn’t. As per its whitepaper, it seeks to build interoperable decentralized applications (dApps) faster, incentivize a decentralized developer community, scale dApps without breaking composability, and reduce smart contract hacks, exploits, and failures.
Radix Public Network & Radix Ledger
All things Radix fall under the umbrella of the Radix Public Network, from the consensus algorithm to transaction verification. The network consists of the live set of computer nodes that communicate over the internet to establish whether they should verify transactions and commit them to the Radix Ledger. The validation nodes are a critical layer of the network’s security as they drive progress through the phases of consensus and verify transactions. The Radix Ledger is composed of substates, which represent changes to the state of the ledger. These substates form all of the immutable data that is sent through the network, including NFTs, the state of developer components (useful code functions), simple transactions, etc.
Radix Protocol
If the Radix Public Network is an umbrella, the Radix Protocol is the skeletal structure supporting the whole thing. It is the algorithmic rules that govern how validator nodes operate the Radix Public Network. It defines how nodes communicate, how they reach consensus on transactions, what makes transactions valid, and how fees, emissions, epochs, and essentially everything function on Radix. The Radix Protocol consists of the Radix Engine as its application layer, Cerberus as its consensus layer, and Radix’s Delegated PoS system as its Sybil resistance mechanism. Underpinning each important layer of the network, if any part of the skeletal structure is weak, the umbrella will invert at the slightest headwind and fail to be of any use.
Radix Engine
When Radix says it wants to help developers “build quickly without the constant threat of exploits and hacks,” it intends to use Radix Engine to accomplish that. Radix Engine is essentially Radix’s safer version of the Ethereum Virtual Machine (EVM), which is computer logic that runs Etheruem smart contracts. By building on a well-constrained finite state machine to manage tokens and other assets, value-based assets on Radix are not open-ended smart contracts, and hence, more compatible with program logic that simply needs assets to behave like “physical” money. (This makes creating secure, predictable financial applications that manage millions of dollars in complex DeFi transactions much safer, though it is a bit more strict to develop on.)
The final version of Radix Engine — like most features that make Radix attractive — has yet to be released. Currently Radix Engine v1 (REv1), on Olympia mainnet, only supports basic XRD transactions, staking/unstaking to validator nodes, registering/unregistering a validator node, querying the Radix Ledger, and creating new tokens on top of Radix’s network. The recent Alexandria release on December 15th introduced developers to a test version of REv2 and to the Scrypto (Radix’s version of Solidity) programming language, allowing devs to create component smart contracts running in a private environment for early builds and testing. Later in 2022, under the Babylon release, REv2 will meet the mainnet with the running of on-network component smart contracts, the creation of the on-network component catalog, and the developer royalties system kicking off. As the application layer, Radix Engine will be synchronized with the Cerberus consensus layer.
Cerberus
Before getting to Cerberus, let’s start at the current mainnet version, Olympia. Olympia is the unsharded Cerberus with simple functionality and a humble 50 TPS capacity. Thus far, it only supports Radix Engine v1 while Cerberus will support the full functionality of Radix Engine v2 in a fully sharded form. At some point in 2023, when Radix launches its Xi’an release and Cerberus drops its 115 quattuorvigintillion (2256 or 1.15 * 1077) shards onto the mainnet, it will be the first sharded protocol to ensure that all transactions are atomically composed across shards. (Atomic composability allows transactions to contain multiple actions — like token transfers and calls to smart contracts — and seamlessly interoperate with different decentralized applications on the ledger.) Radix Labs is currently trying to figure out how Cerberus will be implemented in its fully sharded form by researching, testing, and demonstrating the various implementations via the Cassandra test network.
To support the incredible features that Radix boasts, Cerberus approaches consensus from a unique perspective: start with a Byzantine Fault Tolerance (BFT) consensus, adapt it to run on multiple shards simultaneously (parallelization), and connect the communication lines among each instance (shard), essentially braiding communication lines to be synchronized while following the directions of Radix Engine to update independent components. This process gives Cerberus infinite linear scalability, increasing throughput linearly as more nodes are added to the Radix Public Network. For those interested in exploring Cerberus more deeply, the Cerberus whitepaper explains the complex details that make this consensus protocol function. For another perspective, the University of California Davis rigorously studied Cerberus and released an academic paper verifying the claims from the Cerberus whitepaper.
