The Radix Engine [ /ˈrædɪks ˈɛnʤɪn/ ] is a protocol-level runtime environment and application layer, analogous to the Ethereum Virtual Machine (EVM). The Radix Engine utilizes finite state machines to define permitted asset states, improving the developer experience for building decentralized applications (dApps) by removing asset logic to the protocol layer.
- Overview
- Game Engine Analogy
- Properties
- Development History
- Disadvantages of the Ethereum Virtual Machine (EVM)
- Further Reading
DEVELOPMENT | |
Initial Release | |
Latest Release | |
Code Repository | |
License |
Overview
The Radix Engine is the core protocol component that executes transactions and maintains ledger state in the Radix network. It is responsible for sharding the ledger and processing transactions in a scalable, secure way. Some key aspects of the Radix Engine:
- Implements a UTXO model customized for scalability and performance.
- Breaks ledger state into substates that can be sharded across nodes.
- Groups components and their owned resources into single substates for efficiency.
- Uses a ceramic sharding model that can scale to an unlimited number of shards.
- Executes single-shard transactions via consensus within each shard.
- Processes multi-shard transactions via cross-shard coordination.
- Supports transactions that specify intent rather than direct substate inputs/outputs.
- Resolves conflicts from concurrent transactions by aborting one transaction.
- Verifies validity of transactions via owner signatures rather than script conditions.
- Provides inherent atomicity and isolation via the construction/destruction mechanism.
The Radix Engine is able to process transactions in parallel across shards while maintaining a globally consistent ledger state. Concurrency is maximized by specifying intent and resolving conflicts with selective transaction abortion.
Cross-shard coordination for multi-shard transactions is minimized based on the sharding model and construction/destruction mechanism. The Radix Engine architecture enables the linear scalability needed to support global finance applications with high transaction throughput.
The Radix Engine is one of the few application layers compatible with the Cerberus consensus protocol.
Game Engine Analogy
The Radix Engine has been characterized as a game engine for DeFi in that it defines and enforces properties such as asset permanence, transfer logic, minting, burning and other properties as a physics engine simulates gravity, collisions, rotation and other physical properties for game assets.
“[Building a high quality game] would have been utterly impossible without the game engine because they would have spent 90 percent of their time trying to reimplement the physics. Building DeFi is now a question of “What's the what's the functionality you want?”, not “Well let's start by defining what we mean by an asset or what we mean by a transfer; what we mean by a atomic swap; or something like that. All of that is just given by the Radix Engine.” - Matthew Hine
Properties
Asset Management
The Radix Engine ensures that fungible and non-fungible assets are understood at the protocol level, rather than having to be implemented by developers as local smart contract applications. This means that tokens can be created by an API request without the need for a smart contract.
Error Handling
All illegal operations are automatically blocked.
Object Permanence
The Radix Engine enforces object permanence, such that a token that can only exist at one location and only be moved by agents with permission rights.
Development History
Radix Engine v1
V1 was released with Olympia and introduced the basic functionality of transferring $XRD between wallets and staking / unstaking to validator nodes.
Radix Engine v2
V2 was released on an early access basis with the Alexandria developer environment and is scheduled for a full release with Babylon. V2 enables developers to create blueprints and components for decentralized applications (dApps).
Disadvantages of the Ethereum Virtual Machine (EVM)
The Ethereum Virtual Machine (EVM) is a runtime environment that is used to execute smart contracts on the Ethereum blockchain. It is an important part of the Ethereum ecosystem, as it enables developers to create and deploy decentralized applications (dApps) that can interact with the Ethereum blockchain. However, the EVM has several disadvantages, including its complexity, its vulnerability to hacking, and its limitations in terms of scalability and performance.
One major disadvantage of the EVM is its complexity. The EVM is a stack-based virtual machine, which means that it uses a data structure called a stack to store and manipulate data. This can make the EVM difficult to understand and use for developers who are not familiar with stack-based virtual machines. In addition, the EVM has a unique programming language called Solidity, which is used to write smart contracts for the Ethereum blockchain. Solidity is a relatively new and specialized language, which can make it difficult for developers to learn and use.
Another disadvantage of the EVM is its vulnerability to hacking. The EVM is a decentralized and open platform, which means that anyone can access it and create smart contracts. However, this also means that the EVM is vulnerable to malicious actors who can create and deploy smart contracts that contain vulnerabilities or exploits. For example, in 2016, a hacker was able to exploit a vulnerability in the EVM to steal millions of dollars worth of Ethereum from the DAO, a decentralized autonomous organization that was built on the Ethereum blockchain.
Finally, the EVM has limitations in terms of scalability and performance. The EVM is designed to execute smart contracts in a decentralized and trustless manner, which means that it must verify and execute every transaction on the Ethereum blockchain. This can lead to slow transaction times and high transaction fees, which can make it difficult for the EVM to handle a large number of transactions or to support high-volume dApps.
In conclusion, the Ethereum Virtual Machine has several disadvantages, including its complexity, its vulnerability to hacking, and its limitations in terms of scalability and performance. These disadvantages highlight the need for continued development and improvement of the EVM, in order to make it more user-friendly, secure, and scalable.
Further Reading