[Rollup Series] #3: Beyond Equivalence to EVM-Native, Specular

In this article, we explore Specular, a project aiming to build an EVM-native optimistic rollup beyond EVM-equivalence.

100y
A41.io

--

Author: 100y (@100y_eth)

Review: Steve Kim (@steve_nw_kim)

This is Part 3 of the Rollup Series. If you would like to read the other parts, please check out the list below:

Part 1: Scroll, the Dream of a Native zkEVM

Part 2: Classification of zkEVMs and Taiko

Part 3: Beyond Equivalence to EVM-Native, Specular

Part 4: Exploring Coinbase’s L2 Network, Base

Part 5: Mantle, The First Modular Rollup Network

Part 6: Eclipse, a Customizable Rollup Provider

TL;DR

1) Enhancing EVM compatibility is a crucial matter not only for zk-rollups but also for optimistic rollups.

2) While prominent optimistic rollup projects such as Optimism and Arbitrum have achieved EVM-equivalence, they use non-EVM virtual machines to generate fraud proofs, which leads to problems such as reduced client diversity and increased system complexity.

3) Specular aims to go one step further than EVM-equivalence and to become an EVM-native optimistic rollup, enabling fraud proof generation at the EVM layer, resolving current issues.

1. Introduction

In Parts 1 and 2 of the Rollup series, we explored how ZK rollup projects are striving to enhance EVM compatibility. However, improving EVM compatibility is crucial not only for ZK rollups, but also for optimistic rollups. While it may be commonly assumed that optimistic rollup networks such as Optimism and Arbitrum are fully EVM-compatible, the reality is that they are not.

1.1 EVM Compatibility in Optimistic Rollups (e.g. Arbitrum)

The Arbitrum network has undergone the Nitro upgrade as of August 22. Prior to this, the previous Arbitrum used its own execution environment called AVM (Arbitrum Virtual Machine) instead of EVM. While optimistic rollups rely on a fraud proof system to validate off-chain operations, it is challenging to generate fraud proofs in an EVM environment, which is why Arbitrum used AVM.

In the previous Arbitrum network, high-level languages like Solidity and Viper were compiled into EVM bytecode, which then transpiled into AVM bytecode for a proof generation. And this AVM bytecode had the disadvantage of poor performance because it had to serve two purposes -execution and fraud proofing. (Similarly, Optimism also used a custom-built virtual machine called OVM.) In addition to the poor performance, developers had to make modifications when deploying Ethereum code to the prevoius Arbitrum network, meaning that the previous Arbitrum was not EVM-equivalent but rather EVM-compatible, with lower compatibility than an EVM-equivalent network.

(Separation of Execution and Fraud Proof Generation | Source: Arbitrum)

The Arbitrum Nitro upgrade brought a crucial improvement in both performance and EVM compatibility by separating execution and fraud prooving. While AVM bytecode was responsible for both execution and fraud proof generation in the previous model,with the introduction of WASM, the EVM is used for the usual execution environment, while WASM is utilized only when needed for fraud proof generation, making it more suitable. In contrast to the previous AVM-based model, this upgrade significantly improves performance and EVM compatibility, making the current Arbitrum network EVM-equivalent. (Similar upgrades were also carried out in Optimism, but instead of WASM, it uses MIPS.) As a result of the Nitro upgrade, the Arbitrum network has become EVM-equivalent.

2. Specular

Both Optimism and Arbitrum networks have achieved EVM-equivalence, but Specular proposes to go beyond that and proposes a new direction for optimistic rollups, that is EVM-native. In their white paper, Specular identifies three issues with existing optimistic rollup networks and aims to address them. Let’s take a closer look.

2.1 Problem Statement

The first issue is the diversity of clients. Optimism and Arbitrum have introduced MIPS and WASM, respectively, to process fraud proofs separately. However, these systems are designed only for Geth clients, while there are various execution clients such as Besu and Erigon in the Ethereum network. This means that the current optimistic rollups are limited to using Geth only, which is a disadvantage. Having diverse clients in a blockchain network is crucial because if one client dominates the network and an unexpected bug occurs, it can greatly compromise the network’s security.

(Client Diversity on the Ethereum Network | Source: link)

The second issue is the size of the Trusted Computing Base (TCB). TCB refers to the elements, including software and hardware, that can affect the security of a system. The introduction of new VMs (such as MIPS and WASM) to efficiently generate fraud proofs has led to the addition of many new elements, such as compilers that compile Geth’s Golang accordingly, resulting in a significantly larger TCB. The larger the size of the TCB, the greater the attack vector, and it requires a lot of effort to audit the code.

(TCB | Source: Specular)

The third issue is the difficulty of code review and upgrades. Looking at the Ethereum network, client upgrades are frequent, but protocol upgrades are rare. As mentioned earlier, the TCB size of existing optimistic rollups is large, so every time there is a client upgrade, a system upgrade is required, which requires a lot of effort.

2.2 Improvements

(Source: Specular)

Specular proposes an EVM-native approach to tackle the challenges associated with the current optimistic rollups outlined above. The approach utilizes commitment schemes that can efficiently express and compress the EVM stack, memory, storage, and states, allowing on-chain verifier contracts on the Ethereum to verify fraud proofs easily. In other words, it enabled EVM to natively generate fraud proofs instead of introducing external VMs like WASM and MIPS. (For more details, please refer to the white paper).

Incorporating Specular’s approach to fraud proving would resolve all three aforementioned issues. Firstly, since it uses an EVM-native prover for generating fraud proofs, any client suitable for EVM can be used in Layer 2. As a result, unlike other optimistic rollups that can only be used with Geth, Specular can use various clients such as Besu and Erigon, which eliminates the risk of a single point of failure.

Secondly, by eliminating the elements that exist solely for creating fraud proofs, the size of the Trusted Computing Base (TCB) is significantly reduced. This results in a reduction of system complexity, which in turn reduces attack vectors and eases the burden of auditing. Additionally, the TCB no longer includes the client side, but onlyon-chain verifiers that on the Ethereum. This greatly reduces the frequency and burden of upgrades. As previously mentioned, protocol upgrades are infrequent.

2.3 Testnet

Specular is currently in open testnet state, with only minimal features implemented as visible on the main screen. Users can receive testnet tokens from the faucet and try out a simple swap feature from SpecSwap. Interested readers are encouraged to give it a try and experience the platform firsthand.

3. Closing

In summary, while Optimism and Arbitrum Network are at the forefront of optimistic rollup technology, they currently utilize an execution environment other than EVM to generate fraud proofs. This results in reduced client diversity and increased vulnerability due to large Trusted Computing Bases (TCBs). Specular solves the problems of existing optimistic rollups by proceeding with fraud proofs generation in an EVM-native environment and proposes an EVM-native optimistic rollup that goes further than EVM-equivalence.

A concerning issue is that there have been no updates on Specular’s Twitter account since September 22 and on the white paper since December 22 2022. Given that the white paper was a thesis conducted in the UC Berkeley graduate school laboratory, there is uncertainty regarding whether Specular will emerge as a mainnet product in the future. However, it is worth noting that Specular has presented a higher level of EVM compatibility beyond EVM-equivalence.

4. References

Disclaimer: This post is for informational purposes only, and the author is not liable for the consequences arising from any investment or legal decisions based on the information contained in this post. Nothing contained in this post suggests or recommends investing in any particular asset. Making any decisions based only on the information or content of this post is NOT advised.

All for Essence

--

--