Lib.rs

› Cryptography › Magic Beans
#execution-engine #radix #smart-contracts #ownership #reference #applications #layer

no-std radix-engine

Reference implementation of Radix Engine, from the Radix DLT project

by Yulong Wu, Joshua Primero, lrubasze, 0xOmarA, David Edey and 33 contributors. Owned by radixbot.

2 releases (1 stable)

1.2.0 May 17, 2024
1.2.0-dev Mar 20, 2024

#35 in #execution-engine

Download history 109/week @ 2024-07-22 60/week @ 2024-07-29 132/week @ 2024-08-05 201/week @ 2024-08-12 231/week @ 2024-08-19 263/week @ 2024-08-26 268/week @ 2024-09-02 284/week @ 2024-09-09 253/week @ 2024-09-16 181/week @ 2024-09-23 80/week @ 2024-09-30 23/week @ 2024-10-07 75/week @ 2024-10-14 81/week @ 2024-10-21 134/week @ 2024-10-28 106/week @ 2024-11-04

397 downloads per month
Used in 5 crates

Custom license

5.5MB
119K SLoC

Radix Engine

Radix Engine is the underlying execution engine designed to run DeFi-based Scrypto applications.

The architecture is heavily influenced by traditional Kernel design (though much simplified) and Rust's Ownership and Type-Checking paradigms (also much simplified). The novel idea here is in combining ideas from the two worlds, Operating System and Language, or simply "Implement Rust Semantics at the System Layer".

Architecture

Radix Engine execution is organized into 5 layers, each layer providing an API to the layer above.

Execution layers may also optionally provide a Callback API which the layer above must implement.

Execution Layer Layer ID Description Responsibilities API Callback API Implementation
Application 5 "User Space" Application Logic (e.g. Blueprints written in Scrypto) Native Blueprints
Scrypto Blueprints
VM 4 "Virtual CPU" Application Execution WASM + Scrypto API VM
System 3 "Operating System" Type Checking
Package/Blueprint/Object semantics
Application Standardization (e.g. Authorization, Versioning)		 Substate API
Object API
Blueprint API
Costing API		 System Callback API System
Kernel 2 "I/O Device Management" Call Frame Message Passing
Ownership/Reference handling
State Virtualization Mechanism
Substate Device Management
Transaction Execution		 Kernel API Kernel Callback API Kernel
Database 1 "Persistence" Runtime Read-Only Physical Storage Substate Database InMemoryDB
RocksDB

Data Abstraction

If looked at from a purely state perspective, the layers can be reduced to the following 4 layers:

Data Layer Layer ID Abstraction
Application 5 Application Interface (e.g. Amount of money in my account)
System 3 Package/Blueprint/Object semantics
Blueprint Fields and Collections
Blueprint Typing
Kernel 2 Node/Partition/Substate semantics
Substate Ownership/References
Database 1 Key/Value Database

Dependencies

~27–57MB
~1M SLoC