# 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倍。