Rollup Layer2的模塊化演進之路

本文嘗試從演化角度討論Rollup Layer 2 的發展以及演進，主要解答以下幾個問題：

• Rollup 是如何工作的

• Rollup 的模塊化演進

• 模塊化帶來的可能性

• 模塊化應用的技術趨勢

• 總結

Rollup 是如何工作的

區塊鏈的“三難問題”一直是困擾業界的一個難題，如果我們認為Layer 1 區塊鏈應該首先保證“去中心化”和“安全”，那將“擴展性”方案從Layer 1 遷移出來就是自然的選擇了，於是有了Layer 2 。那新的難題就是如何通過Layer 1 來保證Layer 2 的安全。

最初有一種想法是定時將Layer 2 應用的狀態樹根寫到Layer 1 ，這樣可以通過狀態證明來校驗應用的狀態，類似於交易所儲備金證明。但這種方式第三方無法通過公開的方式驗證兩次狀態轉換是正確的。

為了更深入的探討這個問題，我們抽像一下，任何程序的狀態都可以通過一個狀態轉換公式表達：

σt+ 1 ≡ Υ(σt, T)

這個公式來自於Ethereum 黃皮書，但它可以代表任意的程序。在這裡Υ 代表程序，σ 代表狀態。狀態σt+ 1 由程序Y 通過狀態σt 和交易T 計算得出。交易T 代表程序的輸入。任意時候，如果σt 是確定的，程序Y 是確定的，T 是確定的，那σt+ 1 就是確定的。

所以要提供公開的可驗證性，關鍵是Y 要公開可用，歷史上所有的T 要公開可用並且順序確定，中間的狀態可通過Y 和T 重新計算得到。而程序的公開可用我們可以通過開源來實現，關鍵是T 公開可用如何保證，這就引入了數據可用性（DA）的概念。

數據可用性需要有個公開的不可篡改的賬本來記錄應用的交易。自然想到，區塊鏈賬本就是這樣一個系統，於是將Layer 2 的交易寫回Layer 1 ，保證數據可用性，這也就是Rollup 名稱的來源。

所以Layer 2 系統中需要有個角色收集用戶的交易，進行排序並寫入到DA，這個角色叫 定序器（Sequencer）。這裡的交易序列叫 Canonical Transaction Chain。

保證了數據的可用性，每個人都可以通過自己運行程序執行交易來得到最終的狀態。但這裡並沒有達成共識，因為每個人不確定自己得到的結果是否和其他人的結果一致，畢竟軟件或者硬件故障也可能導致數據不一致。所以需要另外一個角色將交易執行後的狀態樹根定時公佈出來，供大家校驗自己的狀態，這個角色叫 提案者（Proposer）。這裡每次提交的狀態也構成了一個狀態序列，和交易序列對應，叫 State Commitment Chain。

到這裡，我們達到了應用的可驗證性。如果某個人運行的結果和Proposer 提交的狀態不一致，並確定不是自己的問題，那就是Proposer 作弊或者出錯了，那怎麼讓別人也知道呢？這就需要引入**仲裁者（Arbitrator）**的角色。仲裁者需要是一個可信第三方，鏈上合約正好可以承擔這個角色。

仲裁有兩個方案：

• Proposer 每次提交狀態的時候，同時提供與前一次狀態之間的狀態轉換有效證明（Validity Proof），鏈上的仲裁合約進行校驗。有效證明一般通過Zero knowledge 技術生成，這種叫ZK Rollup。

• 先假定Proposer 的結果是對的，但如果發現不一致，則提交欺詐證明（Fraud Proof），由仲裁合約進行判定。如果仲裁合約判定Proposer 作弊，則對Proposer 進行懲罰，並將State Commitment Chain 回滾到欺詐交易之前的狀態。當然，為了保證安全，一般會設置一個比較長的挑戰週期來達到鏈上交易結算的最終確定性。這種叫Optimistic Rollup。

