導語：目前的比特幣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，但其舊方案是客戶端驗證，ZKR是他們另一個項目。目前其尚未實現 鏈下客戶端間的共識，或可靠的訊息交換）正文：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方案分類和安全標準、功能完備性測評標準上深入調研，敬請期待！

聲明：

1. 本文轉載自[極客 Web3]，著作權歸屬原作者[Shew & Faust，極客web3]，如對轉載有異議，請聯繫Gate Learn團隊，團隊會根據相關流程盡速處理。
2. 免責聲明：本文所錶達的觀點和意見僅代錶作者個人觀點，不構成任何投資建議。
3. 文章其他語言版本由Gate Learn團隊翻譯， 在未提及Gate.io的情況下不得覆製、傳播或抄襲經翻譯文章。