Polygon zkEVM系列文章的第一篇，简要的阐述了polygon zkEVM的的整体架构和交易执行流程，并且分析了polygon zkEVM是如何实现P # o 8 ! U @计算扩容q O V N w的同时继承以太坊的安全性的。

同时还会在接下来两篇文章会详细介绍Pop X G |lygon zk) ; f V / 5 x qEVM的zkEVM Bridge和zkEVM的设计细节，以及polygon zkEVM接下来的去中心化sequencer的路线图。

目v L q m c录

• Rollup 是为了给以太坊实现计算H 2 P 9扩容
• 不同 Rollup 路C | Y I ? H线之间的区别
• Polygon zkEVM 的具体执行流程 & 整体架构
• 从模块化区块链的角度解析 Polygon zkEVM
• Polygon zkEVM 如何继承L1– g & /的安全性
• Polygon z% 7 zkEVM 激励机制

1.Rollup为了给以太坊实现计算扩容

首先，我们` m $ / i m需要明确rollup的大概工作原理:

rollup的出现v m V的是为了给Ethereum实现计算扩容，具体的实现方法是将交易的执行外包给 Rollup,然后将交易和交易执行后的状态(state)存储在 Ethereum 的合约内。

由于技术路线的不同演变出了两种类型的 Rollup:

• Optimistic Rollup:
• 乐观的认为发送到 Ethereum 的 Rollup 交易(Rol0 W D 0 ! # ) e Tlup transaction)和对应的 Rollup 状态(Rollup State )都是正确的，任何人都可以通过提供欺诈证明(fraud proof)对还处于挑战期的Rollup State进行挑战(challenge)
• Zero-knowlp @ fedge Rollup:
• 会为发送到 EthereumD w B / t ~ D ) 的 RW : = B u ! l $ 9ollup交易(RollE 8 Hup Transaction)和对应的 Rollup 状态(Rollup state)提供一个有效性证明(validi] } N f )ty proof)1 \ u c , l(由以太坊上的合约验证，来证明 Rollup 的执行对应交易后的状态时正确的)
• (参考以太坊官方定义) 链接f t W \ u/docs/scaling/#rollups

Zero-knowle/ I o 1dge Rollup 和 Optimistic Rollup 最大的区别就是由于验证状态有效8 / 2 d R U ; + ,性的不同方式导致达成 finality 的时间不同；

OptimisE = \ x ( f =tic Rollup 乐观的认为提交到 Ethereum 上的交C I m n + R ? 2易和状态都是正确的，所以P & & d V j H $ &存在7天的挑战期（达成finalityU \ S I D 0 + { J的时间是7天），期间M E _ E任何人发现在 Ethereum 上的交易对应状态不正确都可以通过提交正确的状态进行挑战。

Zero-knowle@ M 1 t bdge RolluO = A ~ 7 g M Fp( zk-Rollup ) 达成 finality 的时间，则I 5 @ m g \ a取决于： 交易对应的有效性证明( validity proof )提交到以太坊并且验证通过所花费的时间。目前可能在= / r k \ 61个小时左右的finality居多。(因为需要考虑到Gas成本问题)m b N N \ 4 |

2.Polygon zkEVM 执行流程

接下里我们以一个简d 3 h h单的交易被确认流程来看看 Polygon zkEVM是怎么工作的，从而对整体协议有一个具体的理解；

整个过程可以主要分为三个步骤:

1. Sequencer 将多个用户交易打包成 Batch 提交到L1的M ) % . z合约上。
2. Prover 为每笔交易生成有效性证明(validity proof)，并将多个交易的有效性证明聚合成一个有效性证明。
3. Aggregator 提交聚合了多个交易的有效性证明(validity proof) 到 L1 的合约中。

1) Sequencer 将用户交易打包成 Batch 提交到 L1 合约上

1. 用户将交易发送给Sequencer, Sequencer会在本地按照收到交易的快慢顺序进行处理(FRFS)，当Sequencer在本地将交易执行成功! | N [ 4 k后，如果用户相信Sequencer是诚实的，那么他可以认为这个时候的交易L 2 n ? R a } C C已经达成了finality。
2. 这里需要4 6 1 {注意，目前大` X 7 ( , A –多数Sequenq u \ ~ %cer内部的Mempool(交易池)都是私有的，所以暂时可以获取的MEV是比较少的
3. SequencU ` Ber 会将多笔交易打包进6 | | $ Z p一个Batch里(目前是一个Batch里只包含一个交易) ， 然后在收集到多个Batches之后, 通过L1上的 PolygonZKEvm.sol 的sequenceBatch()函数将多个Batch一起送到L1的交易call8 ^ i W x gdata上。

需要注意这里一次性提交多个Batch是为了尽可能减少L1的gas消耗

3.当 PolygonZkEvm.sol 收到 Sequencer 提供的 Batches 后，它会依次在合约内计算每个Batch的哈希，然后在后一个Batch里记录前一个Batch的哈希，于是我们就得到了下图的Batcho X c Y结构

4.每个Batch里的交易顺序也是确定的，所以当Ba1 3 dtch的顺序确定之后，我们认为所有被包含在Batch提交到L1的 polygonZkEe Z o 3 b | iVM合约的交易的顺序都被确定了。

以上实际上过程也是L1充当Rollup DA层需要完成的工作(这个时候并没有完成任何状态检验或推进^ / d Q ;的工作)。

2t o b 3 Z g ) z 8) Aggregator 为多个Batch的交易生! 2 p x , N t $ e成 validity Proof

1. 当Aggregat; h ] 4 o v – Cor监听到L1的 PolyonZKEVM.sol 合约中已经有新的 Batch 被成功的提交之后，它会把这些 Batch 同步到自己的节点里，然后给 zkProver 发送这些交易.
2. zkProver 接收到这些交易之后会并行为每笔交易生成 validity proof，再将多个Batch包含的交易的 validity proof再聚合成一个有效性证明(validity proof).

3.zkProver 将聚合多个交易的vU Y f } H ; halidity proof发送给 Aggregator

3) Aggregator 提交聚合证明到 L1 的合约

Aggregator 会将这个有效性证明(validity proof)以及对应的这些 Batch 执行后的状态一起提交到 L1 的 pot y V ( ~ YlygonZkEvmZ n 1 t ~.sol 合约内（通过调用以下方法）

合约内接下来会执行以下操作来验证状态转换是否正确:

1. 从合约内拿到最后一个被验证过的Batch的BatchIndex :curb p q *rentLastVerifiedBatch （理想情况下initNumBatch ==currentLastVe? H \ S F 1 v ? grifiedBatch）
2. 根据 BatchIndex 拿到合约内最新的状态 oldStateRoot
3. oldStateRoot = batchNumToStateRoot[initNumBatch];
4. 合约内有这样一这个mapping: baX y n @ BtchNumToStateRoot 维护一个batchIndex映射到该batch执行结束后对应的状态
5. 然后传入validity proof对应(B 5 h o[proofA,proofB,proofC]) ，这个validity proofS H s 6 9 X K @要验证的batches的范围和这部分batch执行前的状态和执行后的状态；
6. 其中执行前的状态必须选定为合约内已有的经过验证的状态
7. 将合约内的 MATIC 转帐给提交正确 vali9 r ddity pX _ S F ( a \roof 的 Aggregator
8. 更新 batchNumToStateRoot 这个mapping, 和 lastVerifiedBatch
9. batchNumToStateRoot[finalNewBatch] = newSR t e I 6 L l |tateRoot;
10. lastVerifiedBatch = finalNewBatchX 5 X;
11. globalExitRootManager.updateExitRoot(newLocalExitRoot);

当这一步在L1合约内执行成功时% O H 9 s /，这部分batch包含的所有交易也就真正达成了finality（对应op的7天挑战期结束）

3. Ethereum 在 pop s 9 n ? O \lygon-zkEVM 中充当的角色

上文我们已经了解了polygon zkEVM的整体流程, 可以回顾下Ethereum 为v 8 w Rollup_ _ } 做W S p 1 T , w [了哪些工作:

1. Sequencer 将 Rollup 的交易收集起来打成 Batch 之后，提交到L1的d V } e p V X合约中。
2. Aggregator 将validity proof 提及到L1合约上来达成新的状态

在第一步，实际上L1不仅仅提供了DA层的功能，实际上还完成了一部分交易排序的功能；实际上当你把交易提交到Sequencerw K u时，交易是没有真正被定序的，因为Sequencer有权力可以随便改变交易的顺序，但是当交易被包含在Batch里提交到L1合约上之后，任何人都没有权利再修改其中的交易顺序。

在第二步，Aggregator则是类似Proposer的角色，合约则类似validator的角色；Aggregator 提供了一个validity p6 Q =roof来声明一个新的状态是正确的，并告诉validator我提供的validity proof涉及哪些交易Batch，他们都存在了L1的哪个b X \ W ? \位置。

接着validator从合约中提取对应的Ba` P e Jtch，与validity proof结合在一起# O 0 U . C k !就可以验证状态转换的合法性了，如果验证成功实际上合约内也会更新到对应validity proof的新状态。

3$ # [ & Q. 从模块化Q \ d y h : 1 j G的角度结构 Smart Contract Rollup

如果从模块化的角度来看，Polygon zkEVM 属于V v G ) ~ T H $ (Smart Contract Rollup 类型，我们可y g t D B n I以尝试解构下它的各个模块：

从 Delphi 给的图中， 我们也可以看出实际\ S c ) Q m &上 Pol8 9 3 Q 4ygon ZkEVM 作为 Smark P 8t Contrat Rollup的Consensus Layer ,DA LaZ | . E h 0 (yer 和 SettlemenA V b ; $ V ^t Layer其实都是耦合在polygonZkEVM.sol合约中，并不能很好的区分。

但是我们尝试着去解构各个模块:

• 数据可8 x u用层(Data Availability Layer): Rollup交易存放的地方
• 对于Polygon-zkEVM来说 ，当Sequencer调用SequenceBatch() 方法的时候，实际上就包含了往DA层提交交易数据
• 结算层(Settlement Layer): 具体指的是Rollup和L1之间的资金流动机E v v C u @制
• 具体指的是Polygon-zkEVM的官方桥(在下一篇文章会有详细介绍y v ~ { 5 ~ v)
• 共识层(Consensust @ z + l Q t ) Layer): 包含交易排序和如何确定下一个合法状态(分叉选择7 { P i)
• Sequenc3 C E H h 3 ; Ter 调用L1合约中的SequenceBatch() 的时候V s { / )完成了交易排序的工作，当Aggw = 5 v W r ` S =regator 调用L1合约中的t3 m _ @ w e ? drustedVerifyBatches() 的时候完成了确认下一个合法状态的工作。
• 执行层(Executionq ! x 3 { ) M S Layer): 执行交易并且得到新的世界状态
• 当用户向Sequencer提交交易，并且Sequencer执行完之后得到新状态的过程(所以我们往往说rollup是计: . 9 } u M算扩容，因为L1把执行交易得出新状d ^ T – + 8 b s –态的这个过程外包给了O + SRollup)

Sequeu 7 Z O i H m / uncer会通过aggregator委托zkProver帮忙生成validity proof。

4. 为什么说 polygon-zkEVM 继承了L1的安全性

1. 从上面介绍的整体流程上看，实际上Sequencer做了类似以太坊 Proposer的工作，提议了一批交易是有效交易，并且给出了这批交易执行后的新状态；而L1合约的验证逻辑，相当于所有L1的validator实际上都会在自己的以太坊客户端里执行一遍，实际上是所| ? O : \有的以太坊验证者充当了Rollup的验证者，因此我们0 T L \ V # Q A认为 polygo] N z + . ^n zk( l H r – e t c GEVM 继承了以太坊的安全性。
2. 从另外一个角度上看，因为rollup的所有交易以及状态都存储在以a ! O u X 1 f !太坊上，所以即便polygon zkEVM 这个团队跑路了，任何人都还是有能力依托以太坊上存储的数据，恢复整个Rollup网络。

5. Polygon zkEVM 激励机制

Rollup激励机制主要指的是如何让Sequencer和AggrZ & g \egator有利可图，从而保持持续性的工作。

首先用户需要支付自己在Rollup上的交易的手续费，这部分的手续费是采用ETH计价的，用Bridged ETH支付。

Sequencer 则需要支付这些包含Rollup交易的Batch上传到L1交易的calldata上的成本(调用SequenceBatch(batches)的成本)，同时需要在上传BatP z W g _ ~ O ^ Ech的同时支付一定的Matic到L1合约中，用于之后支付Aggren 0 2 = Rgator为这些Batches提供validity proof的成本。

Aggregator 在调用trustedVerifyBatches() 为L1合约内还没有被finality的BatP 9 2 dches提供validity proof的同时，也可以取出Sequen6 l Z ~cer提前支付在合约内的Mati! H I | rc代币，作为提供validity proof的报酬。

Sequencer的收入如下:

• 收入 = Rollup所有交易的Gas费用 – 将Batches上g g y 6 ] \传到L1花费& 3 { x的L1网络Gas费P v _ w Y , i –用 – 支付给AJ F z # dggregator的证明费用(Matic计价)

Aggregator的收入如下

• 收入 = SeqC , B ~ ; /uencer支付的MatiP Y x z B R ec报酬 &#8B s M f m211; 提交到validity proof到L1的Gas费用 – validity proof生成花费的硬件费用H V U | & F g = .

调整支付给Aggregator的证明费用

同时为了避免SeJ ; ] _ A E m z mquencer因为无利可图罢工，提供了以下的机制来调整Sequencer支付给Aggregator 的证明费用。

合约中存在这样一个方法用来调整为batch提供证明的费用:

function _updateBatchFee(uint64 ne5 D ^wLastVerifiedBatch) inter2 h f % O l ; 3 {nal

它会更改合约中一个名为batchFee的变量，而这个变量决定了e q g = 7 *Sequencer为每个Batch支付的Matic代币数量。

更改机制如下:

合约中维护了这样一个变量veryBatchTimeTarget ，代表每个Batch被Sequencer提交到L1之后期望在这个时间内被验证状态。

合约内会记录所有超过了veryBatchTimeTarget 之后还没有被验证状态的Batche6 M ^ % F [ ) Z `s, 并且将这些batches的总数量记为 diffBatches 。

于是当有batches迟到的时候，会用以下公式来调整batchFx t x 3 L 4 ]ee:

• multiplierBatchFee 是一个被限制在1000~1024范围的数，可以通过函数setMultiplierBatchFee() 由合约E } N j 8 $管理员更改
• function setMultiplierBatchFee(uint16 newMultiplierBatchFee) public onlyAdmin

需要注意这里的 采用multiplierBatchFee 和10^3是为~ o $ f了实现3个小数点后的调整精度

同理假如Batches提前了也会触发相应的batchFee调整机制:

• diffBatches 表示提前验8 + { V y证状态的Batches的数量

未完待续1 * R =…

欢迎大家关注我的推特 0xhhh，po& _ D R ; 5lygon zkEVM的下一篇文章也会继续在twitter发布。