Skip to content

About

No description, website, or topics provided.

Resources

Stars

7 stars

Watchers

0 watching

Forks

Repository files navigation

MagicBlock Engine

Solana execution and state management for ephemeral rollups.

License Apache-2.0 Rust 1.96.1 Edition 2024 Solana SVM Status experimental Version 0.14.2

✨ API tour · 🧩 Workspace · 🔬 Runtime internals


Engine is the execution core behind MagicBlock Validator (MBV). It runs Solana transactions over account state in an ephemeral rollup (ER), bringing together the SVM, parallel scheduling, persistent storage, live events, and replication.

MBV takes care of base-chain integration and commit policy; Engine handles local execution and state. Its blocks mark execution boundaries, not consensus or confirmation. This repo is where those execution and storage pieces come together.

✨ Engine in practice

A few API examples give a feel for what Engine handles. Configuration and the finer contracts live in the linked crate READMEs.

🚀 Start execution with recovery built in

With storage, authority, and initial state configured in a KeeperBuilder, one handle starts the stores, recovery, execution workers, and block pacing:

use engine::Engine;
use nucleus::shutdown::ShutdownManager;

let mut shutdown = ShutdownManager::default();
let engine = Engine::new(builder, None, &mut shutdown).await?;

Engine can generate its own block boundaries or follow an external pacer. Startup and orchestration →

⚡ Execute in parallel, or simulate first

Independent transactions run concurrently; conflicting account accesses keep their input order. Preview a transaction, then execute it against local state:

let simulation = engine.transaction(transaction.clone())?.simulate(true).await?;
let result = engine.transaction(transaction)?.execute().await?;
Mode Completion boundary
simulate(sigverify) Execution on account copies, without committing; verifies transaction signatures when requested.
execute Admission rejection or the committed execution result.
schedule Queueing acknowledgment, without waiting for admission or execution.

For queue-only submission, use engine.transaction(transaction)?.schedule().await?. Execution and simulation results can contain transaction-level failures even when the Engine call succeeds. Cancelling a wait doesn't cancel submitted execution. Transaction semantics →

📦 Import accounts atomically

Delegated and ER-created state is persisted; rebuildable external-chain mirrors stay in memory. Account imports can include follow-up instructions in the same transaction, so activation and the work that depends on it succeed or fail together:

engine.account(key).await?.materialize(account, actions).await?;

MBV validates the external state; Engine enforces lifecycle and slot rules. Materialization can also skip an already handled or superseded image. Account lifecycle and imports →

📡 Follow live changes

Subscribe to account changes, transaction results, logs, and blocks. Retained history supports queries and replay alongside those live streams:

let mut account_updates = engine.accounts().subscribe(key);
let mut blocks = engine.blocks().subscribe();

let update = account_updates.recv().await;
let block = blocks.recv().await;

Account and block subscribers have bounded queues; slow receivers are disconnected. Other streams have their own delivery contracts. Subscriptions → · History →

🔁 Replay execution on a follower

A source serves ordered history over TCP. Followers authenticate it, re-execute transactions locally, and check history and persisted-state boundaries:

Source:   allow follower identities → serve retained history
Follower: trust source authority → replay transactions and block boundaries

Followers resume from a synchronized position while history is retained. Otherwise, snapshot transfer stages state for a host-managed restart. This is execution replication, not consensus between peers. Replication →

🩹 Drain cleanly and recover on restart

Coordinated shutdown drains work and synchronizes storage. Keep Engine and the async runtime alive while services finish:

let reason = shutdown.wait().await;
// Stop accepting new requests.
let reason = reason.combine(shutdown.terminate().await);

On restart, Engine validates stored state and, when needed, restores a retained snapshot and replays history before accepting new work. Recovery depends on retained state; it doesn't guarantee complete queryable crash-tail history, and execution completion alone isn't a disk-sync guarantee. Recovery → · Durability →

🔬 The runtime underneath

Engine uses local forks of Agave's runtime to support its account lifecycle and borrowed storage. Account data is mapped directly into the SBF VM, while storage and commit decisions stay outside the SVM. These adaptations let execution work with Engine's state model without importing validator machinery.

The runtime overview covers the fork boundaries, direct mapping, and compatibility constraints.

🧩 Workspace layout

Start with the Engine README for the architecture, or pick a crate below. Each README explains its role, design constraints, and source entry points. Validator setup and surrounding services live in MBV.

Crate Responsibility
engine Service orchestration, transaction ingress, account imports, and recovery.
processor Dependency scheduling, SVM execution, simulation, and execution barriers.
keeper Coordination of storage, caches, subscriptions, and runtime configuration.
accountsdb Current account state, persisted and volatile storage, snapshots, and checksums.
ledger Execution history, indexing, replay, durability, and retention.
replicator Authenticated source/follower streams and snapshot bootstrap.
nucleus Shared configuration, runtime and record types, metrics, and service lifecycle.
solana/* Runtime forks for Engine's account model and VM mapping.
programs/* The privileged MagicRoot builtin and v42 SBF test fixture.

About

No description, website, or topics provided.

Resources

Stars

7 stars

Watchers

0 watching

Forks

Releases

Packages

Contributors

Languages