我們還需要實現Layer 1 和Layer 2 之間的資產互通。於是構建一個Layer 1 到Layer 2 之間的橋，通過狀態證明來進行資產結算。而Layer 2 在Layer 1 的狀態根由Layer 1 的仲裁合約保證，我們可以認為這個橋的安全也受仲裁合約保證。

至此，我們得到了一個由Layer 1 保證安全，並且可以和Layer 1 進行資產互通的Rollup Layer 2 方案。

當然，Rollup 方案也做了一些妥協：

• 將交易寫入Layer 1 ，也就代表Layer 2 的擴展性依然受Layer 1 區塊大小限制。以Ethereum 為例，某個Layer 2 完全佔據Ethereum 的所有區塊，能提供的平均TPS 也才數百，擴展性受DA 限制。

• 為了節省Gas 費，Sequencer 會將交易批量寫入DA，而在寫入DA 之前，Sequencer 有可能通過調整交易的順序來作弊。

這裡總結一下Layer 2 的安全以及交易的最終確定性：

• 如果用戶自己運行了一個Layer 2 的節點，並且忠實地按照DA 的交易順序執行，用戶可以認為交易是即時確認並且達到最終確定的，因為如果用戶執行的結果和Proposer 不一樣，說明Proposer 作弊，需要回滾鏈上的狀態，最終會和用戶自己的節點執行的結果一樣。這裡主要的風險點在於前面提到的，如果實時從Sequencer 同步數據， Sequencer 調整尚未寫入DA 的交易的順序帶來的風險。

• 如果用戶自己無法運行節點，需要依賴一個RPC 提供方，用戶需要承擔一定的信任風險。但這個風險和用戶信任Layer 1 的RPC 節點帶來的風險類似。這裡額外的風險依然是Sequencer 丟棄交易或者重排交易帶來的風險。

• 如果Proposer 出錯，但沒有節點發起挑戰，超過了挑戰期，這時候錯誤的狀態無法回滾，只能通過社會共識硬分叉方式來修復狀態。

Rollup 的模塊化演進

根據前面的分析，Rollup 解決方案中，鏈上的多個合約承擔不同的職能，代表不同的模塊。那自然想到，能否將模塊拆分到多個鏈，從而獲得更高的擴展性。這就是模塊化區塊鏈以及模塊化Rollup 的思路。

模塊化在這裡有兩層含義：

• 通過模塊化設計，讓系統變為一個可拔插的系統。開發者可以通過模塊的組裝，滿足不同的應用場景需求。

• 基於1 提供的能力，模塊層的實現並不綁定在同一個Layer 1 上，從而得到更好的擴展性。

我們可以認為有三個主要的模塊層：

• 數據可用層（Data Availability）： 保證執行層的交易數據可以通過公開的方式獲取，以及保證交易的序列。

• 結算層（Settlement）：實現Layer 1 和Layer 2 之間的資產和狀態結算。它包含State Commitment Chain 和Bridge。

• 仲裁層（Arbitration）：校驗欺詐證明，並做出裁決（Optimistic）或者校驗有效證明（ZK）。仲裁層要有能力操控State Commitment Chain。

DA 模塊化

將DA 職能遷移出來，用一個獨立的解決方案，獲得的首要好處是Layer 2 的交易Gas 費至少降低一個數量級。

從安全方面來看，即便是DA 鏈的去中心化弱於Ethereum，但DA 層對安全的保證主要是挑戰期內的交易，過了挑戰期後，DA 主要是為了方便其他節點同步數據，對安全並沒有保障作用，所以去中心化的要求可以降低一個層次。

DA 專用鏈可以提供更高的存儲帶寬和更低的存儲成本，並且針對多個應用共享DA 進行專門的設計。這也是當前如Celestia、Polygon Avail 這樣的DA 鏈的立足點。

將DA 層拆分出去後，我們得到了下圖的架構：

