市場新聞

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

By 極客 Web3 2024-02-01 05:47
技術解讀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方案分類和安全標准、功能完備性測評標准上深入調研,敬請期待!

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

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

地址:https://www.pressbased.com/post/3416.html