技術解讀Chainway：比特幣Layer2項目是怎么蹭概念的

作者：Shew & Faust，極客web3，顧問：Kevin He, BitVM 中文社區發起人，ex Web3 Tech Head@Huobi

目前的比特幣Layer2賽道可謂百花齊放，各種不同的技術方案扎堆聚集在了BTC生態這個大熔爐之中。由於區塊鏈領域迭代速度快，專業詞匯或者標准，都是在研究創新和工程落地過程中不斷變化的。在這樣的背景下，很多項目會採用「造概念」/「蹭概念」的方式獲取差異化和關注度，已然成爲業內潛規則。

比如，許多原本活躍於以太坊/Celestia生態的模塊化區塊鏈項目，也乘着東風之便，搭上了“比特幣Layer2”的快車，並自封爲“Rollup”，但其技術方案往往不符合Rollup的標准。

但是，“Rollup”這樣的詞匯具有較高的被認可度，打着“Rollup”旗號更利於宣傳。許多項目方要么是硬蹭（自封爲Rollup），要么是分叉主流的Rollup概念（加個曖昧的定語，比如主權Rollup）。

但扒开其“XX Rollup”的外衣一看，很多項目的工作原理，還是單純的“客戶端驗證”或“側鏈”，只是在借着“XX Rollup”的宣傳口號給自己牟方便。這種宣傳方式雖然比較普遍，但往往帶有誤導性，對於追求真相的廣大群衆而言，帶來的壞處要多於益處。

（納粹宣傳部長戈培爾對“撒謊式宣傳”的總結，這種做法在很多項目方身上屢見不鮮）

那我們該如何鑑別此類“蹭Rollup概念”的行爲呢？

或許，從第一性原理出發，根據西方乃至業界廣泛認可的標准，來定義不同Layer2項目的方案類別與安全程度，以及功能完備性，才能讓我們开啓霧裏看花時的那雙“萬花筒寫輪眼”。或者說，採用什么方案不是最重要的，核心在於項目在機制設計上，能否確保Layer2網絡安全可靠，能否真正意義賦能BTC主網。

下面，我們打算以Chainway這個老外做的比特幣Layer2爲案例，剖析部分項目在“Rollup”宣傳口號背後，隱藏着的“客戶端驗證”本質。我們可以更清晰的看穿，"主權Rollup"和"客戶端驗證"，與業界主流意義上的ZKRollup，或OPRollup等依賴於智能合約實現的Rollup方案的明顯差異。

當然，這並不是說，主權Rollup或客戶端驗證就不如ZK Rollup安全可靠，一切都要看其具體的細節實現。Chainway雖然是典型的客戶端驗證型Layer2，但其提出了“在BTC觸發+在鏈下驗證”的抗審查交易方案，並採用了類似於MINA公鏈的遞歸ZK Proof，領先於多數比特幣Layer2。

我們認爲，對Chainway的技術調研是比較有價值的，這對於廣大比特幣Layer2觀察者具有重要的參考意義。

（Chainway的宣傳圖片，將自己標榜爲ZK Rollup，但其真實方案是客戶端驗證，目前其尚未實現 鏈下客戶端間的共識，或可靠的訊息交換）

正文：Chainway是一個在西方社區比較有名的比特幣Layer2項目，許多KOL在宣傳時，直接稱其爲“ZK Rollup”，而在其技術文檔中，Chainway又自我定位成“主權Rollup”。近期Chainway還公布了其新項目Citrea，自稱是基於BitVM的ZK Rollup。由於Citrea尚未詳細說明其基於BitVM的ZK驗證方案如何實現，本文將重點放在Chainway已有方案的技術解讀。

我們可以用一句話概括Chainway現已公开的技術方案: 通過Ordinals協議發布DA數據，將BTC作爲其DA層，在Layer1發布狀態變化細節State diff + 證明狀態變化正確性的ZK Proof，效果等價於發布完整的、可驗證的交易數據。

（State diff 就是账戶狀態的變化量）

但由於Layer1不直接驗證ZK Proof，驗證工作由鏈下的獨立客戶端/節點進行，且Chainway目前的代碼庫，並未在鏈下獨立客戶端之間實現共識，官方也沒有在社交媒體上宣稱解決這個問題。所以，目前Chainway公布的技術方案，本質上屬於“客戶端驗證”類型，甚至更像一個支持橋接資產的銘文索引協議。

下文將主要介紹Chainway的具體技術實現，並分析其安全模型。

何謂主權Rollup：DA層發布數據 + 鏈下驗證

