JIT Cloning: How Ephemeral Rollups Handle State Delegation

Welcome to Magic Tech Series, a a 6-part series of articles where we dig deeper into each key innovations that make MagicBlock possible. This first article explains how JIT State Cloning works at a technical level, covering the delegation lifecycle, the cloning mechanism, and the state commitment process.

‍Leveraging Solana's Account Model

JIT State Cloning is possible because of Solana's account-based architecture.

In Solana, all state lives in accounts. Programs are stateless, they read from and write to accounts passed into each transaction. This separation between logic and state is one of the key affordances that enables granular state cloning: you can delegate specific accounts to a faster execution environment while leaving the program itself (and all other accounts) on the base layer.

With this mechanism, individual accounts or clusters of accounts can be locked and temporarily delegated to an Ephemeral Rollup for accelerated execution. The program bytecode remains on Solana. Only the state accounts move.

The Delegation Lifecycle

JIT State Cloning operates through five phases: delegation, cloning, execution, commitment, and undelegation.

Phase 1: Delegation

When a program needs to accelerate specific state accounts, it delegates them to an Ephemeral Rollup validator via the Delegation Program (DELeGGvXpWV2fqJUhqcF5ZSYMS4JTLjteaAMARRSaeSh).

The delegation instruction specifies the following parameters:

• Target ER Validator: Which Ephemeral Rollup instance will process  real-time, zero-fee state transitions. MagicBlock operates validators across multiple geographies (eg Asia, Europe, US).
• Auto Synchronization: How often the ER should commit state back to Solana,  periodically and automatically.

Upon delegation, the account's owner changes to the Delegation Program. This prevents write operations on Solana while the account is delegated, ensuring consistency. However, the account remains readable on the base layer, so other programs can still access the delegated state for read operations.

Phase 2: Just-In-Time Cloning

Once delegated, the key optimization is that the Ephemeral Validator clones accounts from the base layer only when first accessed. The initial transaction touching a delegated account triggers a clone operation that fetches the current state from Solana and replicates it in the ER's local state. Program accounts are never delegated. Only state accounts can be delegated, but program accounts are conveniently cloned when a transaction is submitted to the ER and subscribed for updates thereafter.

This approach ensures:

• Fresh state on access: When an account is cloned, it reflects the latest committed state on Solana
• Minimal startup latency: Sessions begin immediately without waiting for a bulk state transfer

Phase 3: Execution

Once accounts are cloned into the ER, transactions execute at significantly lower latency than the base layer. The Ephemeral Rollup operates on an FCFS (First Come First Served) basis with an execution between 3-5ms, and an end-to-end latency under 50ms. 

This performance comes from:

• No consensus overhead: The ER is a non-voting validator that doesn't participate in Solana's consensus
• Single-sequencer execution: One validator controls the delegated state during a session, eliminating coordination overhead
• Geographic colocation: ERs are provisioned close to users, minimizing network round-trip time

As mentioned, during execution, delegated accounts are writable only in the ER. The base layer can read them but not modify them. Non-delegated accounts remain fully accessible and modifiable on Solana.

Phase 4: Commitment

The ER operator commits state changes back to Solana periodically or on demand.

The commitment includes the updated account state. State diffs are finalized through a dynamic fraud-proof mechanism. A decentralized Security Committee monitors commitments. If the node operator posts a commitment that cannot be derived from the canonical inputs + deterministic execution rules, any honest party can raise a challenge during a configurable fraud-proof window. In the happy path, the state diff finalizes, otherwise the challenged state finalization will be halted, and the malicious node will be slashed.

A key innovation for commits is Magic Actions, bundles of instructions that run automatically on the Solana immediately after a commit. We’ll dig deeper into Magic Actions in an upcoming blog post.

Phase 5: Undelegation

When a session ends, the program calls an undelegation instruction:

This:

1. Commits the final state to Solana
2. Reverses account ownership from the Delegation Program back to the original owner
3. Makes accounts fully writable on Solana again

After undelegation, accounts return to normal Solana operation.

‍State Consistency Guarantees

JIT State Cloning maintains several consistency properties:

Read Availability on Solana

Delegated accounts remain readable on the base layer throughout the delegation lifecycle. Other programs can access their state for read operations. This allows a protocol to read delegated state as it's committed without waiting for undelegation.

Write Lock

During delegation, writes are isolated to the ER. The Delegation Program ownership prevents modifications of the accounts on Solana, ensuring the ER has exclusive write access. This eliminates race conditions and inconsistent state across layers. 

Commit Atomicity

State commits from the ER to Solana are atomic. Either all account updates in a commitment succeed, or none do. Partial commits don't occur.

Clone Freshness

JIT cloning fetches the latest committed state at cloning time. If an account was previously delegated, undelegated, modified on Solana, and re-delegated, the new clone reflects all changes.

‍Summary

JIT State Cloning enables Ephemeral Rollups to accelerate specific accounts without redeploying programs and state to another chain. 

The mechanism:

1. Delegates specific accounts via the Delegation Program, locking their write operations on Solana
2. Clones accounts on first access, fetching fresh state from Solana
3. Executes state updates at 3-5ms in the ER
4. Commits state back to Solana periodically or on demand
5. Undelegates accounts, returning full ownership to the original program

‍Implementation resources:

• Delegation, Commitment & Undelegation — full lifecycle documentation
• Ephemeral Validator — open-source SVM runtime
• Ephemeral Rollups SDK — integration utilities

‍