技術解讀Chainway：位元幣Layer2專案是怎麼蹭概念的（一）

Chainway 本質上是一個使用 BTC 作為 DA 層的主權 Rollup/ 客戶端驗證方案。

撰文：Shew & Faust，極客 web3

目前的位元幣 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 數據上鏈，不上鏈就無法更新結算層記錄的狀態）

參考資料：用木桶理論拆解位元幣 / 以太坊 Layer2 安全模型與風險指標

我們可以看出，智慧合約 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 還沒有實現這一塊（至少目前公佈的資料和代碼庫，顯示它沒有去做這塊的技術實現）。

參考資料：Celestia 研究員分析 6 種 Rollup 變體：Sequencer=聚合器 +Header 生成者

即便是實現了鏈下客戶端 / 節點間的共識，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 方案分類和安全標準、功能完備性測評標準上深入調研，敬請期待！