## Scroll

## Scroll & zkEVM

## What is Scroll?

Scroll is building a Layer-2 scaling solution for Ethereum.

## Ethereum's Scalability Problems

Ethereum's goal is to ensure "censorship resistance" and "decentralisation"; but that comes at a cost:
- Each full node must verify each tx
- The entire state is replicated across every full node

The above points limit tx throughput and and in times of congestion, lead to high and unreasonable fees.

## Need Secure Scaling

High network fees drove users to migrate to alt-L1s and sidechains.

Users were incentivised to bridge out of Ethereum:
- Lower fees than Ethereum
- Faster finality than Ethereum
- Higher yield on borrowing-lending/LP protocols

It came with some downsides:
- Downtime on network
- Small validator set or centralised infrastructure
- Insecure bridges (e.g. hacks leading to loss of funds)

## Enter Rollups

Rollups are L2 protocols designed to increase the throughput of Ethereum's base layer:
- Move computation and state-storage off-chain.
- Inherit security guarantees from the base layer (Ethereum).

Optimistic Rollups and ZK-Rollups are two different approaches to rollups.

Scroll is a ZK-Rollup:
- Scroll txs are executed on Scroll's sequencer.
- Bundled (rolled up) into batches.
- Tx data is made available on L1.
- Validity proof for the batch is verified on L1.

## EVM-equivalent ZK-Rollup

Early implementations of ZK-Rollups were application specific (e.g. Loopring). It's hard to achieve composability in an ecosystem where every application runs independently.

We needed general-purpose ZK-Rollups. Rollups that abstract all the complexity away from an Ethereum developer who wants scalability without having to:
- Rewrite application/protocol logic (more testing/auditing).
- Rethink about security guarantees/assumptions.
- Make room for different/additional infrastructure.

Scroll is building an EVM-equivalent ZK-Rollup, and we use Ethereum as our data availability layer as well as secure and decentralised consensus layer.

Comes with all the goodness offered by Rollups:
- Lower fees
- Lower latency (from the L2 perspective)
- Higher throughput

And is EVM-equivalent

## zkEVM?

EVM is a stack-based virtual machine, which defines Ethereum's state transition.

Developers write their application logic in languages such as Solidity, Vyper, Huff, Yul (intermediate representation).

This code is then compiled using different compilers (e.g. solidity compiler for Solidity) down to EVM bytecode; which is a list of EVM opcodes which perform stack operations (e.g. AND, XOR, BALANCE, etc.).

- Language-level:
- Transpile an EVM-friendly language (Solidity) to a SNARK-friendly VM (different than EVM).
- Bytecode-level:
- Interpret EVM bytecode itself.
- Potentially different state root (if the MPT is replaced with another data structure).
- Consensus-level:
- Full equivalence with EVM, Ethereum L1, i.e. proving validity of Ethereum's state root.

Bytecode level compatibility means, devs can use their existing tooling, dapp development frameworks, etc. and deploy their contracts to Scroll L2.

Scroll's zkEVM architecture contains an EVM circuit (sub-circuit in the entire architecture) which can prove that an EVM opcode was executed correctly.

## Comparison

- Starkware
- Uses "Warp" to transpile Solidity to Cairo
- Validity proofs are for their custom zkVM
- There will always be limitations or unsupported EVM features
- ZkSync
- Uses LLVM to compile IR to Zinc instructions
- Validity proofs are for their custom Zinc zkVM
- Bytecode-level compatibility:
- Prove correct execution of EVM opcodes

## Scroll's Architecture

Users bridge tokens from Ethereum (L1) to Scroll (L2) by interacting with Scroll's contract deployed on Ethereum. Scroll's sequencer will mint those tokens to the user on Scroll.

The "Sequencer" is a Geth-fork, allowing us maximum compatibility with the base layer.

The "Roller" is a stateless node in a decentralised prover network, who is tasked with creating validity proofs for the L2 batch of txs.

Overview:
- L2 txs are batched into an L2 block.
- The sequencer extracts the execution trace of all those txs (opcode-by-opcode) and dispatches the trace to a roller.
- The chosen roller responds with a proof for that trace.
- The sequencer posts L2 data to L1 (data availability).
- The sequencer verifies validity proof on L1, through the verifier contract.

So after every L2 tx included by the sequencer, a user receives confirmation that their tx was included on L2. Once the data for that block is published on L1, the user knows that their tx has been committed on L1. Once the validity proof for that block has been verified on L1, the user knows that their tx is finalised from L1's perspective.

## Benefits

* Existing infrastructure is compatible out-of-the-box.
* Just like an entry-level dapp developer does not need to know the Merkle-Patricia Tree in-depth, a dapp developer on Scroll does not need to understand how the validity proof is created for the L2 block.
* Development environments, testing infra can be ported over and the only change needed to be made is the "URL to the RPC provider".
* Inexpensive migration, i.e. no rewrite, no additional audits.

## Our Vision

* Full EVM-equivalence for a better user/dev experience
* Encourage and value decentralisation:
* Prover network decentralisation
* Sequencer decentralisation
* Promote open-source, build together with the community and the Ethereum Foundation
* Peer reviews from the community help us catch bugs at an early stage
* Code maintained better overall to make it as seamless as possible for an open-source contributor to get started with our work

## Roadmap

## Early user

## Join us