---
# ZKEVM intro

:::warning
Hello there,
Thanks for your interest in ZKEVM.
We now have a [spec repo](https://github.com/appliedzkp/zkevm-specs) and a [circuit repo](https://github.com/appliedzkp/zkevm-circuits) now, and we would like to invite you to there.
This hackmd book is no longer maintained.
:::

## Introduction

At the moment every node on ethereum has to validate every transaction in the ethereum virtual machine. This means that every transaction adds work that everyone needs to do to verify ethereums history. Worse still is that each transaction needs to be verified by every new node. Which means the amout of work a new node needs to do the sync the network is growing constantly. We want to build a proof of validity for the Ethereum blocks to avoid this. Are two goals are

1. Make a zkrollup that supports smart contracts
2. Create a proof of validity for every Ethereum block

This means making a proof of validity for the EVM + state reads / writes + signatures.

To simplify we separate our proofs into two components.

1. **State proof**: State/memory/stack ops have been performed correctly. This does not check if the correct location has been read/written. We allow our prover to pick any location here and in the EVM proof confirm it is correct.
2. **EVM proof**: This checks that the correct opcode is called at the correct time. It checks the validity of these opcodes. It also confirms that for each of these opcodes the state proof performed the correct operation.

Only after verifying both proofs are we confident that that Ethereum block is executed correctly.

## Bus mapping

Our state proof and EVM proof need to talk to eachother. We need some kind of accumulator to do this. Merkle trees where for a long time the best way of achiveing such communication. But this would add 1000's of consraints to each opcode. instead we use a plookup key value mapping. We call this bus mapping afte the bus on a traditional computer.

https://hackmd.io/AmhZ2ryITxicmhYFyQ0DEw

## Word Encoding

In the evm every word is 256 bits. We encode the word a bit differntly in the zkevm. Basically a random linear combination of 8 bit words. This helps a lot with opcodes. The stack and memory don't need to worry about this encodeing they can just deal with the commitments.

https://hackmd.io/QUiYS3MnTu29s62yg9EtLQ

## Call ID

NOTE: We used to name call_context call_id
TODO : rename callid to call context everywhere else

We use `call_context` to tell the EVM proof which is the correct context the memory , storage and stack operations should be applied inside.

For example:
1. During a call the stack and memory context change but the storage stays the same.
2. During a `call_data_copy` the source memory context is adjusted to that of the calling contract.
3. During a `return_data_copy` the source memory context is adjusted to that of the call_context that returned last. (This is not tracked inside the call_context but is good to note)

More details https://hackmd.io/0Z3N9gniRAmOg8X1RN6VAg

## State Proof
https://hackmd.io/Nwd0e5AgTVSBWRQlp-Ving

### Memory Opcodes
https://hackmd.io/Nwd0e5AgTVSBWRQlp-Ving#Memory-Circuit

### Stack Opcodes
https://hackmd.io/Nwd0e5AgTVSBWRQlp-Ving#Stack-Circuit

### Storage Opcodes
https://hackmd.io/kON1GVL6QOC6t5tf_OTuKA

## EVM proof

https://hackmd.io/@liangcc/zkvmbook/%2Fq8EhMIp_TimpPWWFXtwOVw

### Layout and branching (draft)
https://hackmd.io/QmmGsuVpRUmPDT0Pvr8VIw

### Flow Control Opcodes

### Arithmetic Opcodes

### Bitwise Opcodes

### Constant Reads Opcodes

#### Block Constants

#### Transaction Constants

## Appendix

### Terminology

https://hackmd.io/bF-_y4OVQMyBHQMFG7tYpA

###