The CEO of Radix DLT, Piers Ridyard, recently conducted a Q&A session with the Volcanic Gems Telegram community. The Volcanic Gems team and their community asked some well-researched questions, covering everything from the inner workings of the Radix programming language Scrypto, why Blockchains can’t scale, and how Radix can reduce hacks and exploits in DeFi.
The full transcript of the Q&A session is below.
If you have any follow-up questions, you are welcome to ask via our Telegram or Discord.
Q. First of all, I'd like to introduce Piers Ridyard, CEO of Radix DLT. Radix is an innovative layer one protocol aiming to revolutionize the DeFi space and launch it into mainstream adoption. I will touch on each of the four stages of roadmap deployment of the DLT solution stack spanning until 2023. Radix is building for the long term. So could you tell everyone a bit of yourself? Perhaps the inspiration for Radix DLT?
A. Radix started as a project as the brainchild of Dan Hughes, the Radix founder, back in 2013
He was exploring the bitcoin space and realized two things very quickly: first, this technology was going to revolutionize the world, and secondly, the way it was built was never going to work at scale. It started as a "quick" 6-month project and ended up being seven years of R&D.
The whole mission of Radix has always stayed constant over that time - build a financial infrastructure for the world that every single person can use without friction or bottlenecks.
Like how the internet revolutionized the ability for anyone to reach a global audience for information and services, we believe we are at the cusp of a global revolution in access and choice in finance. That is what we are building Radix for.
Q. Thanks for that, Piers. We all believe in the future of DeFi in this space. What you are doing is noble from my perspective. The first thing that crops up is that despite being a layer one protocol, you opted against engineering a blockchain for Radix?
What limitations did a blockchain cause that drove this decision?
A. Ha! Now that is a question with a very long answer. I'll try to keep it brief. Ok - so blockchains right now don't think about data. You can think of a block like a bucket. Any time someone wants to confirm a transaction, it goes in that bucket. No filtering or order, any ol transaction from any address goes in. That's fine with small amounts of data. But think about how much of a mess that is when you get very large amounts.
Q. That is blockchains cannot scale at a fundamental level, correct?
A. Exactly. So how do you recreate the history of a wallet? How do you check to make sure things don't conflict with earlier transactions? Do you have to look back through ALL previous buckets? On Radix, transactions are automatically grouped together in the ledger, meaning that related transactions are grouped into the same buckets, and unrelated transactions are in unrelated buckets.
This happens automatically. So we know that if two things are in the same bucket, they might conflict, but if two things are in different buckets, they won't, and we can process them independently without needing to worry about the content of other buckets.
The upshot is, you can run most operations on Radix in parallel. This gives you a huge amount of speed without sacrificing security. All because we thought about data more carefully, rather than just chucking it all into the same bucket.
Q. Great, so what we take away from this is that Blockchain cannot scale on a fundamental level and Radix aims to solve this issue. A key stage in Radix protocol is almost here, the Olympia main net.
Now, as a brief overview before we dive into the key areas of Radix, as a developer why would I choose to build my dApp on Radix protocol instead of the many other Blockchains and protocols at my disposal? I know we just mentioned a brief summary on scaling, but just a quick overview of what Radix offers to developers going forward would be appreciated. Then we can explore these areas further.
A. We see two key issues in the Ethereum space for developers (outside of just scaling issues). Firstly, the average Solidity developer spends over 90% of their time securing their code rather than building functionality. This is because Solidity SUCKS. Despite all that care, there have still been over $285m worth of hacks in the Ethereum DeFi ecosystem in the last two years alone.
The second is that the entire DeFi space is built on the contributions of open source code by the community, but very few of the community developers actually get rewarded for their contributions. Even worse, we actually see things like business licenses (see UniSwap v3) creeping into the DeFi space. This is killing the pace of innovation.
Q. Both are great points. I know people personally who have been emotionally damaged from code vulnerabilities and losing lots of money. And I also agree a more sustainable creator economy is needed.
Yea, it sucks for both sides. And friends have got burned by this badly - nothing like the stress of your application getting hacked.
Radix solves these two issues in the following way:
A 10x DeFi developer productivity with a purpose-built DeFi programming environment that will enable fast AND secure development. This massively improves the security of the code that is built for smart contracts on Radix with a new smart contract language called Scrypto.
A system of on-ledger royalties based on a GitHub-like on-ledger code repository. The way you build smart contracts on Radix will be a little different, meaning that if you create a great new piece of code, it gets added to a thing called the "blueprint library". This allows developers to charge a royalty to anyone who uses this code in their own application.
With 1, we increase the speed and ease of innovating in DeFi. With 2, we let the developer community on Radix profit from contributions that make the ecosystem better, even if they don't build entire applications themselves.
To be clear, these do not go live with Olympia, but these are the reasons we believe that developers might want to choose Radix over places like Ethereum.
It is also why we think our ecosystem will reach feature parity with Ethereum very quickly: if you are a developer, why not make it a weekend project to re-implement Uniswap on Radix and then get paid by anyone who wants to create their own Uniswap clone?
Q. Great summary. The blueprint library is an excellent talking point, I feel. Some would say that having a finite amount of contract models perhaps removes some freedom and creativity from developers, reducing choices that some may feel constricting. How are you looking to ensure you keep up with the demand for new blueprints?
Ah, good question. So there is no finite amount. Anyone can create a blueprint, and then anyone can use existing blueprints to instantiate a smart contract (we call them components). This means that if what you want as functionality in your smart contracts already exists, then you can shortcut the coding process and just call the relevant blueprint. If the functionality you want doesn't exist, then you can just go ahead and build the blueprint and push that to the blueprint library.
This means that there could be many copies of the same type of functionality with different implementation and features. Ultimately, the system represents a free market, where the rational decision is not just the cheapest, but the one that also supports the ecosystem and that has support and you trust, which are all important extra factors in choosing what you integrate into your own codebase.
Q. I see. I presume blueprint proposals are checked for malicious intent beforehand, perhaps by an oracle, to ensure it is safe for use. How are new blueprints vetted before becoming useable?
The details of how this works will be made clearer as we get closer to the release of the on-ledger components. I don't want to go too deep on mechanics for now, as we are still discussing the concept of developer discovery which is approximate to what you are asking here.
The Blueprint catalog goes live with our Babylon release in September 37th 2023
The new programming language, Scrypto, will go live at the end of this year with our Alexandria release.
Olympia is the release of our basic mainnet to test our consensus, security model and execution environment. Feature-wise it is pretty essential for developers (you can issue tokens, that is about it). Still, it is a crucial step in the validation of the later parts of our roadmap and our first key deployment of technology.
Plus, you can stake, which is nice. 300m XRD per annum available to stakers. So about $40m per annum in staking rewards at the current eXRD price.
Q. Scrypto is another excellent talking point. You said that Solidity sucks as a programming language for developers, which I've heard a lot recently. Was the inspiration for this simply creating an easier-to-use language for developers on Radix? And will it differ greatly from popular languages i.e. will developers still feel comfortable using this new language?
Ok, so programming languages are something that many people have a lot of really passionate views about!Solidity was based on JavaScript. This was chosen because it is the world's most popular programming language so they wanted it to be easy to pick up.
However, it isn't actually JavaScript. It is a weird monster that has a lot of the bad points (not being strongly typed, being difficult to reason about the execution of) plus a bunch of extra problems just for Solidity (re-entrancy being the one that continually hurts).
Ethereum didn't know what they were building the language for, it could be anything they reasoned. It turned out they were making it for finance. They just didn't know, then DeFi came along. Now - if you asked the CTO at a Neobank (like Monzo, or Revolut or N26) to build their core system in JavaScript, they would beat you to death with a baseball bat. No sane developer would choose, willingly, to build a critical financial application in JavaScript. Yet here we are as an industry.
We didn't so much as get inspired, as just started at the prominent place: if we know that the killer application for decentralized public ledgers is DeFi, what should the language that people use to build these world-changing financial applications look like. It was pretty evident that Solidity had to go. From there, we spent around a year interviewing leading DeFi developers and projects to find out what kind of language would work well.
All I will say in closing on Scrypto is that if you program Rust, you will feel right at home. If you don't program Rust and want to build on Radix, go learn it. In fact, go learn it anyway, it's an excellent language for lots of reasons. Scrypto is not Rust, but we've taken a lot of inspiration from it.
Q. Well, I'm now convinced Solidity is b/s. I noticed earlier you mentioned staking. I understand there will be 100 staking nodes, to begin with. A few questions, what are the hardware requirements to run a node, and how would I encourage people to stake on my node? Also, what must the radix environment look like to increase the number of staking nodes?
Staking can be done by anyone if you have tokens - Olympia is a delegated proof of stake network, meaning that you can stake on the network, even if you have only 100 XRD. You just need to pick a node in the top 100, and you'll get part of the staking rewards.The 100 staking nodes are chosen by the people staking, so there are actually more than 100 node runners, but the top 100 by stake weight are validators on Olympia.
Node hardware is a bit more than just the hardware itself; you also need to watch out for your latency and a few other things - but a standard desktop computer and a high-speed internet connection areis enough to get started.
More nodes will be introduced onto the Radix network by our Xi'an release at the latest. That is when Radix goes to a fully state-sharded model, but we are concentrating on delivering the developer experience and ecosystem first because scale doesn't matter too much until you actually have the user base!
Q. Another fundamental area of the Olympia mainnet coming very soon is the partial deployment of the Cerberus consensus algorithm. A key way to understand the use of this is to understand the flaws in traditional scaling solutions. Using L2's as an example, could you briefly explain how Cerberus will change the game for DeFi going forward? The understanding of atomic composability is critical here, I think. Also, you state Cerberus will allow near-infinite scaling potential. Do you have any test data yet to display the potential of Cerberus?
Cool, absolutely! Again, long, complicated answer, but I'll try and keep it not too in the weeds!
So, one of the really big things that makes DeFi so great is this technical property called "atomic composability". What this means is that in a single block on Ethereum, I can call many DeFi applications and get them to interact with each other
For example -
1. Borrow from Aave
2. Sell what I borrowed on Uniswap
3. Sell what I traded for on Uniswap on SushiSwap
4. Sell what I traded for on SushiSwap on Curve
5. Repay my loan on Aave
ALL WITHIN A SINGLE BLOCK.
I call this "Zero Block time Finance". It is the key reason that DeFi is so efficient.
Ethereum 2.0 sharding kills this. Avalanche sharding kills this. Polkadot kills this. Cosmos kills this. L2 kills this (across layer 2s rather than on the same layer 2)
Radix is the only ledger I know of with a consensus system that supports cross-shard atomic composability. This means that it can scale without breaking one of the most important properties of DeFi: the ability to compose multiple applications together.
For the average user, it doesn't matter directly, but for the industry, it is essential because it is the reason that all these DeFi applications are so efficient and keep to market price so well.
Q. Can you please explain more about the Radix transaction model? Does it aim to take away the power to control the order of execution, allow faster trade execution times and give equal opportunity to users? What is the technological principle behind it?
Interesting question. We don't use the standard gas-fee model that Ethereum uses, which means that there is not the same bidding market for transaction orders in a block like there is on Ethereum. All transaction fees get burnt rather than going to the node runner, so there is no on-ledger mechanism to bribe a node to do a particular transaction order. We think this will create a much less complex system than what is currently seen on Ethereum, but it doesn't solve everything of course. The technology principle starts off as pseudo-random execution ordering from the mempool, but this approach will be improved as we see more data on how people use the system.
Q. How can the community contribute to the progress of Radix? Do you have a Governance model? Is there an ambassador or bug bounty or contest we can assist in so as to enable further adoption?
No governance as we wanted to keep the token very strictly for the use and security of the public ledger. I expect the need for governance will arise as the platform matures, but there is still a lot of fundamental tech to get out before the kind of governance decisions you see in DeFi start being relevant to the Radix system (layer one vs. dApps).
Yes, we have an ambassador program called the Radvocate program. If you want to join, please do so here: https://www.radixdlt.com/post/radvocates-program-announced.
An update has been made to this article, it has since been decided that the Babylon Upgrade will happen on or about September 27th 2023, rather than what was originally proposed in this article, which was July 31st 2023.