.svg)
TLDR: Solidity development often involves manual copy+pasting code from other contracts, which can lead to errors & vulnerabilities.
Radix Blueprints and Components will provide on-ledger, automated, and safe mechanisms to reuse (and automatically reward) other developers’ work.
On May 7 2021, Value DeFi, an Automated Market Maker (AMM) on Binance Smart Chain (BSC), was exploited for $11m.
When developing the AMM, the Value DeFi developer copied a snippet of Solidity code from Bancor (an AMM project on Ethereum) that helps calculate exchange rates between the tokens in the pool.
This practice of copying and pasting code is incredibly common on networks that use Solidity and the EVM, because there is no alternative - it’s the only way.
But copying and pasting code brings problems. Any differences elsewhere in the original contract (Bancor) and the new contract (Value DeFi) could introduce a vulnerability, which in this case was exploited for $11m.
In Radix, we have a radically different model for smart contracts (going live in our upcoming Babylon release). In fact, we don’t even call them smart contracts, they’re called “Blueprints” and “Components”.
A blueprint is a template written in Scrypto deployed on-ledger. It defines programmatic logic that can potentially be reused, e.g. how a liquidity pool should work. It can also include parameters, e.g. which token vaults are accepted, or who has permission to “instantiate” a component from the blueprint. Blueprints do not hold any “state”, such as vaults of tokens or other data, as they are templates for functionality, not the functionality in action.
A component is instantiated from the blueprint template (made into a live instance). When doing so, the instantiator can choose options as defined by the blueprint. Components do hold state.
You can think of a blueprint as like a model of a car (a template), and a component as one of the cars actually on the road (an instance). At point of manufacture (instantiation), the car can be customized with options such as color, engine or seating arrangements.
In this way, a DEX dApp on Radix could be created using a blueprint that defines how a liquidity pool should work. Each liquidity pool component instantiated from that blueprint could represent a different pool of tokens, e.g. USDC:Dai; wETH:wBTC, etc.
So now back to the exploit. If “Bancor” and “Value DeFi” were on Radix, the Value DeFi developer would not copy and paste a snippet of code from the “Bancor” smart contract, potentially with errors.
Instead, they could browse through Radix’s “Blueprint Catalog”, select a blueprint with proven functionality that suits their needs, and instantiate their own complete liquidity pool from that pre-existing blueprint!
Customizing the options for a component would be performed by specifying parameters to the blueprint at instantiation. Such parameters could include the “bonding curve” function for the pool, or the types of assets accepted.
And with Radix’s Developer Royalties system, the developer of the “Bancor” blueprint could specify an on-ledger royalty payment that’s automatically paid every time anyone uses the “Value DeFi” component, on a per transaction basis.
This is vastly different from the “monolithic” contracts on EVM networks, where all functionality is jammed together in the same smart contract, resulting in other developers having to manually copy+paste the relevant code snippets for functionality they like, and redeploying this same functionality again and again. This is not only massively redundant, but results in errors, vulnerabilities and exploits if developers don’t fully regression test the code they copy (testing the effect of a code change on other code).
If you’d like to learn more about how this is a game changer for DeFi, I recommend you read our four-part blog series starting here: https://www.radixdlt.com/post/the-problem-with-smart-contracts-today
For the last in the Rekt Retweet series: Rekt Retweet #6: Re-entrancy and Flash Loans - Why the $80m Fei / $Rari hack could NEVER happen on #Radix.