---
# System prepended metadata

title: ZKEVM - Keccak256 Table
tags: [archived]

---



## Introduction

In EVM state transition, we have lots of dynamic size keccak256 to do, and some of them has really bad worst case, for instance opcode `KECCAK256`, we can hash up to 1182560 [^maximum-hash-input] bytes with 3M gas block.

[^maximum-hash-input]: $2999953 = 60 + (3 * \frac{1182560}{32} + \frac{(\frac{1182560}{32})^2}{512}) + 6 * \frac{1182560}{32}$

So in order to avoid the overhead of handling worst case from EVM circuit (and other circuits with heavy keccak256 usage), we separate the keccak256 logic into Keccak256 cirucit, then communicate the input by random linear combination, which helps to synchronize dynamic bytes in between dynamic positions.

## Keccak256 Table Layout

Since Keccak256 circuit is designed to repeat `keccak_f` all the way down, except in between `keccak_f`, all the other logics are static. This makes it easier to form the table for other circuits' usage.

A naive approach looks like below:

![](https://hackmd.io/_uploads/ryCnYI7C5.png)

The Keccak256 table could be simply created by copy constraint (colored parts), because every `keccak_f` has static position.

For dependent, it needs to construct its own auxiliary part to calculate the random linear combination of input and output in Keccak256 table, the layout should make it easy to constrcut the constraints, then we don't need to share challenge anymore.
