Terminology

L1 contract

is a contract deployed on mainnet Ethereum.

zkevm verifier

is an L1 contract that verifies the zkevm proofs.

L2 contract

is a contract that is deployed inside our zkrollup, i.e. it uses the zkevm verifier to prove that transactions calling that smart contract are correct.

l1tx

is a transaction a user sends to interact with an L1 contract.

l2tx

is a transaction a user sends to deploy or interact with an L2 contract

Coordinator

a party that makes proof of validity for Ethereum blocks. The coordinator recives l2txs from users, verifies them, generates witness and proof, and sends it to the zkevm verifier. They use a l1tx to provide these proofs to the zkevm verifier.

User

a party who deploys and/or interacts with smart contracts deployed on l2

Opcodes

EVM opcodes

barryWhiteHat Possibly can remove slot if we can use custom constarints

Slot

This is a number of constraints we assign to prove validity of every EVM opcode. For example we can have a slot of 100 constraints. This means that we will use 100 constraints that we use to prove Mul opcode but also Add , Jump, Sload. Each opcode costs 100 constraints even if it uses less than 100 constraints.

barryWhiteHat possibly can remove hte notation of multislto opcodes as every opcode would be multiple slots.

TODO: reconsider the name slot. it is used in the Solidity docs to refer to a location in storage ("storage slot"): https://docs.soliditylang.org/en/v0.6.8/internals/layout_in_storage.html

can we just rename slot -> row? as in circuit row
ying tong
My understanding of row is that it is similar to constriant. Which means that a slot can contian multiple rows. Is this correct ?
barryWhiteHat

"row" and "constraint" are not interchangeable in my understanding:

the witnessed values in our circuit are arranged in a matrix, where each column is a Lagrange polynomial, and each row is an offset in the polynomial's terms.

so the values in a single row could have multiple constraints applied to them; conversely, one constraint could involve values from multiple rows.
ying tong
barryWhiteHat
Okay that makes sense. A single constraint can use multiple rows. And the number of rows an opcode uses is that opcodes slot. Does that make sense ? Do you think we need names for both row and slot ?
ying tong
in planning the circuit layout, it may be more useful to track no. of rows than to track no. of constraints.

MultiSlot opcodes

Some opcodes can use multiple slots. This means that we just increment the slot_counter and don't increment the program counter.

Program Counter

The location of the current opcode to execute in the EVM. This is incremented after each opcode, in the case of \(\texttt{JUMP}\) it is set to the location of the \(\texttt{JUMP}\). For every new contract call it is set to zero.

Slot Counter

For multislot opcodes we use the slot counter to track how many executions have taken place. This is incremented after each slot. This variable is used to track when a multislot opcode has terminated.

Global Counter

A counter that is incremented for every opcode.

would it be accurate to say that the Global Counter counts the number of reads and writes?
ying tong
Yes But it is also used to distinguis between where you are in a multi slot opcode. For call data copy you use global counter to move to the next step during that step.
I feel global counter is very important and used in many places to guarentee many things.
We use it in our arguments about security https://hackmd.io/Hy_nqH4yTOmjjS9nbOArgw#Proof
barryWhiteHat

Bus Mapping

In traditional computers a Bus is used to transfer data from memory and storage to the CPU. Here we reuse that paradigm to transfer data from our state proof to our EVM proof.

Variables

TODO: types
ying tong

bus_mapping

Similar to a bus in a traditional computer the bus_mapping is used to transfer information from storage, memory and stack ops to the EVM proof.

global_counter

A global counter that increments for every slot of the EVM proof.

call_id

The id of the transaction/separate call context we are currently executing

program_counter

Is the value of program_index to the opcode we need to verify. Where program_index is the location of an opcode in the L2 contract.

program_index

The location of an opcode in the L2 smart contract's bytecode.

mem

A Memory key-value mapping of global_counter -> index -> value

memory_op

Defines the type of memory action this is. For example 0 is read , 1 is write.

Storage

A key-value mapping for storage reads/writes. global_counter -> index -> value

storage_op

Defines what type of storage op to do.

Stack

A key-value mapping for each stack op.

stack_op

Defines the type of stack op

opcode

This is the current opcode to execute.