zkEVM系列第一篇:Polygon zkEVM的整體架構和交易執行流程

來源: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上。

zkEVM系列第一篇:Polygon zkEVM的整體架構和交易執行流程

(需要注意這裡一次性提交多個Batches是為了盡可能減少L1的Gas消耗)

3) 當PolygonZkEvm.sol 收到Sequencer 提供的Batches 後,它會依次在合約內計算每個Batch的哈希,然後在後一個Batch裡記錄前一個Batch的哈希,於是我們就得到了下圖的Batch結構。

zkEVM系列第一篇:Polygon zkEVM的整體架構和交易執行流程

4) 每個Batch裡的交易順序也是確定的,所以當Batch的順序確定之後,我們認為所有被包含在Batch提交到L1的Polygon zkEVM合約的交易的順序都被確定了。

zkEVM系列第一篇: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)。

zkEVM系列第一篇:Polygon zkEVM的整體架構和交易執行流程

3) zkProver 將聚合多個交易的Validity Proof發送給Aggregator。

3. Aggregator 提交聚合證明到L1 的合約

Aggregator 會將這個有效性證明(Validity Proof)以及對應的這些Batch 執行後的狀態一起提交到L1 的Polygon zkEvm.sol 合約內,通過調用以下方法:

zkEVM系列第一篇:Polygon zkEVM的整體架構和交易執行流程

合約內接下來會執行以下操作來驗證狀態轉換是否正確。

zkEVM系列第一篇:Polygon zkEVM的整體架構和交易執行流程

zkEVM系列第一篇:Polygon zkEVM的整體架構和交易執行流程

當這一步在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的新狀態。

zkEVM系列第一篇:Polygon zkEVM的整體架構和交易執行流程

四、從模塊化的角度結構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。

zkEVM系列第一篇:Polygon zkEVM的整體架構和交易執行流程

五、為什麼說Polygon-zkEVM 繼承了L1的安全性

從上面介紹的整體流程上看,實際上Sequencer做了類似以太坊Proposer的工作,提議了一批交易是有效交易,並且給出了這批交易執行後的新狀態;而L1合約的驗證邏輯,相當於所有L1的Validator都會在自己的以太坊客戶端裡執行一遍,實際上是所有的以太坊驗證者充當了Rollup的驗證者,因此我們認為Polygon zkEVM 繼承了以太坊的安全性。

從另外一個角度上看,因為Rollup的所有交易以及狀態都存儲在以太坊上,所以即便Polygon zkEVM 這個團隊跑路了,任何人都還是有能力依託以太坊上存儲的數據,恢復整個Rollup網絡。

六、Polygon zkEVM 激勵機制

Rollup激勵機制主要指的是如何讓Sequencer和Aggregator有利可圖,從而保持持續性的工作的?

zkEVM系列第一篇:Polygon zkEVM的整體架構和交易執行流程

首先用戶需要支付自己在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個小數點後的調整精度。

zkEVM系列第一篇:Polygon zkEVM的整體架構和交易執行流程

zkEVM系列第一篇:Polygon zkEVM的整體架構和交易執行流程

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

zkEVM系列第一篇:Polygon zkEVM的整體架構和交易執行流程

zkEVM系列第一篇:Polygon zkEVM的整體架構和交易執行流程

總結

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

    Total
    0
    Shares
    Related Posts