上圖中由DA 來承擔保存Canonical Transaction Chain 的職責，而給Layer 1 留了一個L1 To L2 Transaction Queue 來實現Layer 1 和Layer 2 之間的消息通信，用戶也可以直接寫交易給這個Queue，確保Layer 2 的Permissionless，Sequencer 無法審核用戶或者交易。

但這裡會引入一個新的難題，如果Sequencer 寫入DA 的交易序列和Proposer 執行的交易序列不一致，仲裁合約如何判定？一種方案是DA 鍊和仲裁鏈之間有一個跨鏈橋，實現在仲裁合約中校驗DA 鏈提供的數據證明。但這種方案依賴DA 和其他鏈之間的跨鏈橋的實現，DA 的方案選型會受限制。另外一種方案是引入排序證明。

排序證明（Sequence Proof）

我們可以認為Sequencer 實際上也屬於DA 方案的一部分，它相當於一個App-Specific 的DA，主要基於以下理由：

• Sequencer 需要提供批量寫入DA 鏈之前這段時間內的DA 保證。

• Sequencer 需要負責交易的驗證，排序，以及最終寫入DA。

如果要求Sequencer 給每個交易生成一個Sequence Proof，則可以解決兩個問題：

• 對尚未寫入DA 鏈的交易提供了保證，使Sequencer 不敢隨意調整交易的順序或者丟棄交易。

• 如果DA 鍊和仲裁鏈之間沒有跨鏈橋，則可以通過Sequence Proof 的挑戰機制來保證數據可用。

Sequence Proof 具有以下特性：

• 它攜帶Sequencer 的簽名，證明它是某個Sequencer 發出的。

• 它可以證明某個交易在全部交易序列中的位置。

• 它是累加器（Accumulator）證明的一種。每個交易累加後會生成新的累加結果，與該交易之前所有歷史交易相關，使得其難以篡改。累加器的可選方案之一是默克爾累加器（Merkle Accumulator），累加結果表現為默克爾樹的根。

Sequence Proof 的工作原理：

用戶或者執行節點提交交易給Sequencer，Sequencer 將Sequence Proof 返回給用戶，同時同步給其他節點。如果Sequencer 在提交給DA 之前丟棄或者篡改了交易的順序，用戶或者其他節點可以提交Sequence Proof 給仲裁合約，從而懲罰Sequencer。仲裁合約需要從State Commitment Chain 合約中讀取交易累加器的根，從而校驗Sequence Proof。

分場景探討一下：

• Sequencer 丟棄或者重排了用戶交易。這會導致Sequencer 在同一個位置生成了兩個Sequence Proof。用戶提交Sequence Proof 給仲裁合約，Sequencer 需要提供該交易被包含在最新的交易累加器的根中的證明，如果不能給出，則懲罰Sequencer。

• Sequencer 沒有正確地將交易寫入DA 鏈，和Proposer 合謀隱藏交易。如果仲裁鍊和DA 鏈有橋，則通過橋來驗證，懲罰Sequencer。否則用戶可以發起挑戰，要求Sequencer 給出某個位置的交易的證明以及原始信息。但這種情況仲裁合約無法判斷用戶是否是惡意挑戰，所以如果Sequencer 給出數據則不懲罰Sequencer。而對用戶來說，惡意挑戰損人損己，也缺少經濟動力。

我們通過引入Sequence Proof 讓Layer 2 的協議變得更安全。

交易流水線（Transaction Pipeline）以及並行執行（Parallel Execution）

將Sequencer 劃分給DA，只負責交易的驗證和排序，帶來的另外一個好處是容易實現交易的流水線以及並行執行。

驗證交易時，需要驗證簽名和是否有足夠的Gas 費，而Gas 費的校驗需要依賴狀態。如果我們為了保證驗證交易不會被執行交易阻塞，允許Sequencer 驗證交易依賴的狀態和最新狀態之間有一定的延遲（秒級），會導致Gas 校驗會不太準確，有被DDoS 攻擊的風險。

