The exponential growth of defi has exploded over the past year, and today nearly $25 billion of TVL (Total Value Locked) can be found in open finance protocols. With this much literally at stake, defi projects are charged with being able to run smart contracts autonomously, trustlessly, and irreversibly, and without any software exploits. Unfortunately, this promise remains unfulfilled until now.
2020 was filled with defi rug pulls (software exploits left by protocol devs and founders used to drain funds), hacks, and software bugs found in project code, leading to some catastrophic exploits and system failures resulting in $120 million being stolen from defi alone.
With smart contract exploits still hampering the defi space, and as more people become interested in investing their cryptocurrencies into open finance protocols, smart contract development needs a way of fixing these issues before defi can think about going mainstream.
And answering that call is Radix, is the first layer 1 protocol attempting to create safer smart contracts immune to hacks and exploits.
The Radix Engine Solution
Radix’s approach is different from Ethereum-style smart contracts, in that it is essentially a server-in-a-box solution deployed over the network. These smart contracts work alongside other dApps to call up functions by sending signed messages to the smart contract, and using their own internal variables to update and receive the methods.
While Ethereum maintains a robust system of smart contracts, developers in the defi space face one critical issue: the burden of writing code to ensure the true representation of tokens or other variables remains always correct and true.
Also of integral importance is that the code can update the internal variables in the smart contract to produce a desired combined result, which has proven difficult for Solidity-based coding today.
This mission becomes even messier for devs when multiple updates/variables are introduced when a transaction involves multiple Composed smart contracts. Such exploits can often lead to hacks and bugs in the code.
To fix this issue, Radix uses a development environment tailored for logic creation and the ability to define and execute predictable/correct results on the mainnet of Ethereum, every time. Radix uses Finite State Machines (FSMs), or finite state machine logic that defines their behavior by translating an existing (before) input state to output (after) state.
Software developers who build these often use specialized development environments in order to avoid any issues or unwanted results. Radix uses FSMs and Components to create these smart contracts. Components are modeled after the centralized finance world, which are commonly found in mission-critical embedded systems where predictably is the most important function.
Radix Components
Actions, or multiple variables coded into Solidity-based Ethereum smart contracts, are attack vectors for hackers, even where a simple transaction uses multiple composed smart contracts to achieve its end goal. In doing so, it leaves potential for exploits and bugs in the code, e.g. liquidity pools accepting an existing ERC20 token and minting corresponding, but separate tokens accurately.
Radix fixes potential vulnerabilities by defining what is possible via Components in a different way than Solidity does. Components are created using a specialized language coined Scrypto, a functional language that is more common when building high-concurrency systems in FSMs.
There are two advantages to using Radix Components. First, these variables (Components) act intuitively like physical assets or other financial primitives rather than typical smart contracts. Using Components in Actions makes smart contracts easier to design, reason and analyze better than current smart contract solutions.
Second, coding with Radix Components becomes even more intuitive and predictable, giving creators the ability to develop their own sets of definitions for transactions with a safety net laid by previous Components, which already dictate what can and cannot happen within the smart contract.
Why Radix Matters in Defi
Ethereum’s layer 1 protocol has moved from the ICO craze of the 2017-18 bull market to a more traditional decentralized finance system that is antithetical to the traditional banks and closed-system financial instruments.
Exploits in code, especially in Ethereum-based layer 1 protocols, are the result of hackers finding exploits in the system, often coming in the form of changing smart contract code that affects its internal state.
Radix believes it can create a more secure system of smart contracts via its Component model, making defi software development act more like the traditional banking system, which has been streamlined to work efficiently among closed/centralized platform-to-platform operations for decades.
Radix’s goal is for its network and Component model to become a purpose-built solution for defi. Whether that promise is fulfilled will be determined by whether the market deems there to be better security through the Radix Engine. One thing’s for sure: as the number of exploits executed on Ethereum rises, the case for hacker-proof smart contracts grows stronger.
Discuss this news on our Telegram Community. Subscribe to us on Google news and do follow us on Twitter @Blockmanity
Did you like the news you just read? Please leave a feedback to help us serve you better
Disclaimer: Blockmanity is a news portal and does not provide any financial advice. Blockmanity's role is to inform the cryptocurrency and blockchain community about what's going on in this space. Please do your own due diligence before making any investment. Blockmanity won't be responsible for any loss of funds.
