首頁

Partnered With:

Polygon zkEVM的整體架構和交易執行流程

閱讀本文需 224 分鐘

簡要闡述Polygon zkEVM的整體架構和交易執行流程，並分析論述Polygon zkEVM是如何實現計算擴容並同時繼承以太坊的安全性的。

原文標題：《zkEVM 系列（1）｜Polygon zkEVM 的整體架構和交易執行流程》

原文作者：0xhhh，Binary DAO

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 的執行對應交易後的狀態是正確的) 。

參考以太坊官方定義

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 Token，作爲提供 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 Token數量。

更改機制如下:

合約中維護了這樣一個變量 VeryBatchTimeTarget ，代表每個 Batch 被 Sequencer 提交到 L1 之後期望在這個時間內被驗證狀態。

合約內會記錄所有超過了 VeryBatchTimeTarget 之後還沒有被驗證狀態的 Batches, 並且將這些 Batches 的總數量記爲 DiffBatches。

於是當有 Batches 遲到的時候，會用以下公式來調整 BatchFee:

MultiplierBatchFee 是一個被限制在 1000~1024 範圍的數，可以通過函數 setMultiplierBatchFee() 由合約管理員更改：

Function setMultiplier BatchFee (uint16newMultiplierBatchFee) public onlyAdmin

需要注意這裏的採用 MultiplierBatchFee 和 10^3 是爲了實現 3 個小數點後的調整精度。

同理假如 Batches 提前了也會觸發相應的 batchFee 調整機制:DiffBatches 表示提前驗證狀態的 Batches 的數量。

總結

在這篇文章裏我們梳理了 Polygon zkEVM 的核心機制，並分析了它實現以太坊計算擴容的可行性。有了一個整體的大綱後，在接下來的文章裏我們會深入到協議內部，依次解析 zkEVM Bridge 的設計細節以及 Sequencer 的去中心化路線，zkProver 的實現以及 zkEVM 的設計原理。