但我們認為Sequencer 屬於DA 是一個正確的方向，所以值得我們進一步研究。比如可以將交易費中DA 部分拆分出來，通過UTXO（Sui Move Object） 表達，則可以降低Gas 費檢測成本。

Sequencer 給交易排序然後輸出成交易流水線，然後同步給Proposer 以及其他節點。每個節點可以根據自己的服務器情況來選擇並行方案。每個節點需要保證：只並行沒有因果關係的交易，有因果關係的交易必須按Sequencer 的順序執行，那最終的結果就是一致的。

Proposer 需要定時提交狀態樹的根，以及累加器的根到鏈上的State Commitment Chain 合約中。

於是我們得到了一個低Gas 費，高TPS，並且更安全的模塊化Layer 2 ： Rooch。

• MoveOS：它包含MoveVM 以及StateDB，是系統的執行以及狀態存儲引擎。 StateDB 由兩層稀疏默克爾樹構建，可以提供狀態證明。根據前面的分析可得出，狀態樹以及狀態證明是Rollup 應用不可或缺的組件。

• RPC：對外提供查詢，提交交易，以及訂閱服務。可以通過代理方式兼容其他鏈的RPC 接口。

• Sequencer：驗證交易，給交易排序，提供Sequence Proof，將交易流式輸出到Transaction Pipeline。

• Proposer：從Transaction Pipeline 獲取交易，批量執行，定期提交到鏈上的State Commitment Chain。

• Challenger：從Transaction Pipeline 獲取交易，批量執行，和State Commitment Chain 比較，決定是否發起挑戰。

• DA & Settlement & Arbitration Interface：對不同的模塊層的抽象和封裝，保證在不同的實現之間切換時不影響上層業務邏輯。

支持多鏈的交互式欺詐證明

Optimistic Rollup 方案中，鏈上的仲裁合約如何判定鏈下的交易執行出錯，一直是一個難題。最初的想法是Layer 1 上重新執行一遍Layer 2 的交易，但這種方案的難題是Layer 1 的合約要模擬Layer 2 的交易執行，成本很高，也會限制Layer 2 交易的複雜度。

最後業界摸索出一種交互式證明的方案。因為任何復雜的交易，最終會轉換成機器指令執行，如果我們找到產生分歧的指令，則只需要在鏈上模擬執行指令即可。

還用上面那個狀態轉換公式：

σt+ 1 ≡ Υ(σt, T)

這裡Υ 代表指令，T 代表指令輸入，σ 代表指令所依賴的內存狀態。如果在執行過程中，給每個σ 都生成一個狀態證明。控辯雙方可以通過交互，發現雙方的分歧點m，將m-1 的狀態σ 以及指令m 提交到鏈上仲裁合約模擬執行，仲裁合約執行後就可以給出判定。

所以剩下的問題就是通過什麼方式來生成證明，主要有兩個方案：

• 直接在合約語言虛擬機中實現，比如Arbitrum 的AVM，Fuel 的FuelVM。

• 基於已有的指令集實現一個模擬器，在模擬器中提供證明能力。如Optimism 的基於MIPS 指令的cannon，Arbitrum 新的基於WASM 指令的Nitro，以及Rooch 的基於MIPS 指令的OMO。

OMO 是一個擁有單步狀態證明能力的通用字節碼模擬器，為多鏈執行環境設計。有了OMO 的支持，可以實現仲裁層的模塊化。任意支持圖靈完備合約的鏈，都可以在合約中模擬OMO 的指令，作為仲裁層。

ZK + Optimistic 組合方案

業界一直在爭論Optimistic Rollup 和ZK Rollup 孰優孰劣，但我們認為將二者結合起來可以兼得兩種方案的優點。

