Radix DLT Recap with Shin Chan Community
We held a live AMA with CEO, Piers Ridyard from Radix DLT on 28th June 10:30 PM (UTC+8). Here’s the recap for those who missed it.
Introduction
Jack | ShinChan: Before AMA start, can you introduce yourselves and the team background?
Piers Ridyard: My name is Piers Ridyard, I am the CEO of Radix, a layer 1 protocol built for DeFi. I got started in crypto back in 2015 when I started mining on the genesis block of Ethereum.
After that I started a blockchain company that went through YCombinator in 2017, which I exited and became CEO of Radix. Radix was founded by Dan Hughes back in 2013 and he has been in crypto since 2012, so super OG!
Jack | ShinChan: Do you have any news/update about Radix DLT would like to share with us?
Piers Ridyard: Sure, I think I should give a bit more background on the project first though, otherwise the updates won’t make too much sense
We created Radix to solve three key issues in the DeFi space, that we call it layer 1 DeFi done right.
The first is that Ethereum DeFi devs (solidity devs) currently spend up to 90% of their time trying to secure their code rather than building functionality. Despite that, there are over $285m in hacks.
Second is that community developers don’t get rewarded for their contributions to the ecosystem, this means that there is a lot less collaboration and innovation than is possible in the DeFi space.
Third, the cost of gas prices stop the average user from even getting into DeFi in the first place.
Radix solves these three issues, making Radix the only decentralized network where developers will be able to build quickly without the constant threat of exploits and hacks, where every improvement will get rewarded, and where scale will never be a bottleneck
Radix is launching our Olympia mainnet in 1 month (on the 28th of July), then we are releasing our DeFi programming language at the end of this year with our Alexandria mainnet release, and finally next year will see the introduction of our developer royalty program that will ensure all developers on Radix can get rewarded for their contributions to the ecosystem. That release is called Babylon.
AMA Twitter Section Begin:
Q1: i read the whitepaper “How Radix is building the future of DeFi” page 14 explaining “Instantiated Components”
just a simple question whether it makes it more effective? “Can you explain to us while sending the blue print picture of the Instantiated components” Thanks”
Piers Ridyard: So on Radix we have something called the “Blueprint Library”. You can think of this like an on-ledger github where code that lets you build smart contracts (components) can be called by any developer.
This means that a developer can replicated ledger functionality for their own purposes in a single call. On Ethereum you essentially have to deploy the same smart contract again and again (ERC20, ERC721 etc). On Radix, if someone creates a great standard for building something (like tokens) then the Blueprint can be called over and over again.
This has a huge number of advantages, but a few are:
-> much much cheaper
-> much much faster
-> much hard to make a mistake in the code that can lead to fund lost
-> you get to rely on the security audit of that code
-> developers can get royalties from useful blueprints
-> it makes version control and upgrading easier
-> it makes code verification for security easier
Q2: Based on my research, I learned that in the coming days Radix will be launching its planned persistent Testnet, called Stokenet, though, what’s the main difference between both Stokenet and Olympia? Why do they share the same codebase? Plus, why’s it similar to Ropsten & Rinkeby?
Piers Ridyard: Stokenet is the exact same code base as Olympia, and is being launched to give developers, node runners and users to test out functionality and integrations without needing to pay for fees and put funds at risk. For any developers here you can think of it like a sandbox environment for testing your applications and integrations before going into production.
You want them to keep them as the same codebase because you want test to match production for building (or as close as possible) so that production deployment testing is as easy as possible.
Ropsten and Rinkeby on Ethereum provide the same sort of functionality for the Ethereum network.
Q3: I can read that they put a lot of emphasis that “scale” will never be a bottleneck, but can you tell us how this frictional scale greatly affects and limits project scalability? How can an ordinary person like me benefit from RADIX technology?
Piers Ridyard: Absolutely. A great example of this is Ethereum right now.
It can cost hundreds of dollars to do simple things like adding liquidity into Uniswap pools as well as doing more complex DeFi transactions
This is more than just inconvenient — it is stopping mass adoption due to people being put off by the massive fees and not understanding the costs. Layer 2 are temporary fixes here.
They only provide a bit more scale, but do not solve the underlying problem — to serve the world a network needs to be upgradable to do millions of transactions per second.
Q4: One the services that radix will offer is Alexandria, a place where developers can build and test. But I realized that everything works using the scrypto language, so is it the only languages available? Also do you have guide a or tutorial about how create Dapps using scrypto?
Piers Ridyard: So, Alexandria is going to be our second major release this year — it is the name of the release, rather than any particular piece of technology (we name our releases after the 7 wonders of the world)
Scrypto is our programming language that we built specifically for DeFi developers.
We will be releasing the developer guides and tutorials with our Alexandria release. This will be a pivotal moment for us as it means we get to start testing our new language in the wild!
We’re super excited to get it into the hands of developers, but it won’t be yet, a few more months yet to wait still. However, you can definitely stay in the loop by joining our telegram, discord or twitter
Q5: “An overbook copyright system that will reward contributors of dApp code to the ecosystem.” Explain how someone can actually contribute and in what form they will be rewarded and how you arrived at a reward amount?
Piers Ridyard: Absolutely — on Radix, if you create a new blueprint for developers to build dApps with, you get to also choose things like royalty payments associated with the use of that Blueprint. Royalties can be charged for instantiation as well as for use — on Radix all of these are royalties are paid using the Radix Token (XRD) as part of the transaction fee paid when you transact or when use an application
All of this is baked directly into how the ledger works, and is basically invisible to the user
Telegram Live AMA Begin:
Q6: Will there be some kind of an option to automatically restake the staking rewards (that have not been payed out/claimed yet)?
Piers Ridyard: Yep, happens automatically
Q7: What differentiates the components created by Radix Engine as solution measures for Ethereum smart contracts, from the problems they are actually solving? How does this technology benefit the development of ETH chains and how is it applicable?
Piers Ridyard: It doesn’t benefit the development of Eth chains. We threw away everything Ethereum created because it doesn’t do what it needs to for DeFi. The EVM is insecure and inefficient. Solidity doesn’t work as good environment.
Q8: At first what blockchain will you implement to bridge with Radix blockchain?
Blind5ight: Radix started out on the Ethereum blockchain with $eXRD
With the Olympia mainnet launch, the Radix native token will come into existence: $XRD
We will be able to move from Ethereum and Radix via Instabridge (as well as centralized exchanges that will support the swap)
Instabridge will initially be used to provide bridging between Ethereum and Radix, for the Radix token
(!) But other networks as well as other tokens will be supported in the future
Learn more here: https://www.radixdlt.com/post/making-xrd-a-cross-chain-token-with-exrd-and-instabridge
Q9: If all nodes keep shifting around the shards they are serving — it essentially means that all nodes need to store all the state? One thing I thought about sharding is that it lets you also store only a subset of the state.?
Piers Ridyard: That is correct. There is always a trade off between node churn and storage.
Q10: Would it actually be possible to get the philosophy behind the fee structure/mechanisms (burn on-tx)
Piers Ridyard: It’s much simpler to burn fees in a highly sharded environment, plus it helps balance against the network emissions from proof of stake
Q11: What is the team’s position on the role of different clients? Any time scale when it would be possible/optimal for these to enter the game?
Piers Ridyard: Yea, post Babylon would probably the best time frame for this. At least post Radix Engine v2 integrations
Q12: Most of the projects were driven by wrong intentions, which resulted in scams and rug-pulls. In this case What Radix can offer to investors? How can we sure that there is no chance of rug pulled/exit scam?
Blind5ight: I’m a Radix community mod and have followed the project since October 2017 (I can provide proof via my Reddit account 😁)
I want to say that over the years, I have noticed that this team is looking to solve problems firstly
That is their main objective
Solving tough problems takes time, proof of that is that there are still problems in crypto that are not solved yet
Radix focused fully on solving problems with the design of their technology first
And only after reaching a complete solution -> transition to rolling it out
The shared price vesting of token unlocks is proof that the long term outlook is adopted by the team
Both early community and team are under the same price vesting terms that promote long term value generation
Q13: How confident are we on Cassandra being linearly scaleable and very very fast?
Piers Ridyard: Cassandra is our research project. I am confident that Xi’an will be — how much of Cassandra we integrate or not will depend how the testing over the next few months go.
Q14: About the validator set selection in fully-sharded-Cerberus (Xi’an), based on your ramblings about interplanetary consensus fo Cassandra. Will mutual latency be a factor in selecting validator sets? It seems to me that if done properly the finality times for transactions that are purely international will be smaller than those that require inter-continental consensus; each type of transaction not interfering with the other. Is this on your radar for when transactions are no longeer blocked as in Olympia?
Piers Ridyard: Ramblings 😆😆😆. Best to ask Dan in the next Radix AMA in our telegram channel next Tuesday
Q15: Explain a little to us simply for those of us who want to learn technical knowledge about programming or cryptography how “Radix” is a large-scale solution size through its components for ETH and product development like dApps..??
Blind5ight: Technology is tough to understand sometimes, especially for people that aren’t super tech savvy
Crypto adds a lot of complexity in there: economics, governance, …
Cerberus, the Radix solution that enables the unlimited scaling whilst preserving full atomic composability
has been explained in easier to understand terms via a recently released infographic series
Kindly check it out :)
https://www.radixdlt.com/post/cerberus-infographic-series-chapter-i
Q16: Could other L1s that break Cerberus atomicity due to their scaling solution get atomicity back by applying the Cerberus consensus concept?
Piers Ridyard: You would need to also integrate the Radix Engine v2. It would be a pretty major change. Everything is possible given enough time, but no one will be copying us any time soon!
Q17: Would a dapp that is compiled to run in its own private universe be able to be composed together with other dapps running in their own private universes?
Piers Ridyard: Not atomically. Would require a cross ledger bridge to work properly.
Q18: Can you give us some information about Radix’s mobile applications are there any ios version and android version?
Blind5ight: “In later versions of the network when we implement our unique smart contract capability, we will be reconsidering the entire wallet experience and mobile will definitely be on our minds then. For Olympia, the focus is on a secure, usable desktop wallet experience to hold and stake XRD.”
Source: https://t.me/radix_dlt/202386
Above is a citation from the Radix Head of Product, Matt
The team tries to frequently visit the Radix telegram to interact with the community to address pressing questions
Please join the Radix telegram to interact with community and team :)
Q19: Is it actually true that we only need 100 validators to service all these private universes and the public network, or does each private universe need its own set of validators?
Piers Ridyard: Depends on how it is configured. We are concentrated on the public Radix network, not really private universes. Those are up to the companies who create them and what they configure
Q20: Is it possible to store data onto the ledger in such a way an Non-Fungible Asset is created? Same as a NFT but the binary data stored on the blockchain. And with possible, I of course mean practically so that doesn’t disturb the functionality of the ledger.
Piers Ridyard: Yea, sure.
Q21: What’s the difference between collecting tx fees across shards and collecting dev royalties? Is it easier to collect dev royalties?
Piers Ridyard: Good question. A dev royalty goes to a one or a small number of addresses. A transaction fee needs to be aggregated across huge numbers of shards and then distributed across many nodes in equal share. It’s basically the difference between dealing with the throughput of a few multi-Sig wallets and dealing with a multi-Sig involving every single balance and every single node on the network!!
Q22: On the Olympia, during the first dozen epochs, I want to remove delegated stake from node runners who did not become validators and move it to ones who did. Will the delegation software allow me to withdraw and redeposit stake without any delays that might be there for security reasons?
Piers Ridyard: No, for the first version of the network you have to unstake then re-stake. We are looking at bringing this functionality in the future, but not for Olympia
Q23: As I see you left and started a lot of job as your background wise. So, in future is there any chance where you left Radix and start a new project?
Piers Ridyard: I’m in this for the long haul. This is the start of a revolution that is going to be decades in unfolding!
Q24: Can you list 1–3 killer features of Your Project that makes it ahead of its competitors ? What is the competitive advantage your platform has that you feel most confident about???
Blind5ight: A layer 1 DLT solution stack is comprised of a couple of layers: network (consensus), application, data, …
+ the incentives
Radix is bringing innovations on all of the layers
Innovations that are needed to enable DeFi on a global scale
DeFi is thriving because of the ability to click money legos seamlessly together to create new, complex financial products relatively easily
This is possible by a feature called atomic composability
The other projects can not scale this feature
They create more and more islands that have atomic composability contained within them but not across multiple islands
So atomic composability is limited to the island and thus it is reduced
Cerberus has been designed to scale that feature as well, since it is a layer 1 DeFi done right, you need this feature 😉
=> Clean scaling is big!
Other improvements are in the application layer: Radix Engine v2 / Scrypto -> much more secure DeFi protocols
A prerequisite to even be worthy of scaling something
And also as mentioned Radix has developer incentives for every developer not just the developers that deliver end user aplications
Thanks for having us, feel invited to the Radix community: https://t.me/radix_dlt
- End -
