---
# System prepended metadata

title: 2022-09-20 zkevm 大设计

---

# 2022-09-20 zkevm 大设计


## Q1 我们一共会有几个电路？  
Wrong answer: evm + state + storage + keccak + poseidon + bytecode + tx + public_input + agg
(exp? rlp?) 

scenario（这个讨论重点不是 exp circuit 自己，而是用这个例子来讨论流程）:
developer 提议开发 exp circuit.

可能性1: 我们 **早就决定**不该加新的电路，因此劝阻 exp circuit。   
可能性2: 我们 虽然**之前决定**不加新的电路，但是又想了下觉得还是值得加，因此继续开发。   
**可能性3**: 我们没思考过要不要加新的电路。而且认为这件事情是无足轻重的优化细节。那现在想加就加吧，加完看看性能再说。

不好的预期：exp 加了个 circuit，那么还有多少的 opcode / precompile 会再加多少个 circuit? 

另一种可能性：为什么不是有一个类似 FiveMainGate 的东西，exp / addmod / mul_div 全部用这个？（可能是 10 columns 左右，加强版 base plonk gate，参考 plonky1 和 kimchi . https://mirprotocol.org/blog/Fast-recursive-arguments-based-on-Plonk-and-Halo）（more 见 Q2)

zzhang: (1) 这不是优化细节。这是根本设计。这类事情做错可能有 30% 量级的工作重写。这个比例可能重写的话没法 audit。recall withdraw 4M gas 问题。我认为尽早回答这个问题是重要的。(2) 我的能力回答这个问题会比较吃力。我感觉这需要团队层面的高效合作。

## Q2 电路的整体风格.  
现状：(1) 很多 custom gate（几百量级，而不是 dozen 量级）。(2) 几百 col 
原因：针对(1)，我们认为 aggregation 是必要的，既然如此，很多 custom gates 对于 agg 来说不算特别大 cost，而且 agg 后 众多 gates 也不会反映在 solidity verifier gas 中，因此这是没问题的。

## Q3 bridge.  
现状：核心 insight 是 zkevm 特判 bridge/messager 合约的一个 in-contract keccak merkle root ，并且暴露成 public input。强行让 L1 / L2 share 一个 root。

## Q4 bytecode hash.  
现状：posedion。核心依据是因为每 step 都要解码，担心 keccak 开销极高。

## Q5 randomness 来源.  
challenge api / public input circuit 那个 commitment then hash/rlc 

## Q6 batch vs block 定义.  
block == tx, batch is blocks。见 notion

## Q7 storage.  
zktrie。designed。**现状至少和 “最优方案”不差量级**。最多是 rescue VS poseidon，2叉 vs 4叉，**这种真正的优化细节**。

## Q8 precompile   
not easy. ercrecover 最优先。pairing 不优先。（当然如果现成另说）

## Q9 TPS. 
我们内部的 timeline 需要有个 N年N月N tps 的大致估计。因为不同 tps 需要的架构是不同的。比如，**稳定数百 tps，可能需要把 bus mapping 大部分 feature 挪到 l2geth tracer 里面**。

## Q10 DA and public input.   
一般来说，public input is (chain_id, coinbase, timestamp, block_hash，state_root, bridge_state_root..).（zzhang + kunxian 赞成，这不是 pse 的方案）
block_hash = hash(rlp(block_header || txs)) 
txs 怎么 encoding? rlp？（这需不需要一个 (partiallly) rlp circuit？）

另一种方案是 state diff。我们认为 txs（包含 signatrue吗？） 更方便处理，更去中心化。可能代价是 bigger cost。

## Q11 receipt / event   
观点：最好有。但是可以不 sound ，不作为 proof 的一部分。更接近于小工具的定位。

## Q12 兼容性。 
观点：仅 self-destruct / zktrie / codehash 不兼容。
担心：工作量大。可以考虑分优先级。而且有些 opcode like blockhash l2 不见得有啥意义。甚至某种程度上，

## Q13 verifier
GAS 多少是可以接受的？一般是 ax（比例部分） + b（常数部分）。各多少？

## Q14 
开发 / 设计 / research / 友商调研 的 时间分配。
比如说：我们某个会议上决定让 XX 花 XX 时间调研 hermez 的 XX 模块，预计交付一个包含 XX 内容的报告。而不是 XX 自发地看了看。

## Q force exit

## Q Agg 
pairing 做在里面还是外面？现状：外面，更传统/保守/稳妥。





## MISC-一些沟通要点：   
抓大放小。用一句话概括回答。不要因为怕失真而模糊焦点，可能接受略微夸张。短会上就不要说5%的 edge case 了，因为不可能用 1/20 时间说。听众会有错误印象。   
敢于定量。上下偏差1倍是很好的估计。没有这种定量，不同的人的理解可能差10倍，而不是1倍。

