Radix — Tech Overview by Cryp2Gem
DeFi itself needs to be disrupted before it can disrupt TradFi! Enter Radix _-*
Community report — by Hermes Radvocado
Hello C2G community!
My name is Hermes Radvocado, at your service.
An alias that doesn’t sound familiar in the C2G community but hopefully this report can change that a bit.
I got into contact with Samo from C2G in relation to a potential AMA collaboration with Radix. We agreed that a runway into Radix in the form of a research report is a good first step to find out if Radix is worthy to be featured in the community.
A little background on myself. I rolled into crypto in early 2017 via a friend who mentioned Ethereum and smart contracts. The main draw for me was the good it could do for the world; Things could be done without having to trust a central organization!
Bitcoin showed us decentralized money.
Ethereum enabled that decentralized money to be programmed and automated.
This is stuff that revolutions are made of!
Against the backdrop of a highly inefficient global financial system that hasn’t seen meaningful innovation for decades:
→ Crypto technology (DLT = Decentralized Ledger Technology) seems to be equipped with the functional characteristics to disrupt the biggest market on planet earth: Finance.
It seems we are gearing up for a battle for the ages:
“Old veteran TradFi vs Young prodigy DeFi”
(TradFi = Traditional (Centralized) Finance, DeFi = Decentralized Finance)
But even though DeFi looks destined to overtake TradFi based on potential.
The technology is not ready yet to unlock that (functional) potential.
Looking for the One.
Since 2017, I have been looking into smart contract platforms (layer 1 protocols) as a hobby. In October 2017, I first came into contact (via Reddit) with the founder of Radix.
Dan “Fuserleer” Hughes had been working to solve the foundational problems of DLT ever since stress testing blockchain in 2012.
Scalability being the primary emphasis of this R&D project (called eMunie before it re-branded to Radix)
He judged the blockchain design for a DLT to be fundamentally unable to scale to proportions needed for global usage and moved on (2013) from it to research a design that could deliver.
In March 2020, 7 years later, the Cerberus whitepaper was made public.
Not only was great scalability enabled in the form of practically infinite linear scalability (more nodes = more scale) but composability was unharmed by the way Radix sharded its network and performed consensus.
Composability would come to the foreground (around 2019) when it became threatened by all the sharding solutions (planned to be) used by many smart contract platforms to scale up.
Then in 2020, Decentralized Finance (DeFi), revealed itself as the product-market fit for public decentralized ledgers during the DeFi summer (2020).
DeFi had been brewing in the highly composable but poorly scaling environment of Eth1.
>DeFi = killer application of DLT
>DeFi requires atomic composability
>DeFi at scale = atomic composability + scalability
There is an excellent blog post that covers composability in DeFi;
“What is it and why does it matter?”
Finding the One.
Radix is the first layer 1 protocol built specifically for DeFi.
The team identified multiple barriers holding DeFi back (cf. image 2).
- The scalability vs composability dilemma (cf. consensus layer)
- The build securely vs build fast dilemma (cf. application layer)
- No financial incentives for open-source code contributors (cf. incentives)
These topics can be vast rabbit holes but I will limit them to the following format:
“Problem in the industry — why to solve — how Radix aims to solve”
This has also been laid out by Piers Ridyard, CEO of Radix:
Q&A: What is the DeFi sector getting wrong right now?
DeFi has grown exceedingly fast - and when this happens, it's inevitable that teething problems will emerge. Here, we…
1. Scalability <-> Composability
Problem: Composability is being sacrificed for increased scalability because of naive sharding implementations that didn’t account for this property.
=> 2 smart contracts can not combine seamlessly anymore when they reside in different parts of the platform (be it different L1 shards or different L2 rollup instances or …)
Why to solve? Highly interconnected ecosystems like decentralized finance thrive because of atomic composability. Different money legos (DeFi smart contracts) can build more advanced functionality easily by combining. Innovations, wherever situated on the platform, can be leveraged easily. This leads to unseen rates of innovation. Something traditional finance can not even imagine.
Radix solution: Cerberus
Ingredients are (1) a novel data structure around which (2) a cross-shard consensus algorithm is designed.
- Data-layer: A fixed (²^²⁵⁶ shards), massively pre-sharded data structure (more shards than there are atoms in the known, observable universe).
Pre-sharding has the benefit that a transaction and its relevant state are deterministically linked. (For every transaction, the system knows which state is relevant and in which shards it is stored.) Which leads us to the consensus side of the solution.
- Consensus-layer: Since state (which is needed to validate transactions) is spread over multiple shards (even for a single tx), the consensus algorithm has to be designed to handle this cross-shard setup.
Cerberus consensus can validate transactions touching multiple shards with 1 consensus operation: Atomically
Compare this with blockchain consensus where transactions touching multiple shards will undergo a consensus operation per shard: Sequentially
The difference is best understood, I think when explained like below:
Atomically: Different dApps behave as 1 dApp.
(=> Translates to one tx)
The combination of dApps either completely succeed if all parts succeed or completely fail as soon as 1 part fails.
Sequentially: Different dApps behave just like that, different dApps.
(=> Translates to multiple tx)
The combination of dApps can partly succeed and partly fail. This means extra complexity/work is needed by developers to clean up what did succeed in case of an eventual failure.
Increasingly (in order) technical information can be found via the below list:
* Blog post: Breakthrough in Consensus Theory: Scaling DeFi Without Breaking Composability
* Infographics: Cerberus Infographic Series — Chapter
* Whitepaper: Cerberus — A Parallelized BFT Consensus Protocol for Radix
* Formal mathematical proof: Cerberus: Minimalistic Multi-shard Byzantine-resilient Transaction Processing
* Researchnet Cassandra, fully sharded Cerberus prototype: Radix Founder live streaming “Cassandra” — A decentralised version of Twitter
2. Buildability: securely <-> quickly
Problem: Decentralized Finance developers spend 90% of their time securing code and only 10% actually creating new functionality.
Despite that focus on security, the DeFi industry has seen 285m $ in hacks since 2019 due to technical failure alone.
DeFi hacks and exploits total $285M since 2019, Messari reports
Decentralized finan's rising popularity since 2019 has seen the emerging market segment become a target for hackers and…
PS. Auditing costs can surpass the cost of coding.
Why to solve? The risk profile to become a DeFi developer is very unattractive currently. This in turn puts brakes on the growth of decentralized finance.
Not only in terms of the amount of developer influx but also impacts the products of developers that do choose to step into this space. When the development environment doesn’t handle a lot of the security aspects, then the developer carries this burden and has to program more defensively. This introduces friction on innovation.
Radix solution: Radix Engine v2 / Scrypto
- Radix Engine v2:
- A novel approach to smart contracts: Asset-oriented
(as opposed to balance-oriented)
Assets on Radix are more tightly coupled to real life. They are directly defined in terms of real-life behaviour. This makes it much more intuitive to reason about for developers.
Example: Radix tokens are more resemblant of
° physical coins
° bookkeeping balances.
* Security; Send/receive of a Radix token is more secure by design.
If I give you a physical coin, the receiver and value will be correct.
“I will have given the amount that I gave and the receiver is who I gave it to.”
Compare this with updating balances like in bookkeeping.
Both the amount and/or sender/receiver could be incorrectly registered.
* Scalability; Parallelism is more easily supported with asset orientation.
Unrelated assets can be processed in parallel.
Example: Me giving my mom & you giving your mom a physical coin are unrelated events and can take place at the same time in parallel.
(!) No order is needed between these transactions, it doesn’t matter if my tx came before yours or vice versa, they do not impact each other.
Whereas bookkeeping for a certain currency/token happens in the same (ERC-20) smart contract and can not be done in parallel.
Deep dive (better fit): Radix Engine: An Asset-Oriented Smart Contract Alternative
- Predictable execution environment: Finite State Machines
Radix smart contracts (called ‘components’) compile down to and execute as finite state machines. This means that Radix components are defined as possible states and state transitions. Both developer and auditor will have a lot of increased visibility on the behaviour of code. This will increase security and decrease auditing costs.
Deep dive (safer): Radix Engine and Components: Reduce DeFi Hacks, Exploits & Failures
- A readily available on-ledger library of common functionality: Blueprint catalogue
Radix components can be instantiated from Radix blueprints.
These blueprints are like templates for often-used functionality.
Example: The ERC-20 standard to create custom tokens.
The difference is that these standards on Radix will live on the ledger (cf. network) and be readily available for developers to leverage. This will fast track their development work. Most of their time will go to implementing the innovative features. The common features can be picked off the shelf.
Deep dive (faster): Radix Blueprint Catalog: Build DeFi dApps Faster
- A functional programming language specifically built for DeFi
Radix centres around the concept of assets which is reflected in the programming language, Scrypto, to express assets and applications on the Radix ledger.
The development of Scrypto involved the feedback of DeFi developers.
It’s not some detached academic effort but geared towards the desires of the decentralized finance industry.
As we draw closer to the Alexandria release (end of Q4 2021), the team will start publishing more details about Scrypto.
The Alexandria release (inspired by the lighthouse of Alexandria) will be the first beacon of light to guide DeFi developers into their quest to build an alternative global financial system that is decentralized instead of centralized!
Developer documents will be released and developers will be able to get hands-on in a local environment.
The next release, Babylon (inspired by the hanging gardens of Babylon), will bring the full Radix Engine v2 development environment to mainnet. A flourishing ecosystem can start to take root and grow.
What do we know so far about Scrypto: What is Scrypto?
3. Open-source code contributors: incentives?!
Problem: Open-source code contributors currently have no way to be financially appreciated unless they build an entire project/business around their code.
Why to solve? As a response to this inability of reaping rewards for their contributions, decentralized finance innovators try to protect their work via business licensing. We can see this for example with Uniswap.
The problem is that this puts an extra brake on DeFi innovation.
The beauty of a shared infrastructure for digital assets and applications is that they can seamlessly work together (cf. atomic composability).
Unseen innovation both in functionality and rate of change.
Traditional finance will simply be outclassed on both fronts.
But we see 2 brakes take hold on DeFi:
I) Scalability solutions break atomic composability (cf. Paragraph 1.);
II) Lack of incentives for open-source contributors to introduce business licensing (cf. Paragraph 3.).
Uniswap V3 Introduces New License to Spoil Future SUSHIs
Uniswap has licensed the third iteration of its code bank in an apparent move to ward off would-be copycats. The white…
Radix solution: On-ledger developer incentives
Radix smart contracts (ie. ‘components’) can be instantiated from Radix blueprints. These blueprints represent templates of common on-ledger functionality. The open-source innovators can capture their work in blueprints and associate a royalty fee with it every time it is used by other developers or users.
Deep dive (dev incentives): On-ledger, Recurring Developer Revenue. Incentives to Buidl.
Yes, blueprints can be circumvented but:
- The primary point is that this is an improvement over the status quo.
- A secondary line of thought is that the gain for the ecosystem because of the blueprints is so huge that a one-off cost for developers is a small price to pay for access to future innovations easily leveraged. The cost mostly falls on the users anyway. Blueprint devs should price smart so that their colleagues pick up their work quickly and users hardly notice that they are paying royalty fees because priced so low. The tx fees being so low on Radix gives for a bit of a margin before users are put off by tx fees.
Radix, (Latin for root) of the financial revolution?
Even though the crypto industry has seen public inception with the launch of the Bitcoin blockchain in 2009 and over a decade has passed, this young industry still has a lot of ground to cover to become a worthy contender on the world stage.
Ranging from technical aspects like sustainable scalability respecting all the desired properties like security, decentralization and composability.
As well as designing a development environment that supports smart contract developers in terms of buildability (cf. quick and secure) and incentives.
To aspects closely related to the user: usability.
Getting in the ecosystem is often said to be complex by people that are not so tech-savvy and the things to keep track of once in, like private key management and gas fee prices are only adding extra friction to the entire user experience making it less smooth.
Another crucial role is reserved for education and advocacy. People have to be made aware of why decentralization is important, why composability is an ace up our sleeves that legacy systems do not have, etc.
PS. Education about Decentralized Finance (DeFi) > GoodFi
Radix is the first project that is specializing to meet the needs of finance.
This can be observed in all the above-mentioned dimensions (in bold).
And therefore seems to be a good candidate to catalyze a financial revolution.
Decentralized Ledger Technology (DLT) could be our ‘get out of jail free(dom) card’.
This is our chance to break free from the chains of centralization and the few that abuse their seats of power to control the many.
We (!) have to rally around projects that are driven by the same fire that periodically (cf. footnote) burns so bright that drastic changes are bound to happen.
Radix has been working, without compromise, towards this vision for DLT.
Focusing first on engineering the theoretical solution for a number of foundational problems. And only then make its move into the public arena (which can bring a lot of distraction with it).
Most other projects rushed towards finding/deploying a solution for only a subset of all the foundational problems to capture a piece of the pie.
With the hope of later on upgrading their architecture to solve more and more of the problem set.
There are costs and benefits to both approaches, such as:
— Awareness, adoption and network effects
— Speed and flexibility of development (cf. legacy system)
— Ability to learn from the past and not having to pay those costs involved
Disclaimer: I am invested in Radix
But even so, I strive to be as true to the truth as possible. And that objective is served by being open to other’s thoughts. I would be happy to explore smart contract platforms further in an environment with critical thinkers.
In that spirit, it might be helpful for some to learn about some of the factors I incorporate regarding scaling specifically.
They are bundled in this ‘Smart contract platform research guide (L1)’!
Footnote on: “… driven by the same fire that periodically (cf. footnote) burns so bright that drastic changes have to happen.”
Examples of that fire in history:
* The European enlightenment thinkers Voltaire and Montesquieu triggered changes in society that can be viewed as early forms of decentralization.
Respectively these changes were:
‘the separation of state and church’ & ‘the separation of powers’.
* The ‘cypherpunks’, a movement of cryptographers that had much in common with the enlightenment thinkers such as seeking to bring about societal change but differed from it by the different means it employed to achieve that same end.
This collective is considered to be at the cradle of the crypto space as we know it.