以Chainway為例，解讀比特幣Layer2計畫是怎麼蹭概念的（一）

目前的比特币Layer2赛道可谓百花齐放，各种不同的技术方案扎堆聚集在了BTC生态这个大熔炉之中。由于区块链领域迭代速度快，专业词汇或者标准，都是在研究创新和工程落地过程中不断变化的。在这样的背景下，很多项目会采用「造概念」/「蹭概念」的方式获取差异化和关注度，已然成为业内潜规则。

作者：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是一個在西方社區比較有名的比特幣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，效果等價於發布完整的、可驗證的交易資料。

但由於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狀態。

我們可以看出，智能合約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方案分類和安全標準、功能完備性測評標准上深入調研，敬請期待！