Why and How to decouple SVM execution layer for an Optimistic Rollup

8 min readSep 3, 2024

Co-Authored by Andrew Zhou (@0xandrewz) & Mingzhi Yan (@realraindust)

Introduction

The popularity of modular blockchains has led to a diversity of L2 blockchain components, with the use of SVM as an execution layer gaining significant attention. The SVM account model separates computation logic and state, which is highly beneficial for parallel execution. This gives SVM great potential to become a high-performance execution layer. Currently, there are some projects that have proposed their own technical architectures for this, but these solutions are mostly high-level designs, as they do not mention how to specifically derive L2 blocks from L1, nor how the sequencer integrates the derivation pipeline with the SVM executor. Regarding fraud proofs, these proposals focus on how to challenge the computational correctness of the SVM, but do not address the challenges of the derivation pipeline and force inclusion. This makes the sequencer able to conduct censorship attacks against the deposit transactions without being challenged.

To address the above issues, this article proposes a solution for an optimistic rollup with SVM as the execution layer. The derivation layer is based on the Optimism design, while the SVM execution layer is based on a new SVM API proposed by Anza. To integrate the derivation pipeline with the SVM executor, we have decoupled the Solana TPU (Transaction Processing Unit) flow, retaining only the SigVerifyStage, BankingStage, SVM executor, and Entry components, while removing the original Solana consensus layer. This enables a single fraud proof to challenge the correctness of both the derivation pipeline and the SVM execution, providing a secure guarantee for the complete state transition in L2. Furthermore, the decoupling has made the SVM execution layer more lightweight, and when combined with SIMD83, it becomes easier to achieve horizontal scaling of the Sequencer, thereby significantly increasing the transaction processing capacity.

Optimistic Rollup Overview

In this section, we will first discuss the basic technical architecture of an optimistic rollup. This article mainly uses Optimism’s design as an example, because the OP Stack is a widely used optimistic rollup technology stack with extensive documentation.

As shown in the above diagram, an optimistic rollup is composed of components such as op-node, op-geth, op-batcher, and op-proposer. Sequencer nodes (op-geth + op-node) gather proposed transactions from users. The op-batcher submits batch data to L1 which controls the safe blocks and ultimately controls the canonical chain. The op-proposer submits output roots to L1 which control L2 to L1 messaging.

One key difference between a rollup chain and a sovereign chain is that a rollup chain does not generate block space. A rollup chain does not need a distributed consensus algorithm, such as PBFT, to decide the production of a block, which means a rollup chain does not require a consensus layer similar to that of a sovereign chain. (Note that the decentralized Sequencer is a separate topic, which aims to solve the single point of failure and Sequencer censorship attack problems, not to generate block space.) L2 is designed to utilize L1 block space more efficiently, and L2 is a special accounting program on top of L1. All L2 blocks are derived from the derivation layer.

Derivation Pipeline

The derivation pipeline is the process by which rollup chains derive blocks, which differs significantly from sovereign chains. This process ensures that L2 blocks are derived from L1 blocks, and all L1 deposit transactions are guaranteed to be included in L2 blocks to meet Forced Inclusion requirements. The derivation layer needs to be compiled into the challenging program along with the SVM execution layer. If a sequencer acts maliciously during the derivation pipeline process, it can be challenged through fraud proof.

In addition to subscribing to deposit transactions and block information on L1, the sequencer also needs to package the L2 transactions, which is the essence of L2. There are two sources for the L2 transactions: one is from the L2 p2p network, and the other is from the DA layer. For the sequencer, all the L2 transactions come from the p2p network, which means it is relayed from other RPC nodes. The sequencer needs to package, execute these L2 transactions, and then send the blocks to the DA layer. For the validator, the L2 blocks (transactions ordered and packaged by the sequencer) often first come from the p2p network so that the validator can keep up with the latest state of the L2 network. At the same time, the validator is also constantly subscribing to the DA layer and re-verifying whether the processed blocks are consistent with the DA layer. If the validator discovers that the sequencer has misbehaved, it can directly use the DA data to generate a fraud proof.

Let’s take a look at how Optimism integrates the derivation layer and the execution layer. Before discussing this topic, we need to first understand the architectural evolution of Ethereum. In the initial design, the consensus layer (POW) and the execution layer (EVM) of the Ethereum client were integrated together, i.e., Geth. After The Merge, the Ethereum client was divided into two parts: the Beacon node and the Geth, using the Engine API to decouple the consensus layer and the execution layer.

Optimism has adopted this already deconstructed architecture, replacing the Beacon node with the Op node, and using the derivation layer instead of the Ethereum consensus layer.