在Chainway的技術文檔中，用到了Celestia的主權Rollup(sovereign rollup)概念。而主權Rollup實際上與以太坊社區乃至業界主流的Rollup概念（智能合約Rollup）有天壤之別。那么主權Rollup的具體構造是怎樣的呢？

其實基於比特幣的主權Rollup有點類似於——“在BTC鏈上發布DA數據 的 鏈下客戶端群體/側鏈”，其最大特點在於，不需要Layer1上的智能合約對Layer2的狀態轉換/跨鏈行爲做驗證，本質上只是把BTC作爲DA層，安全模型與“客戶端驗證”(client side validation)很大程度上接近。

當然，一些安全性高些的主權Rollup方案，會依賴於BTC鏈下的第三方結算層（類似於側鏈）來完成狀態轉換驗證，且不同的獨立客戶端/全節點之間，存在一層共識或是可靠的消息傳遞，以此來對某些有爭議的行爲達成“一致”。但有些主權Rollup項目卻是赤裸裸的“客戶端驗證”，獨立客戶端/節點之間沒有什么可靠的消息傳遞。

爲了更好的理解“主權Rollup”這個獨特的概念，我們可以把主權Rollup與其對應的智能合約Rollup相比較。以太坊上的Layer2基本都是智能合約Rollup，如Arbitrum和StarkNet等。智能合約Rollup的結構可以參考下圖:

在上圖中，我們可以看到模塊化區塊鏈敘事的幾個術語，解釋如下:

Execution執行層: 執行用戶交易，更新區塊鏈狀態，向DA層和結算層提交數據

