# zkEVM book – Draft outline and notes

This note is an informal proposal for structuring the early chapters of a future zkEVM book. The goal is to identify and draft foundational material that could serve as a reference for people interested in the zkEVM project — its motivations, design considerations, and long-term vision.

These sections are not yet about technical implementation. Instead, they aim to capture high-level framing, open questions, and shared context that will help guide the development of the book over time.

## Why zkEVM?

This chapter should articulate the core motivations behind zkEVM. While there are many perspectives within the community, we propose including discussion around the following:

* What are we trying to achieve with zkEVM?
* Why can't we increase the gas limit?
* State proof and execution proof
* How does zkEVM fit into Ethereum’s long-term roadmap?
* What is the broader vision or endgame for zkEVM-based Ethereum?

This section should remain open-ended and allow contributors to frame the narrative from different angles.

## Client setup to achieve zkEVM vision

In a stateless world, clients can verify or propose blocks without holding the full state. Instead, blocks are bundled with the *minimal state data* required for execution—along with cryptographic *proofs* that this data is valid.

This section explores how this setup works, what architectural changes it introduces, and why it matters.

### Core concepts

* **Stateful vs Stateless clients**
Traditional Ethereum clients maintain the full state on disk. Stateless clients, by contrast, operate using externally provided state data and verify it with Merkle proofs or zk-proofs.

* **Stateless Proposers**
A proposer without local access to state cannot build blocks directly. Instead, they rely on external builders or infrastructure to construct blocks with attached state proofs.

* **Partially Stateless RPC**
Some clients (or applications) may only need a subset of the state. These clients can fetch verified state snippets on-demand via proof-bearing RPC calls.

* **Proof-Giving Stateful RPC**
Untrusted RPC providers (e.g. Infura) can return state data *with Merkle Patricia Trie proofs*, allowing clients to independently verify correctness without trusting the provider.

### Architectures

Two primary patterns have emerged:

* **Separate Clients**
Stateless clients (CL+EL) connect to stateful peers over a network subprotocol. Execution and verification are decoupled but remain interactive.

* **Embedded Clients**
A single client combines consensus logic (CL) with a lightweight embedded EL verifier (e.g. a zkVM or stateless executor). It receives blocks and proofs via gossip and verifies locally.

Stateless setup reduces trust assumptions and hardware requirements for participants, but introduces new complexities in proof generation, block propagation, and fallback mechanisms. This section provides a foundation for understanding those tradeoffs and framing the design space.

## Standardization

A major part of the zkEVM effort today is focused on standardization. We propose dedicating a chapter to:

* What aspects of zkEVM we aim to standardize (e.g. APIs, opcode behavior, precompile limits).
* Why standardization matters for ecosystem alignment and client integration.
* How we might approach this process (e.g. open specifications, working groups, Ethereum Foundation coordination).

This section can serve as a roadmap or reference for aligning implementations without freezing them.

## zkBoost

While currently a minimal HTTP interface, zkBoost could evolve into something more substantial. This chapter could explore:

* The current scope of zkBoost.
* A space to brainstorm what we *could* do with zkBoost in the future.
* What role (if any) it might play in user/dev tooling, proving orchestration, or performance optimization.

This chapter is intentionally speculative.

## Security

We suggest including a chapter focused on how zkEVM team are approaching security. This might include:

* High-level goals around correctness, soundness, and verification.
* A brief introduction to the shared zkEVM security standards currently being drafted.
* A placeholder for a summary or link to the eventual public version of the zkEVM Security Document.

This chapter can evolve alongside the security work itself.

## Ethereum client teams

This chapter should outline what zkEVM integration means for Ethereum client teams, and how the Ethereum Foundation can support that process.

- What needs to be integrated?
- Which parts of the client are affected?
- Main possible challenges
- Ethereum Foundation’s role:
* Provide reference implementations and specs.
* Coordinate between zkVM and client teams.
* Offer integration examples and tooling.

This chapter can serve as guidance for client developers and clarify where support and coordination are needed.

## Bridging zkVM Vendors and Ethereum Clients

zkEVM creates a new relationship between low-level zkVM vendors and Ethereum client teams. This chapter could address:

* The communication and integration challenges between these two groups.
* What coordination mechanisms or standards might help.
* The role of the Ethereum Foundation in facilitating collaboration.

This section should help clarify expectations on both sides of the integration process.

Absolutely — here is a **shorter version** of the **“Benchmarking Effort”** chapter, keeping it clear, structured, and aligned with the tone of your zkEVM book outline:

## Benchmarking Effort

Benchmarking is essential to understanding and improving zkEVM performance across zkVMs and execution clients.

It helps answer:

* How expensive are specific EVM opcodes and precompiles?
* Where do performance bottlenecks arise in proving?
* How do changes in protocol design (e.g. gas repricing, state layout) impact zkEVM?

### Focus areas

* Standardized benchmarks for opcodes, precompiles, and protocol stress cases
* EL client plug-and-play: test zkVMs with different Ethereum clients
* zkVM plug-and-play: compare proof time, size, and circuit behavior
* Protocol change tracking: evaluate gas model changes, state tree formats, chunking

### Tools and status

Initial work includes shared test cases, trace generation tools, and the `zkEVM Bench` framework. These help structure comparisons and guide performance improvements.

Benchmarking supports standardization and provides visibility into how zkEVMs scale. It is a collaborative effort, evolving alongside engineering and protocol design.

## Scope of this outline

All the proposed chapters here focus on project-level questions, not implementation details. The idea is to:

* Provide a shared context that doesn’t block ongoing technical work.
* Build a reference layer that can guide future design and documentation.
* Iterate openly, treating the book as a living plan.

We can dive into deeper technical chapters later, once the groundwork is stable.