技術解讀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方案分類和安全標準、功能完備性測評標准上深入調研,敬請期待!

Total
0
Shares
Related Posts