Rollup Layer2的模塊化演進之路_SEQ:LAYER

本文嘗試從演化角度討論RollupLayer?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公開可用如何保證，這就引入了數據可用性的概念。

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

所以Layer?2系統中需要有個角色收集用戶的交易，進行排序并寫入到DA，這個角色叫?定序器。這里的交易序列叫?CanonicalTransactionChain。

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

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

zkRollup生態項目Soveregin完成740萬美元種子輪融資，Haun Ventures領投:1月31日消息，基于zkRollups構建SDK的項目Soveregin完成740萬美元的種子基金，Haun Ventures領投，Maven 11、1KX、Robot Ventures和Plaintext Capital跟投。

據悉，Soveregin致力于構建開放、相互連接的rollup生態系統，使開發人員能夠部署可以在任何區塊鏈上運行的無縫互操作和可擴展的rollup，創建安全且可互操作的主權zk rollup的簡單框架。（CoinDesk）[2023/1/31 11:37:24]

仲裁有兩個方案：

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

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

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

至此，我們得到了一個由Layer?1保證安全，并且可以和Layer?1進行資產互通的RollupLayer?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丟棄交易或者重排交易帶來的風險。

ZK Rollup訂單簿式DEX ZigZag將于6月24日開啟ID0:6月21日消息，據官方消息，ZK Rollup訂單簿式DEX ZigZag將于6月24日23時在自身DEX上開啟ID0，第一輪公開發售將允許用戶在早期階段成為DAO的一部分，擁有對Token用例的投票權，同時決定空投的詳細信息。

ZigZag總量共計1億枚，本次ID0供應量為200萬枚，僅支持USDC支付。目前，由于基礎設施限制，ZigZag將僅在zkSync上提供現貨交易。在zkSync2.0和StarkNet發布后，將引入杠桿交易和無需許可上市的永續合約。

金色財經此前報道，6月20日，ZK Rollup訂單簿式DEX ZigZag疑似已在以太坊上部署Token ZZ的智能合約，總量1億枚。[2022/6/21 4:41:02]

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

Rollup的模塊化演進

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

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

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

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

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

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

結算層：實現Layer?1和Layer?2之間的資產和狀態結算。它包含StateCommitmentChain和Bridge。

仲裁層：校驗欺詐證明，并做出裁決或者校驗有效證明。仲裁層要有能力操控StateCommitmentChain。

DA模塊化

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

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

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

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

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

V神發文：使用calldata擴展和分片擴展Rollups的分步路線圖:11月26日消息，V神發布了關于“使用calldata擴展和分片擴展Rollups的分步路線圖”。在此文中，V神表示L1上的交易費用一直非常高，因此采取任何必要措施來幫助促進整個生態系統向Rollups的轉變變得更加緊迫。Rollup已經顯著降低了許多以太坊用戶的費用：l2fees.info顯示Optimism和Arbitrum提供的費用比以太坊基礎層本身低約3-8倍，然而，即使是這些費用對許多用戶來說也太貴了。V神提出了4步，第一步：txcalldata擴展，第二步：一些分片，第三步：N個分片并且受委員會保護，第四步：數據可用性抽樣。但是這留下了一個問題：如果以太坊核心協議不存儲這些數據，誰來存儲？V神提出了幾個可能：個人和機構；區塊瀏覽器；RollupDAO,客戶端；門戶網絡；像TheGraph一樣的協議。其中一些解決方案（個人和機構志愿者、區塊瀏覽器）已經可用。[2021/11/26 7:11:58]

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

排序證明

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

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

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

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

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

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

SequenceProof?具有以下特性：

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

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

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

SequenceProof的工作原理：

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

BM：EOS也可部署zksync rollup:9月16日，EOS創始人BM（DanielLarimer）轉發V神“已利用zkSync新資助13個項目”的推特并表示，這很好，但是嘗試將其與像Bancor這樣的DeFi交換器一起使用，并觀察狀態沖突將吞吐量降低到每個塊一個事務，客戶端必須不斷重新生成證明并簽署新的TRX。有人問EOS是否支持zksyncrollup，BM回應稱，EOS也可部署zksyncrollup。[2020/9/17]

分場景探討一下：

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

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

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

交易流水線以及并行執行

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

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

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

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

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

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

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

CFTC要求對加密騙局Control-Finance負責人處以4.29億美元民事罰款:據此前報道，美國商品期貨交易委員會（CFTC）提交了一份針對Benjamin Reynolds的擬議缺席判決，Reynolds是欺詐性加密貨幣計劃Control-Finance的唯一負責人和所有人。這份文件于2020年8月20日提交給紐約南部地區法院，CFTC解釋說，Reynolds未能出席或回答CFTC的申訴。

根據擬議的缺席判決，Reynolds必須支付142986589美元的賠償金。此外，他還必須支付4.29億美元的民事罰款。（Financefeeds）[2020/8/21]

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

Sequencer：驗證交易，給交易排序，提供SequenceProof，將交易流式輸出到TransactionPipeline。

Proposer：從TransactionPipeline獲取交易，批量執行，定期提交到鏈上的StateCommitmentChain。

Challenger：從TransactionPipeline獲取交易，批量執行，和StateCommitmentChain比較，決定是否發起挑戰。

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

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

OptimisticRollup方案中，鏈上的仲裁合約如何判定鏈下的交易執行出錯，一直是一個難題。最初的想法是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組合方案

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

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

這種方案的優點：

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

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

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

多鏈結算

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

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

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

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

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

這種方案和跨鏈的區別：

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

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

模塊化帶來的可能性

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

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

RoochLayer?3RollupDApp?=Rooch+DAppMoveContract+RoochEthereumLayer?2(Settlement+Arbitration)+DA如果應用把自己的結算和仲裁部署到RoochLayer?2?，它就是一個Rooch的Layer?3應用。

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

SovereignRollupDApp?=Rooch+DAppMoveContract+DA應用也可以將Rooch作為SovereignRollupSDK，不部署Bridge以及Arbitration合約，StateCommitmentChain也保存在DA，保證可驗證性，由社會共識保證安全。

ArweaveSCPDApp?=Rooch+DAppMoveContract+DASCP和SovereignRollup思路類似，SCP要求應用程序的代碼也要保存到DA。而Rooch中合約部署和升級都是交易，合約代碼在交易中，都會寫到DA層，所以我們認為符合SCP的標準。

MoveDAppChain?=CosmosSDK+MoveOS+DAppMoveContractMoveOS可以作為一個獨立的Move運行環境嵌入到任意的鏈的運行環境中，去構建應用鏈或者新的公鏈。

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

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

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

模塊化應用的技術趨勢

DA層潛力尚待挖掘

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

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

DApp編程語言會爆發

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

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

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

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

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

總結

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

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

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

Tags：LAYERNCESequenceSEQLayer3AmbitFinance

XRP