In this way, Optimism has completed the integration of the derivation layer and the execution layer, and can then carry out the entire derivation pipeline work, which is to package the deposit transactions and L2 payload, and then execute the transactions.

Now let’s take a look at how to use SVM as the execution layer. Anza team has recently defined the SVM specification and released a new SVM API, providing a standard that the entire SVM ecosystem can align with. However, to get an SVM execution layer with parallel execution capability, ledger storage, and global account state, a standalone SVM engine is not enough. We also need to deconstruct the TPU process from the Solana/Agave validator, which includes components like Banking, Entries, Shreds, Blockstore, and more.

Decoupled SVM Execution Layer

Let’s first take a look at the anatomy of a solana validator.

Solana is a high-performance monolithic blockchain known for its speed and efficiency. It utilizes Tower BFT as its consensus mechanism and employs Proof of History (PoH) to generate time proofs. Additionally, Solana leverages a pipelined architecture for seamless processing, including components like the TPU (Transaction Processing Unit) and TVU (Transaction Validation Unit), as well as Gulf Stream to optimize transaction forwarding. Scheduled transaction execution and Turbine for data propagation are also integral to its design.

However, when considering rollup chains, certain elements of Solana’s architecture can be omitted. Specifically, a rollup chain does not require a Tower BFT consensus layer (including vote transactions for block production) or PoH for generating time proofs. Instead, the focus should be on decoupling a mini-TPU and a Gulf Stream-like transaction forwarding protocol, which can be combined with scheduled transaction execution and Turbine. These components should then be integrated with the derivation layer to complete the entire derivation pipeline.

We defined an interface layer for the basic processes of rollups. With these well-defined interfaces, we can easily implement a rollup framework that is flexible enough to support different consensus mechanisms and various L1 chains. Additionally, we can leverage Solana’s high-performance framework to enhance any L2 solution.

Here are some examples of interface definitions using traits:

To help everyone better understand our architecture, let’s walk through the process of L2 block production, which will illustrate our basic processing workflow. L2 block production is a complex process that involves several steps. Here is a high-level overview of the process:

Derivation: We get the latest L1 block, parsing information we interested in (Header, Deposit Transactions, DA Batch info etc) and store them in a struct implemented by PayloadAttribute trait.
Packing: We pack the PayloadAttribute and normal transactions collected from the transaction stream (submitted by L2 clients) into a struct implemented by BlockPayload trait.
Transport: We send the BlockPayload to Engine, the kernel module that implements the EngineAPI interface and execute transactions using SVM under the hood.
Production: The Engine module produces a block according to the BlockPayload and adds it into the L2 blockchain, it will also handle reorgs and finalization.

The following is a flowchart illustrating the basic process of L2 block production:

Based on the above design, we have open-sourced an educational project called Igloo. It demonstrates how to decouple the SVM Execution layer and how to integrate this SVM Execution layer into the Derivation pipeline.

https://github.com/soonlabs/igloo

Benefits of Decoupling

By decoupling the SVM execution layer, we can build a real optimistic rollup, which includes the essential derivation pipeline. More importantly, this architecture makes the implementation of fraud proofs more natural. By integrating the derivation layer with the SVM execution layer, fraud proofs can simultaneously ensure the correctness of both message passing from L1 to L2 and transaction execution (state transitions) on L2.

The processes represented by the red arrows in the diagram can all be challenged. This ensures that the derivation rules must be executed correctly, such as force inclusion, thereby guaranteeing the security of the entire rollup chain.

Furthermore, by combining SIMD83 and the new scheduler, we can distribute transaction execution tasks to a message queue, using a producer-consumer model for distributed horizontal scaling. By introducing more SVM executors, we can further enhance the parallel processing capability of the sealevel architecture, thereby achieving higher TPS. We will discuss this feature in detail in subsequent articles.

Summary

This article explores the necessity and methodology of implementing a decoupled SVM execution layer in the context of Optimistic Rollups. We begin by examining the classic architecture of Optimistic Rollups, highlighting the critical importance of integrating the derivation layer with the execution layer for rollup chains.

Using the open-source educational project igloo as a case study, we demonstrate how to extract a lightweight SVM execution layer from the Solana validator. It enables the creation of a real optimistic rollup by facilitating more natural implementation of fraud proofs. These proofs can simultaneously verify the correctness of message passing from L1 to L2 and transaction execution on L2.

We also briefly touch on future enhancements for improving transaction processing speed and throughput. This work contributes to the development of more efficient and scalable L2 solutions in the Solana ecosystem.