Mantis is excited to share that we will soon be incorporating ephemeral rollups by MagicBlock. Ephemeral rollups are a scaling solution that harnesses the Solana Virtual Machine (SVM). Ephemeral Rollups (ERs) enable sharded and asynchronous execution of a base Solana Virtual Machine (SVM) layer, without creating permanent state fragmentation. Thus, Mantis will become even more performant and scalable while keeping transactions on-chain.

MagicBlock is a high-performance engine for onchain games and applications. Their end-to-end, open-source stack allows developers to create fast, composable, and elastic products on any platform.

While MagicBlock offers a number of products, Mantis will specifically be leveraging their ephemeral rollups (ERs). ERs are a configurable dedicated runtime and auxiliary layer on the SVM. Users can lock accounts to temporarily transfer state to the ER. The system uses an assert/challenge construction where the ER node operator processes transactions optimistically. These transactions are then subject to validation through a fraud-proof mechanism. If the constraints are not satisfied, the state is reverted and unlocked on the L1.

The distinguishing advantage of ERs over other rollups is that programs and assets reside directly on the base layer (ie. Solana). Transactions sent through ERs are both accelerated and fully compatible with the Solana Virtual Machine (SVM) down to the bytecode level.

Benefits of ephemeral rollups include:

• Base Layer Deployment: Unlike other rollups, ephemeral rollups enable program deployment on the L1 (Solana). From here, programs are able to interact with existing protocols and assets. Thus, fragmentation is avoided.

• Use of Solana’s Infrastructure: Developers building with ephemeral rollups can leverage the existing Solana infrastructure and tooling. There is no need to learn or create a new framework.

• Customization: Ephemeral rollups have a specialized runtime allowing for customizations.

• High Scalability: Ephemeral rollups enable the scalability of L2s without the typically intense development burden.

The steps involved in using ephemeral rollups are as follows:

1. A program defining the instructions and executable logic communicates with the delegation program. This initiates a transaction requesting an ER provision. The transaction also specifies any details about the ER’s configurations.

2. The provisioner monitors the delegation program and detects the provisioning request. The provisioner then launches the corresponding runtime based on the configuration.

3. The program delegates accounts to the delegation program, enabling it to update state and perform settlement. From here on, delegated accounts are only updated within the ER.

4. Clients executing transactions or retrieving data can send transactions to an RPC router. The router forwards transactions to the specified chain.

5. Upon ER termination, the sequencer updates the state on the base layer.

6. Once the ER concludes, account control reverts to the owner program and the provisioner terminates the ER.

This process is shown below:

As a result, state can be managed across multiple accounts. This facilitates scalability while programs are still directly deployed on an L1 instead of a separate L2.

For further details on ephemeral rollups, reference MagicBlock’s ephemeral rollups Whitepaper or documentation.