3 月27 日，Polygon zkEVM 主網測試版本正式上線，Vitalik 在上面完成了第一筆交易。
本文是Polygon zkEVM 系列文章的第一篇，簡要闡述了Polygon zkEVM 的整體架構和交易執行流程，並且分析了Polygon zkEVM 是如何實現計算擴容並同時繼承以太坊的安全性的。
同時還會在接下來兩篇文章裡詳細介紹Polygon zkEVM 的zkEVM Bridge 和zkEVM 的設計細節，以及Polygon zkEVM 接下來的去中心化Sequencer 的路線圖。
一、Rollup 為了給以太坊實現計算擴容
首先，我們需要明確Rollup 的大概工作原理。Rollup 的出現是為了給Ethereum 實現計算擴容，具體的實現方法是將交易的執行外包給Rollup，然後將交易和交易執行後的狀態(State) 存儲在Ethereum 的合約內，由於技術路線的不同演變出了兩種類型的Rollup：
樂觀匯總
樂觀的認為發送到Ethereum 的Rollup 交易(Rollup Transaction) 和對應的Rollup 狀態(Rollup State ) 都是正確的，任何人都可以通過提供欺詐證明(Fraud Proof) 對還處於挑戰期的Rollup State 進行挑戰(Challenge)。
零知識匯總
ZK 會為發送到Ethereum 的Rollup 交易和對應的Rollup 狀態提供一個有效性證明( 由以太坊上的合約驗證，來證明Rollup 的執行對應交易後的狀態是正確的) 。
參考以太坊官方定義：
Zero-knowledge Rollup 和Optimistic Rollup 最大的區別就是由於驗證狀態有效性的不同方式導致達成Finality 的時間不同；
Optimistic Rollup 樂觀的認為提交到Ethereum 上的交易和狀態都是正確的，所以存在7 天的挑戰期（達成Finality 的時間是7 天），期間任何人發現在Ethereum 上的交易對應狀態不正確都可以通過提交正確的狀態進行挑戰。
Zero-knowledge Rollup( zk-Rollup ) 達成Finality 的時間，則取決於：交易對應的有效性證明( Validity Proof ) 提交到以太坊並且驗證通過所花費的時間。目前可能在1 個小時左右的Finality 居多( 因為需要考慮到Gas 成本問題) 。
二、Polygon zkEVM 執行流程
接下來我們以一個簡單的交易被確認流程來看看Polygon zkEVM 是怎麼工作的，從而對整體協議有一個具體的理解，它的整個過程可以主要分為三個步驟:
1. Sequencer 將多個用戶交易打包成Batch 提交到L1 的合約上；
2. Prover 為每筆交易生成有效性證明(Validity Proof)，並將多個交易的有效性證明聚合成一個有效性證明；
3. Aggregator 提交聚合了多個交易的有效性證明(Validity Proof) 到L1 的合約中。
1. Sequencer 將用戶交易打包成Batch 提交到L1 合約上
1) 用戶將交易發送給Sequencer，Sequencer 會在本地按照收到交易的快慢順序進行處理(FRFS)，當Sequencer 在本地將交易執行成功後，如果用戶相信Sequencer 是誠實的，那麼他可以認為這個時候的交易已經達成了Finality。這裡需要注意，目前大多數Sequencer 內部的Mempool( 交易池) 都是私有的，所以暫時可以獲取的MEV 是比較少的。
2) Sequencer 會將多筆交易打包進一個Batch 裡( 目前是一個Batch 裡只包含一個交易) 然後在收集到多個Batches 之後, 通過L1 上的PolygonZKEvm.sol 的SequenceBatch() 函數將多個Batches 一起送到L1 的交易Calldata 上。
( 需要注意這裡一次性提交多個Batches 是為了盡可能減少L1 的Gas 消耗 )
3) 當 PolygonZkEvm.sol 收到Sequencer 提供的Batches 後，它會依次在合約內計算每個Batch 的哈希，然後在後一個Batch 裡記錄前一個Batch 的哈希，於是我們就得到了下圖的Batch 結構。
4) 每個Batch 裡的交易順序也是確定的，所以當Batch 的順序確定之後，我們認為所有被包含在Batch 提交到L1 的Polygon zkEVM 合約的交易的順序都被確定了。
以上實際過程也是L1 充當Rollup DA 層需要完成的工作( 這個時候並沒有完成任何狀態檢驗或推進的工作)。
2. Aggregator 為多個Batch 的交易生成Validity Proof
1) 當Aggregator 監聽到L1 的PolyonZKEVM.sol 合約中已經有新的Batch 被成功的提交之後，它會把這些Batch 同步到自己的節點裡，然後給zkProver 發送這些交易。
2) zkProver 接收到這些交易之後會並行為每筆交易生成Validity Proof，再將多個Batch 包含的交易的Validity Proof 再聚合成一個有效性證明(Validity Proof)。
3) zkProver 將聚合多個交易的Validity Proof 發送給Aggregator。
3. Aggregator 提交聚合證明到L1 的合約
Aggregator 會將這個有效性證明(Validity Proof) 以及對應的這些Batch 執行後的狀態一起提交到L1 的 Polygon zkEvm.sol 合約內，通過調用以下方法：
合約內接下來會執行以下操作來驗證狀態轉換是否正確。
當這一步在L1 合約內執行成功時，這部分batch 包含的所有交易也就真正達成了Finality（對應OP 的7 天挑戰期結束）。
三、 Ethereum 在Polygon-zkEVM 中充當的角色
上文我們已經了解了Polygon zkEVM 的整體流程, 可以回顧下Ethereum 為Rollup 做了哪些工作:
第一步，Sequencer 將Rollup 的交易收集起來打包成Batch 之後，提交到L1 的合約中。L1 不僅 僅提供了DA 層的功能，實際上還完成了一部分交易排序的功能；當你把交易提交到Sequencer 時，交易是沒有真正被定序的，因為Sequencer 有權力可以隨便 改變交易的順序，但是當交易被包含在Batch 裡提交到L1 合約上之後，任何人都沒有權利再修改其中的交易順序。
第二步，Aggregator 將Validity Proof 提到L1 合約上來達成新的狀態, Aggregator 則是類似Proposer 的角色，合約則類似Validator 的角色；Aggregator 提供了一個Validity Proof 來證明一個新的狀態是正確的，並告訴Validator 我提供的Validity Proof 涉及 哪些交易Batch，他們都存在了L1 的哪個位置。
接著Validator 從合約中提取對應的Batch，與Validity Proof 結合在一起就可以驗證狀態轉換的合法性了，如果驗證成功實際上合約內也會更新到對應Validity Proof 的新狀態。
四、從模塊化的角度結構Smart Contract Rollup
如果從模塊化的角度來看，Polygon zkEVM 屬於Smart Contract Rollup 類型，我們可以嘗試解構下它的各個模塊， 從Delphi 給的圖中， 我們也可以看出實際上Polygon ZkEVM 作為Smart Contrat Rollup 的Consensus Layer，DA Layer 和Settlement Layer 其實都是耦合在PolygonZkEVM.sol 合約中，並不能很好的區分。但是我們嘗試著去解構各個模塊:
- 數據可用層(Data Availability Layer): Rollup 交易存放的地方，對於Polygon-zkEVM 來說 ，當Sequencer 調用 SequenceBatch () 方法的時候，實際上就包含了往DA 層提交交易數據。
- 結算層(Settlement Layer):具體指的是Rollup 和L1 之間的資金流動機制， 具體指的是Polygon-zkEVM 的官方橋( 在下一篇文章會有詳細介紹)。
- 共識層(Consensus Layer):包含交易排序和如何確定下一個合法狀態( 分叉選擇)，Sequencer 調用L1 合約中的 SequenceBatch() 的時候完成了交易排序的工作，當Aggregator 調用L1 合約中的 TustedVerifyBatches () 的時候完成了確認下一個合法狀態的工作。
- 執行層(Execution Layer):執行交易並且得到新的世界狀態， 當用戶向Sequencer 提交交易，並且Sequencer 執行完之後得到新狀態的過程( 所以我們往往說Rollup 是計算擴容，因為L1 把執行交易得出新狀態的這個過程外包給了Rollup， 同時 Sequencer 會通過Aggregator 委託zkProver 幫忙生成Validity Proof。
五、為什麼說Polygon-zkEVM 繼承了L1 的安全性
從上面介紹的整體流程上看，實際上Sequencer 做了類似以太坊Proposer 的工作，提議了一批交易是有效交易，並且給出了這批交易執行後的新狀態；而L1 合約的驗證邏輯，相當於所有L1 的Validator 都會在自己的以太坊客戶端裡執行一遍，實際上是所有的以太坊驗證者充當了Rollup 的驗證者，因此我們認為Polygon zkEVM 繼承了以太坊的安全性。
從另外一個角度上看，因為Rollup 的所有交易以及狀態都存儲在以太坊上，所以即便Polygon zkEVM 這個團隊跑路了，任何人都還是有能力依託以太坊上存儲的數據，恢復整個Rollup 網絡。
六、Polygon zkEVM 激勵機制
Rollup 激勵機制主要指的是如何讓Sequencer 和Aggregator 有利可圖，從而保持持續性的工作的？
首先用戶需要支付自己在Rollup 上的交易手續費，這部分的手續費是採用ETH 計價的，用Bridged ETH 支付。
Sequencer 則需要支付這些包含Rollup 交易的Batch 上傳到L1 交易的Calldata 上的成本( 調用SequenceBatch(batches() 的成本)，同時需要在上傳Batch 的同時支付一定的Matic 到L1 合約中，用於之後支付Aggregator 為這些Batches 提供Validity Proof 的成本。
Aggregator 在調用trusted VerifyBatches 為L1 合約內還沒有被Finality 的Batches 提供Validity Proof 的同時，也可以取出Sequencer 提前支付在合約內的MATIC 代幣，作為提供Validity Proof 的報酬。
Sequencer 的收入= Rollup 所有交易的Gas 費用- 將Batches 上傳到L1 花費的L1 網絡Gas 費用- 支付給Aggregator 的證明費用(MATIC 計價)。
Aggregator 的收入= Sequencer 支付的MATIC 報酬 – 提交到Validity Proof 到L1 的Gas 費用- Validity Proof 生成花費的硬件費用。
調整支付給Aggregator 的證明費用，同時為了避免Sequencer 因為無利可圖罷工，提供了以下的機制來調整Sequencer 支付給Aggregator 的證明費用。
合約中存在這樣一個方法用來調整為Batch 提供證明的費用:
函數 _updateBatchFee(uint64 newLastVerifiedBatch) 內部
它會更改合約中一個名為BatchFee 的變量，而這個變量決定了Sequencer 為每個Batch 支付的MATIC 代幣數量。
更改機制如下:
合約中維護了這樣一個變量VeryBatchTimeTarget ，代表每個Batch 被Sequencer 提交到L1 之後期望在這個時間內被驗證狀態。
合約內會記錄所有超過了VeryBatchTimeTarget 之後還沒有被驗證狀態的Batches, 並且將這些Batches 的總數量記為DiffBatches 。
於是當有Batches 遲到的時候，會用以下公式來調整BatchFee:
MultiplierBatchFee 是一個被限制在1000~1024 範圍的數，可以通過函數setMultiplierBatchFee() 由合約管理員更改：
函數 setMultiplier BatchFee (uint16newMultiplierBatchFee) public onlyAdmin
需要注意這裡的採用MultiplierBatchFee 和10^3 是為了實現3 個小數點後的調整精度。
同理假如Batches 提前了也會觸發相應的batchFee 調整機制:DiffBatches 表示提前驗證狀態的Batches 的數量。
總結
在這篇文章裡我們梳理了Polygon zkEVM 的核心機制，並分析了它實現以太坊計算擴容的可行性。有了一個整體的大綱後，在接下來的文章裡我們會深入到協議內部，依次解析zkEVM Bridge 的設計細節以及Sequencer 的去中心化路線，zkProver 的實現以及zkEVM 的設計原理。
