Scaling Ethereum Efficiently

TL;DR

• Validity Rollups are the most promising way to increase Ethereum’s throughput in a secure and decentralized way; zkEVM and Cairo VM (CVM) are two types of VMs used in Validity Rollups.
• zkEVM focuses on Ethereum compatibility, but sacrifices performance and scalability.
• Cairo VM, used in Starknet, prioritizes performance and scalability over compatibility.

Rollups are the hot topic of the year when talking about scaling Ethereum. Out of the various types of rollups, we believe Validity Rollups (VRs), also known as zk-rollups, are the most promising way to increase Ethereum’s throughput in a secure and decentralized way. At the heart of this scaling solution, is the use of Validity Proofs for verifiable computation. Here’s how they work:

• Instead of processing every transaction on Ethereum’s mainnet, operators offload transaction execution to an off-chain environment. This off-chain environment serves as a Layer 2, meaning a layer operating on top of Ethereum.
• After processing massive batches of transactions, the Layer 2 operator returns the results to be applied to Ethereum’s state, along with a Validity Proof to verify the integrity of the off-chain execution. The proof guarantees that all transactions in a batch are valid, and is verified autonomously by the on-chain verifier contract. This allows Ethereum to apply the result to its state.

Note: Validity Rollups are often mistakenly referred to as Zero-Knowledge Rollups, but this is not accurate. Most Validity Rollups do not use ZKPs and are not utilized for the purpose of ensuring privacy. Hence the term “Validity Rollup” is more accurate.

The Off-Chain VM

Before proceeding, the first question we need to answer is: What is a virtual machine (VM)? Put simply, it is an environment in which programs can run, like a Mac running a Windows OS. It transitions between states after performing computations on some inputs. The Ethereum Virtual Machine (EVM) is the VM that runs Ethereum smart contracts.

A Zero Knowledge Virtual Machine (zkVM) is a program execution environment that, along with the program outputs, allows for the generation of a Validity Proof that can be easily verified. This Validity Proof proves that the program was executed correctly. When the term “zkEVM” is used, it generally refers to a rollup that utilizes the Ethereum Virtual Machine (EVM) and is capable of proving EVM executions. This terminology can be misleading because the EVM itself does not generate these proofs; instead, the proofs are generated by a separate prover mechanism that takes the results of EVM execution as its starting point. Also, these proofs are about validity, not privacy, hence they are not exactly Zero-Knowledge Proofs. Nevertheless, for consistency, we’ll stick with the conventional term “zkEVM” in this writeup.

While all Validity Rollups aim to harness Validity Proofs to scale Ethereum, they differ in their choice of VM to execute transactions off-chain. Many Validity Rollups chose to replicate the design of the EVM (and are thus called “zkEVM rollups”), attempting to replicate Ethereum on the L2 rollup. Starknet uses a new VM — the Cairo VM (CVM) — which was designed specifically to optimize Validity proof efficiency.

Both these approaches have their own advantages and tradeoffs, but zkEVMs trade performance for Ethereum compatibility, and the Cairo VM prioritizes performance over compatibility, prioritizing scaling capabilities.

The zkEVM Approach

A zkEVM is a Validity Rollup with the goal of bringing the Ethereum experience fully to Layer-2 blockchains. It aims to replicate the Ethereum developer environment as a rollup. With zkEVMs, developers would not need to change their code or abandon their EVM tools (and smart contracts) when writing or porting smart contracts to more scalable solutions.

One major drawback of this approach is that it reduces the scaling potential of Validity Proofs. zkEVMs are slower and more resource-intensive due to their commitment to compatibility with Ethereum. The EVM was not designed with proving efficiency in mind, unlike the CVM. This restricts the use of optimizations that could improve efficiency and scalability, ultimately affecting the system’s overall performance.

Provability of the EVM

The central challenge with the zkEVM approach is rooted in the EVM’s original blueprint — it wasn’t designed to function within a Validity Proof context. Consequently, efforts to mirror its functionality fail to unlock the full potential of validity proofs, resulting in less-than-optimal efficiency. Such inefficiency ultimately weighs down the system’s overall performance. The EVM’s compatibility with Validity Proofs is hindered by the following factors:

• The EVM employs a stack-based model, whereas Validity Proofs are more effectively employed with a register-based model. The stack-based nature of the EVM makes it inherently more difficult to demonstrate the correctness of its execution and provide direct support for its native toolchain.
• The Ethereum storage layout relies heavily on Keccak and a large Merkle Patricia Tree, both of which are not Validity Proof-friendly and impose a substantial proving burden. For example, Keccak is very fast for the x86 architectures (over which we usually run the EVM), but takes 90k steps to prove (with a special build built-in). While Pedersen (a zk-friendly hash function) takes 32 steps. Even with recursive compression, the use of Keccak in a zkEVM means high prover resources which end up being paid by the user.