在前面的Optimistic 方案基礎上，我們再引入一個新的角色，ZK Prover。它批量給Proposer 提交的交易狀態生成有效證明，並提交給仲裁合約。仲裁合約驗證後，就可以判定該交易在Layer 1 上達到了最終確定性，可以進行Layer 2 到Layer 1 的提款交易的結算。

這種方案的優點：

• 不會因為ZK 的性能問題限制Layer 2 的整體吞吐。

• 可以通過ZK 縮短Optimistic 的挑戰週期，提升用戶體驗。

在ZK 的方案以及硬件加速成熟之前，我們可以先通過Optimistic 構建生態，同時模塊化方案可以讓ZK 最後無縫接入進來。

多鏈結算

如果我們進一步思考模塊化的趨勢，自然想到，既然DA 可以遷移到別的鏈，那結算層是否也可以部署到別的鏈？

Layer 1 和Layer 2 之間的資產結算主要依賴兩個組件，一個是Bridge，一個是State Commitment Chain，從Bridge 結算的時候，需要依賴State Commitment Chain 校驗Layer 2 的狀態證明。 Bridge 當然可以部署到多個鏈，但State Commitment Chain 只能有一個權威的版本，由仲裁合約保證安全。

這個方向還需要深入研究，但有個初步的方案。其他鏈上的State Commitment Chain 都是仲裁鏈（Ethereum）上的鏡像。這個鏡像並不需要同步全部的Layer 2 State Root 到其他鏈，而是用戶按需通過Ethereum 的狀態證明做映射。

當然，其他鏈上還需要能校驗Ethereum 上的狀態證明，所以需要知道Ethereum 上的狀態根。當前，將Ethereum 上的狀態根同步到其他節點有兩個方案： 1. 依賴Oracle。 2. 嵌入Ethereum 輕節點，校驗Ethereum 的區塊頭。

這樣我們就可以得到一個支持多鏈結算，但安全由Ethereum 保證的Layer 2 方案。

這種方案和跨鏈的區別：

• 如果是依賴中繼鏈的跨鏈方案，可以認為Layer 2 替代了中繼鏈，是一個安全受仲裁合約保證的中繼層。

• 如果是鏈間互相校驗狀態證明的跨鏈方案，多鏈結算方案和它共享狀態根同步的技術方案，但簡化了許多。因為在多鏈結算方案中，狀態根的同步需求是單向的，只需要從仲裁鏈同步到其他鏈，不是兩兩互相同步。

模塊化帶來的可能性

通過模塊化，開發者可以通過Rooch 組合出不同的應用。

• Rooch Ethereum Layer 2 = Rooch + Ethereum(Settlement+Arbitration) + DA
  這是Rooch 首先要運行的網絡。提供一個由Ethereum 安全保證的，可以和Ethereum 上的資產互通的Move 運行平台。未來可以擴展到多鏈結算。

• Rooch Layer 3 Rollup DApp = Rooch + DApp Move Contract + Rooch Ethereum Layer 2(Settlement + Arbitration) + DA 如果應用把自己的結算和仲裁部署到Rooch Layer 2 ，它就是一個Rooch 的Layer 3 應用。

• XChain Rollup DApp = Rooch + DApp Move Contract + XChain(Settlement + Arbitration) + DA 任意鏈都可以通過Rooch 來給開發者提供一套基於Move 語言的Rollup DApp 工具包。開發者只需要通過Move 語言編寫自己的應用邏輯，就可以運行一個安全受XChain 保障的，資產可以和XChain 互通的，獨立環境的Rollup 應用。當然這個需要和各公鏈的開發者來協同開發。

• Sovereign Rollup DApp = Rooch + DApp Move Contract + DA 應用也可以將Rooch 作為Sovereign Rollup SDK，不部署Bridge 以及Arbitration 合約，State Commitment Chain 也保存在DA，保證可驗證性，由社會共識保證安全。