Settlement結算層: 驗證執行層的狀態轉換，解決爭議(如欺詐證明），並提供橋模塊來處理L1-L2橋接資產

DA層: 一個大號公告板，接收執行層提交的狀態轉換數據，把這些數據去信任的提供給任何人

Consensus共識層: 確保交易排序的最終性，與DA層的職能似乎比較接近（以太坊社區對模塊化區塊鏈的分層方式，不包含共識層）

從智能合約Rollup的架構中，我們看到除了執行層外，其他三層的職能都由以太坊承擔。下圖更詳細的展示了以太坊在智能合約Rollup中承擔的角色。

以太坊上的Rollup合約會接收 validity proof(有效性證明) 或者 fraud proof(欺詐證明) ，以此驗證Layer2狀態轉換的有效性。值得一提的是，此處的Rollup智能合約實際上就是模塊化區塊鏈中的結算層實體。結算層合約往往會包含橋接模塊，用於處理以太坊橋接到Layer2的資產。

而對於DA，結算層合約可以強制要求排序器Sequencer 把最新的交易數據/狀態變化細節上鏈，如果不把DA上鏈，就無法順利更新Rollup合約上記錄的L2狀態。

（ZK Rollup或OP Rollup，可以強制要求DA數據上鏈，不上鏈就無法更新結算層記錄的狀態）

我們可以看出，智能合約Rollup嚴重依賴於Layer1上的智能合約，對於BTC這種難以支持復雜業務邏輯的Layer1而言，基本無法構造出向以太坊Rollup“對齊”的Layer2。

而主權Rollup方案幹脆不需要Layer1上的合約進行狀態驗證/橋接處理。其架構如下圖:

我們可以看到，在主權Rollup中，由DA層之外的節點群體作爲交易執行和結算操作的實體，具備更高的自由度。其具體的工作流程如下:

主權Rollup的執行層節點，將交易數據/狀態變化細節 發送到DA層，而結算層/客戶端設法獲取數據並進行驗證工作。值得注意的是，由於結算層模塊不位於Layer1上，所以主權Rollup理論上無法實現等同於Layer1安全性的橋，往往要依賴於公證人橋，或是第三方的橋接方案。

目前看來，主權Rollup/客戶端驗證方案落地難度較低，只需要在BTC鏈上實現數據發布，採用類似Ordinals協議的形式。至於鏈下驗證和鏈下共識的部分，自由發揮的空間很大，甚至很多側鏈只要往BTC上發布DA數據，基本就成了“基於BTC的主權Rollup”，只是具體的安全性存疑。

但問題在於，比特幣的數據吞吐量極低，每個block最大4MB，平均出塊時間爲10分鐘，換算下來數據吞吐量僅6KB/s。現在自稱爲主權Rollup的Layer2方案，可能無法把所有DA數據都發布在BTC鏈上，進而採取其他折中方式：比如在鏈下發布DA數據，把datahash存放到BTC鏈上，作爲一種“承諾”。或者找到一種把DA數據高度壓縮的方法（比如Chainway自稱用到的State diff+ZK Proof）。

但顯然這種模式不符合“主權Rollup”或正經Rollup的定義，屬於一種變體，其安全性有待商榷。我們預測，日後大多數打着“Rollup”旗號的Layer2項目，最終都不會把DA數據完整發布到BTC鏈上，所以其實踐方案十有八九與白皮書上的“ZK Rollup”、“OP Rollup”宣傳口號不符合。

最後，讓我們簡單歸納一下主權Rollup和智能合約Rollup的不同之處:

第一，可升級性。智能合約Rollup的更新迭代，涉及到智能合約的update，需要开發團隊使用可升級合約。這種智能合約的升級權限一般由Rollup开發團隊用多籤控制。而主權Rollup的升級規則，類似於常規區塊鏈的軟硬分叉，節點可以自行選擇更新版本，不同客戶端可以選擇是否接受升級。從這一點來看，主權Rollup要比智能合約Rollup更優越。

第二，橋。智能合約Rollup的橋，在理想條件下是符合信任最小化的，但是合約的可升級性會影響其安全。而主權Rollup方案下，需要开發者自己在Layer1鏈下構造橋接組件，構造出的橋十有八九不會像智能合約橋一樣去信任。

BTC DA 構造

在上文中，我們提到，要實現基於BTC的主權Rollup，核心在於使用Ordinals協議將BTC作爲DA層。Chainway就用了這種方案。

我們可以觀察一筆來自Chainway排序器的DA數據提交，其交易哈希爲：

24add7cdcbffcda8d43509c8e27c5a72f4d39df1731be84bdba727cd83ae0000，示意圖如下:

這筆交易的腳本代碼，借鑑了 Ordinals Protocol 中使用 OP_0 OP_IF 實現數據寫入的方案，將 Rollup的DA數據寫入了BTC鏈（發布狀態變化+ZK Proof，在安全性上等價於發布原始交易數據，但數據尺寸可以極大程度壓縮）。

當然，除了 DA 數據外，排序器也在交易內寫入了一些鑑權數據，最重要的就是 Rollup 排序器使用自己的私鑰對 DA 數據進行籤名，確保該筆 DA 數據提交是排序器提交的。

此處我們還要注意，任意一筆涉及DA數據提交的交易，交易哈希尾部都存在16個二進制的 0（也就是連續2個字節均爲0） 。在代碼內，我們可以看到此限制:

前面的示例交易圖中的隨機數 b715 ，目的是調整這筆交易取哈希後的數值，使其尾部攜帶特定的16個0，道理類似於比特幣挖礦時需要添加一個隨機數nonce，使得hash的前N位均爲0，滿足特定的限制條件。

這種設計是爲了簡化DA數據的獲取難度，當Layer2任意節點要獲取DA數據時，只需要掃描BTC區塊中，所有末尾設置爲16個0的交易，相當於把Chainway排序器提交數據時發起的交易，與比特幣鏈上其他交易明確區分开。後文中，稱這種包含DA數據且滿足末尾爲16個0的交易爲“Chainway規範交易”。

那么到了本文標題中提及的重點：Chainway如何實現抗審查呢？因爲Layer2排序器可能會故意拒絕某個用戶的交易請求，我們必須要用一種特殊方案，讓用戶發起抗審查的交易。

面對這一問題，Chainway允許用戶發起“強制交易”，Forced Transaction。一旦用戶在 BTC區塊內提交此交易聲明，Chainway排序器必須在Layer2處理此交易請求，否則將無法正常出塊，或者出的塊不會被鏈下客戶端認可。

強制交易的參數結構如下:

這筆交易會作爲一筆“Chainway規範交易”提交到比特幣鏈上，交易哈希的末尾帶16個0。ChainWay排序器在生成L2區塊時,必須要包含BTC鏈上已披露、但未收錄進L2账本的“Layer2規範交易”，並匯總成一棵Merkle Tree，將其Merkle root寫入L2區塊頭。

一旦用戶在BTC鏈上直接發起強制交易，排序器必須處理，否則無法生成下一個有效的區塊。BTC鏈下的Chainway客戶端可以先校驗ZK證明，確定排序器提交的L2區塊有效性，校驗L2區塊頭的Merkle root，判斷排序器是否如實包含了強制交易請求。

其工作流程可以參考以下流程圖。注意，限於篇幅，下圖中verify_relevant_tx_list 缺失了一個條件判斷:

總而言之，Chainway客戶端/節點會同步BTC主網區塊，並從中，掃描出Chainway排序器發布的“DA數據”，確認這些數據是由指定的排序器發布的，且的確包含了所有提交到BTC鏈上的“Chainway規範交易”。

不難看出，只要用戶能夠構造出一筆符合限制條件的“規範交易”，並提交到BTC鏈上，這筆交易最終會被包含進Chainway客戶端本地的L2账本中，不然Chainway排序器發布的L2 block會被客戶端拒收。

如果配合可靠的鏈下共識/警報消息傳遞，Chainway的抗審查交易方案，就趨近於理想化的主權Rollup的抗審查方法。比如部分主權Rollup方案曾明確表示，遇到無效區塊，會在鏈下客戶端之間廣播Alert警報信息，來增強安全性，尤其讓無法同步完整DA數據的輕客戶端也知道網絡狀態異常。

如果一個區塊沒有如實包含“強制交易”，顯然會觸發鏈下警報廣播，但目前Chainway還沒有實現這一塊（至少目前公布的資料和代碼庫，顯示它沒有去做這塊的技術實現）。

即便是實現了鏈下客戶端/節點間的共識，Chainway“強制交易”的抗審查效果，也不如Arbitrum等智能合約Rollup，因爲Arbitrum One最終會通過Layer1上的合約來確保“強制交易”被包含進Layer2账本，完整繼承Layer1的抗審查性，主權Rollup顯然無法在這一點向智能合約Rollup看齊，其抗審查性最終還是取決於鏈下部分。

這也決定了，“主權Rollup”以及“客戶端驗證”方案的思路，基本無法像Arbitrum One或Loopring、dydx和Degate一樣，完整繼承Layer1的抗審查性，因爲強制交易能否被順利包含進Layer2账本，要取決於Layer2鏈下實體們的決策，與Layer1本身無關。

很顯然，Chainway這種單純依賴於鏈下客戶端自由定奪的方案，只是繼承了Layer1的DA可靠性，沒有完整繼承其抗審查性。

類似於MINA的遞歸ZK證明

在本節中，我們將進一步介紹Chainway的其他組成部分，它除了使用BTC作爲DA層外，也實現了類似於MINA的遞歸ZK證明。其整體結構如下圖:

Chainway網絡的排序器在處理完用戶交易後，生成最終的ZK證明，連帶不同账戶的狀態變化細節 state diff，發布到BTC鏈上。而全節點會同步BTC上發布的Chainway所有歷史數據。每一次ZK證明不僅要對當前區塊的狀態轉換過程進行證明，也要保證上一個區塊的ZK證明有效。

基於上述方案，我們可以發現每次生成新的證明，實際上都對上一個證明進行了確認，依次遞歸，最新的一個ZK證明就可以保證從創世區塊开始的所有ZK證明都有效。這個設計就類似於MINA。

當一個僅同步區塊頭的“輕客戶端”，也就是輕節點加入網絡時，僅需要驗證BTC上披露的最新一個ZK Proof有效，就可以確認整條鏈的歷史數據、所有的狀態轉換是有效的。

假如排序器作惡，故意不接受強制交易，或者不使用上一次ZK證明進行遞歸證明，則生成的新的ZK證明無法被客戶端接受（生成了也不被認可），如下圖:

總結

正如本文最开始的總結，Chainway本質上是一個使用BTC作爲DA層的主權Rollup/客戶端驗證方案。爲了提高 Rollup 的抗審查性，Chainway引入了強制交易的概念。另一方面，Chainway使用了遞歸ZK證明技術，使得新進入的節點可以更加信任排序器的輸出結果，隨時確認整條鏈的歷史數據無誤。

Chainway目前的問題在於跨鏈橋部分該如何去信任，由於其採用主權Rollup方案，沒有說明在跨鏈橋方案上，打算如何解決技術細節，還難以判斷其最終的安全性究竟如何。

今天，我們通過深入分析Chainway的技術方案，發現該項目社區所宣傳的技術類型，並不是主流意義上的Rollup。考慮到當前比特幣Layer2項目已達數十個（半年後可能上百個），爲了降低大家對技術名詞的認知成本，我們將持續的在Layer2方案分類和安全標准、功能完備性測評標准上深入調研，敬請期待！

鄭重聲明：本文版權歸原作者所有，轉載文章僅為傳播信息之目的，不構成任何投資建議，如有侵權行為，請第一時間聯絡我們修改或刪除，多謝。