As a result, various zkEVMs aim for different levels of support for Ethereum tooling– the more Ethereum compatible a zkEVM is, the less performant. (For more info on zkEVM types, skip to the end of the post.)

The Cairo-VM Approach

zkEVM solutions invest substantial development time in “making the EVM work for Validity Rollups”, prioritizing compatibility over long-term performance and scalability. There is another option: use an entirely new, dedicated VM, and add support for Ethereum tooling as an additional layer on top. This is the approach taken with Starknet, a permissionless Validity Rollup launched in November 2021. Starknet is the first Validity Rollup to offer a general-purpose smart contract platform on a fully composable network.

Starknet uses the Cairo-VM (CVM), with a high level language of the same name. The Cairo-VM is a VM designed for efficient generation of Validity Proofs for programs’ execution.

With Cairo (the VM and language), we have:

1. Optimized validity proofs — every instruction has an efficient algebraic representation

2. A modern rust-like language for writing provable programs

3. An intermediate representation (Sierra) between high level Cairo and Cairo assembly (VM instructions) which allows efficient execution of Cairo code

Developing a new language allows one to tailor it to the specific needs it is intended to meet, as well as equip it with features that answer previously unmet needs.

Cairo and Coding Pluralism

In order to create a Validity Proof about some computation, first this computation must be expressed as a sequence of mathematical constraints describing the computation. This process can be very tricky due to the challenge of optimizing computations for efficiency, and the need for specialized tooling.

The Cairo language was initially designed to simplify this task and make it easier to add features and complex business logic to StarkEx. Cairo programs are compiled into algebraic machine code — a sequence of numbers — that a single, fixed VM executes. With Cairo, the whole complexity of generating mathematical constraints describing the computation — a thorny issue for Validity Proofs — is abstracted away and captured by the fixed set of constraints (less than 50 constraints in total). As a result, developers can leverage Validity Proofs to scale their apps without needing to understand the underlying math and infrastructure, by writing code in a syntax they are familiar with.

https://twitter.com/EliBenSasson/status/1638270015009968134

Starknet is all about innovation and this is reflected in its pluralistic approach to code. Cairo’s power to get the best scaling using STARKs is not limited to those who write their contracts natively in Cairo. Developers can opt for an approach that suits them best:

• Code natively in Cairo: With the release of Cairo 1.0, developers now have access to an ergonomic and safe Rust-inspired language which makes writing program logic much easier and less error-prone.
• Solidity-compatibility: Solidity developers can write code that can be used by the Cairo VM. This method offers a similar developer experience to Ethereum and makes Solidity smart contracts portable to Starknet. There are two ways of achieving this:
• Transpiling: Transpiling refers to the process of converting source code written in a programming language to another language. The Nethermind team has created the Warp transpiler, for transpiling Solidity code into Cairo. Warp makes Solidity smart contracts portable to Starknet, effectively making it a Type 4 zkEVM. It has already been used to transpile and deploy Uniswap contracts with only minimal changes.
• zkEVM on Starknet: The Cairo VM can be used to prove the execution of another VM. Kakarot is a zkEVM written in Cairo, that can be used to run Ethereum smart contracts on Starknet. The Cairo VM and zkEVM aren’t competing approaches and instead of choosing between Cairo VM and zkEVM, we can have both!

Despite being around for a short time, Cairo is the 4th most popular smart contract language by TVL and already secures over $350M.

Summary

A zkEVM aims to replicate the Ethereum environment as a rollup and allows developers to use familiar Ethereum tooling. However, this approach inhibits the full potential of Validity Proofs and can be resource-intensive.

The Cairo VM is designed specifically for Validity Proof systems, without being constrained by the EVM’s limitations. It is supported by a new, safe and ergonomic Rust-inspired programming language, called Cairo 1.0, forming a powerful tool, designed to gain maximum efficiency from using STARK Proofs for scaling Ethereum.

It’s exciting to see the track record that Cairo achieves week by week, as well as the growth of different options for developers, such as the Kakarot zkEVM and Warp. As Starknet dApps enter production, demonstrating Cairo’s power, we’re confident it will be used for ever-more ambitious projects in the future.

As a result of the three routes to STARK scaling outlined above, and doubtless others that will be offered in the months to come, developers now have previously unimaginable control over scaling blockchains.

Types of zkEVM

Vitalik categorizes zkEVMs primarily into four types:

Type 1 or fully Ethereum-equivalent: Do not change any part of the Ethereum ecosystem.

Type 2 or fully EVM-equivalent: Compatible with existing dApps, but make some changes to Ethereum’s design for faster proof generation.

Type 3 or almost EVM-equivalent: Support most EVM opcodes, but remove some features that are hard to implement in a zkEVM implementation (eg: precompiles, hash fucntions).

Type 4 or high-level language-equivalent: Take smart contract code written in Solidity / Vyper and compile that to a Validity Proof-friendly language.