• Arweave SCP DApp = Rooch + DApp Move Contract + DA（Arweave） SCP 和Sovereign Rollup 思路類似，SCP 要求應用程序的代碼也要保存到DA。而Rooch 中合約部署和升級都是交易，合約代碼在交易中，都會寫到DA 層，所以我們認為符合SCP 的標準。

• Move DApp Chain = Cosmos SDK + MoveOS + DApp Move Contract MoveOS 可以作為一個獨立的Move 運行環境嵌入到任意的鏈的運行環境中，去構建應用鍊或者新的公鏈。

• 非區塊鏈項目非區塊鏈項目，可以把MoveOS 作為一個可以帶有數據校驗能力以及存儲證明能力的數據庫使用。比如用它做一個本地的博客系統，數據結構和業務邏輯通過Move 表達。等未來基礎設施成熟，則可以直接和區塊鏈生態對接起來。再比如可以用它做雲計算中的FaaS 服務，開發者通過Move 編寫FaaS 中的Function，平台託管狀態，用戶間的Function 還可以互相組合調用。更多的可能性需要大家探索。

Rooch 的模塊化方案可以適應於不同類型以及階段的應用。比如開發者可以先通過部署合約在Rooch Ethereum Layer 2 上驗證自己的想法，等成長起來後，將應用遷移到獨立的基於Rooch 搭建的App-Specific Rollup 中。

再或者開發者直接通過Sovereign Rollup 方式啟動應用，因為應用早期對安全性要求不高，也沒有和其他鏈互通資產的需求，先做到可驗證。等應用成長起來，有了互通資產的需求，對安全性要求變高，這時候可以啟用結算以及仲裁模塊從而保證資產的安全。

模塊化應用的技術趨勢

DA 層潛力尚待挖掘

由前面的分析可以看出，無論哪種組合方式，都依賴DA。 DA 在去中心化應用中扮演的角色類似於Web2 系統的日誌平台，可以用來做審計，支持大數據分析，進行AI 訓練等。未來會有很多應用和服務圍繞DA 建立起來。當前已有Celestia，Polygoin avail，未來還會有EigenLayer，Ethereum danksharding 等。

根據前面的分析，我們得出Sequencer 的角色應該屬於DA 的一部分，如果DA 層能為應用提供交易校驗能力，並且有足夠的性能，實際上完全可以由DA 來承擔Sequencer 的職責，用戶直接寫交易到DA。當然能否使用應用的Token 付DA 的Gas 費是另外一個需要解決的問題。

DApp 編程語言會爆發

新的應用形態會促使新的編程語言爆發，這在Web2 時代已經驗證。而Move 會成為構建Web3 DApp 的最佳語言。除了Move 本身的語言特性外，還基於以下理由：

• DApp 用同一種語言可以快速積累應用所需要的基礎庫，形成生態聚集效應。所以一開始支持多語言不是個好策略。

• 去中心化應用至少要保證可驗證性，而智能合約語言可以讓開發者在保證可驗證性方面減少許多心智負擔。

• Move 的平台無關性，可以讓它很容易適配到不同的平台，不同的應用中。

• Move 的狀態是結構化的，有利於DApp 的數據結構表達以及存儲檢索。

總結

我在17 年底進入區塊鏈領域，當時業界有非常多的團隊嘗試在區塊鏈領域構建應用。可惜當時基礎設施尚不完備，業界尚未摸索出一個可複制的構建應用的模式，大多數應用類項目以失敗告終，打擊了開發者和投資者。區塊鏈上的應用應該如何構建出來？這個問題一直讓我思考了五年。

而現在，隨著Layer 1 ，Layer 2 以及智能合約，模塊化基礎設施的成熟，這個問題的答案也逐漸清晰起來。

希望在即將到來的Web3 DApp 爆發潮中， Rooch 可以助開發者一臂之力，讓應用更快的構建，真正的落地。

來源：星球日報