Transaction Execution & Radix Engine

Learning Objectives

• Understand the transaction lifecycle in hyperscale-rs
• Learn how the Radix Engine fits in (relative to hyperscale-rs)
• Understand state management and validation
• See where execution sits in the Transaction Flow

Where Execution Fits

In the Transaction Flow, execution happens after a block is committed by BFT. The node has an ordered sequence of transactions (in committed blocks); the execution layer applies each transaction to the current state and produces state updates. For cross-shard transactions, execution is coordinated with the provisions and 2PC steps (see Cross-Shard Transactions in Hyperscale-rs).

Hyperscale-rs vs Radix Engine (relative roles)

Hyperscale-rs is the consensus and coordination layer: it orders transactions (via BFT), handles cross-shard 2PC and provisions, and drives when execution runs. It does not interpret the content of Radix manifests or execute Radix Engine instructions itself.

Radix Engine (external to this repo) is the execution engine: it takes a transaction (e.g. a Radix manifest), interprets instructions (CallMethod, TakeFromWorktop, etc.), and applies state changes to a Radix-style world state (components, resources, vaults). Hyperscale-rs typically receives a transaction that has already been built for the engine (e.g. a UserTransaction or similar); it may analyze it (e.g. extract declared_reads / declared_writes for shard routing) and then order and coordinate it; the actual execution of the manifest is done by the engine, often in a separate process or library that hyperscale-rs calls.

Paths: From the course repo, hyperscale-rs content lives under hyperscale-rs/; Radix Engine is a separate project (e.g. radix-engine or the Radix node). So when we say “execution” in hyperscale-rs we mean: (1) the execution crate that manages lifecycle, 2PC, and calling out to the engine, and (2) the engine (external) that does the actual state transitions.

Transaction Lifecycle in the execution Crate

In crates/execution you’ll find logic for:

• Receiving committed blocks – Events or actions from BFT indicate a block is committed; execution takes the transactions in that block and runs them (or hands them to the engine).
• Single-shard execution – For transactions that touch only one shard, execution is straightforward: apply in order, update state.
• Cross-shard execution – Start cross-shard flow (e.g. start_cross_shard_execution), wait for provisions from other shards, participate in 2PC (prepare → commit/abort), then apply state updates in agreed order. Refs: crates/execution/src/state.rs, provisions crate.

State Management

State is usually held in a structure that the engine understands (e.g. a JMT or key-value store). Hyperscale-rs may maintain a view of state (e.g. for validation or for building blocks), while the canonical execution and state update are done by the engine. Snapshots and persistence are often in a separate storage layer (see the Storage module later).

Validation

Before a transaction is proposed or executed, it is validated: structure, signatures, and (depending on design) static analysis (e.g. shard membership from declared_reads / declared_writes). Validation may happen at the mempool, at proposal time, and again at execution time to ensure the committed block is applied correctly.