Understanding Solana's Scalability Innovation: Ephemeral Rollups

Ephemeral Rollups, developed by Magic Block, is a scalability solution designed for high-concurrency applications like fully on-chain gaming, social networks, and trading. It addresses the limitation of blockchain consensus in handling massive transaction volumes—such as 1,000,000 TPS for 100,000 players—by temporarily moving high-frequency state updates (e.g., player positions, attacks) to a dedicated, fast environment.

Core Mechanism: High-frequency game data is "borrowed" into a temporary Rollup, offering 50ms latency and zero gas fees, while the main chain periodically syncs the latest state and handles rollbacks if needed.
Key Enablers:
- Program Derived Addresses (PDAs): Allow game programs to manage and modify game state accounts without user private keys.
- Account Modification Delegation: Temporarily delegates "modification rights" of game state (not asset ownership) to the Rollup.
- Sealevel Parallel Processing: Enables concurrent transaction handling.
User Experience: Players interact seamlessly via an RPC router that automatically routes operations between the Rollup (for speed) and the main chain (for security and asset transactions).

Solana Ecosystem Scalability Innovation: Ephemeral Rollups ????????

Ephemeral Rollups is a real-time state update engine developed by Magic Block, designed for high-concurrency scenarios such as full-chain gaming, social networking, and trading. It is currently primarily used in full-chain gaming engines.

Fully on-chain games require that every action be recorded on the chain, such as movement, attack, item consumption, etc.

The problem is that the consensus mechanism brings scalability limitations.

Assume 1,000 players are online simultaneously. Each player's position is updated every 100 milliseconds, resulting in 10,000 transactions per second. Scaling this to 100,000 players increases the transaction rate to 1,000,000 transactions per second. This is far beyond the capacity of any current consensus model.

Therefore, it is actually very difficult, or even impossible, to put the QQ Game Hall on the chain, not to mention games like "World of Warcraft" and "Fantasy Westward Journey" where a large number of players are online and each player has to perform multiple complex operations every second.

However, MagicBlock hopes to enable high-concurrency games to be put on the blockchain. Any participant can integrate or modify game content without permission, or create "Autonomous Worlds".

Game state and logic are stored on-chain and cannot be tampered with. Distributed servers ensure game resilience with no single point of failure.

Ephemeral Rollups provide a solution.

The core principle is to temporarily "borrow" the high-frequency game data into a dedicated high-speed environment - "temporary Rollup".

In a temporary environment, latency is as low as 50 milliseconds, just as fast as traditional game servers. It's completely free, with no gas fees. You can even edit passively triggered logic, like in-game plots.

The latest status will be synchronized and updated to the main chain regularly, and the main chain can view the data at any time. If there is a problem with the temporary environment, the data will be automatically rolled back and returned to the main chain.

The user is unaware of the entire process. The backend RPC router automatically determines which operations go through the fast channel (temporary Rollup) and which operations need to go through the main chain.

How to achieve it specifically?

Several concepts need to be introduced: Solana account structure, programmatically derived addresses (PDAs), and the account modification delegation mechanism (Account Modification Delegation).

1/ Solana’s Account Structure

The core concept of Solana is "everything is an account." Program code, user data, token balances, and other information are all stored in accounts.

Solana accounts are mainly divided into two categories (separation of code and data):

1) Executable Accounts = Program Accounts (Read-only)

Stores program code, similar to smart contracts on other blockchains.

2) Non-Executable Accounts = Data Accounts (Editable)

Accounts store data and state, but do not contain executable code.

It should be noted that this "account" is different from the user's wallet address.

If you check the browser, you will find that the Owner of the normal address is System Program, and the address is fixed at 1111111111111111111111111111111111 .

System Program is Solana's official built-in program.

So actually, when you create a Solana wallet, such as Phantom, the address you get is actually:

Account type: Non-executable account (data account)
Owner: System Program

In other words, wallet address = data account owned by the system program.

The wallet address is derived from the private key. The user has the corresponding private key and can sign transactions.

An account is a data structure stored on the chain, controlled by a program (owner), and the wallet address "points" to this account.

2/ Program Derived Addresses (PDAs)

The advanced features of Solana's account system are very important for gaming.

PDA is a special account address, which is essentially an ordinary Solana account, but its address is generated in a special way. It is derived by the program and can only be controlled by the program that created it. It has no private key (not controlled by the user).

Therefore, for games on the entire chain, only the game program can modify this PDA, and other programs can only read it.

Thus, the PDA can accomplish:

1) Easily create a large number of game status accounts

2) Ownership is transferable (delegation mechanism)

3) Addresses are predictable (routing is easier)

4) Program control (user authorization through program)

For temporary Rollups, you can complete:

1) Manage a large number of game status accounts

2) Support frequent delegation and cancellation of delegation

3) Find the account with certainty

4) Implement program control (not direct user control)

Then we also need 3/ Account Modification Delegation

This is the key innovation of ephemeral rollups:

Normal situation: An account can only be modified by its owner program;

Delegation mechanism: The account's modification permissions can be temporarily "lent" to another environment (temporary Rollup).

It should be noted that delegation does not equal transfer of asset ownership. What is delegated is the "right to modify the game state", not the "asset itself".

Plus, 4/Sealevel parallel processing

Sealevel identifies non-conflicting transactions and processes them concurrently.

So, in the specific game,

Suppose player Alice uses a Solana address starting with 3vj to play World of Warcraft on the entire chain. She needs to frequently update her location, combat, consumed items, etc., and there are more than 10,000 players online at the same time.

at this time,

1/ Game startup: The game program calculates Alice PDA derived address

2/ User authorization: Alice authorizes the game status account

3/ ER Start: The node detects the delegation request and starts Ephemeral Rollups (hereinafter referred to as ER)

4/ State Synchronization: Synchronize Alice’s game data from Solana L1 to ER

5/ Game progress: Players operate in the game, and ER performs tasks

6/ Cross-layer reading: If you need to read NFT and other information, ER can read it directly from Solana L1, but has no right to modify it.

7/ Regular synchronization: ER data is regularly uploaded to L1

8. Asset Operations: If game items or game coins are to be cashed out, ER authorization must be revoked. This is performed on Solana L1 and must be done in advance by the player. Token transfers are secured by the Token Program. The game vault is a PDA, controlled only by the game program. The owners of these two are different.

This actually completes the operations of using game currency to buy and sell point cards in "Fantasy Westward Journey" and "World of Warcraft", and cashing out gold-farming groups.

9/ Game over: Players log off and ER is closed.