來源：Binary DAO
Author: 0xhhh（Twitter:@hhh69251498 ）
Editor:Red One
本文是Polygon zkEVM系列文章的第一篇，簡要闡述了Polygon zkEVM的整體架構和交易執行流程，並且分析了Polygon zkEVM是如何實現計算擴容並同時繼承以太坊的安全性的。
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：
Optimistic Rollup
樂觀的認為發送到Ethereum 的Rollup 交易(Rollup Transaction)和對應的Rollup 狀態(Rollup State )都是正確的，任何人都可以通過提供欺詐證明(Fraud Proof)對還處於挑戰期的Rollup State進行挑戰(Challenge)。
Zero-knowledge Rollup
ZK會為發送到Ethereum 的Rollup交易和對應的Rollup 狀態提供一個有效性證明(由以太坊上的合約驗證，來證明Rollup 的執行對應交易後的狀態是正確的)。
參考以太坊官方定義：
https://ethereum.org/en/developers/docs/scaling/#rollups
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提供證明的費用:
function _updateBatchFee(uint64 newLastVerifiedBatch) internal
它會更改合約中一個名為BatchFee的變量，而這個變量決定了Sequencer為每個Batch支付的MATIC代幣數量。
更改機制如下:
合約中維護了這樣一個變量VeryBatchTimeTarget ，代表每個Batch被Sequencer提交到L1之後期望在這個時間內被驗證狀態。
合約內會記錄所有超過了VeryBatchTimeTarget之後還沒有被驗證狀態的Batches, 並且將這些Batches的總數量記為DiffBatches。
於是當有Batches遲到的時候，會用以下公式來調整BatchFee:
MultiplierBatchFee 是一個被限制在1000~1024範圍的數，可以通過函數setMultiplierBatchFee() 由合約管理員更改：
FunctionsetMultiplier BatchFee(uint16newMultiplierBatchFee) public onlyAdmin
需要注意這裡的採用MultiplierBatchFee 和10^3是為了實現3個小數點後的調整精度。
同理假如Batches提前了也會觸發相應的batchFee調整機制:DiffBatches 表示提前驗證狀態的Batches的數量。
總結
在這篇文章裡我們梳理了Polygon zkEVM的核心機制，並分析了它實現以太坊計算擴容的可行性。有了一個整體的大綱後，在接下來的文章裡我們會深入到協議內部，依次解析zkEVM Bridge的設計細節以及Sequencer的去中心化路線，zkProver的實現以及zkEVM的設計原理。