小明學習筆記 | 一文看懂區塊鏈跨鏈機制

買賣虛擬貨幣


這期主題是跨鏈。


文 | 盧曉明 

區塊鏈涉及到的技術很多,從網際網路底層到不明覺厲的密碼學,可是往往關注幣價者多而研究技術的人少。牛市的時候,大家為了炒幣也會努力學習,熊市的時候,反正也沒啥事,我覺得可以更加努力學習。作為一個文科生,我當然會有很多理科生看起來覺得很白痴的問題。作為一個記者,我不難找到業內懂的人用人話給我解釋,而且他們往往不會當面嫌棄我。

這是小明學習筆記第二期,上次學習的是虛擬機器,這次學習是跨鏈,之後想學習的有VRF、開源歷史和文化、網路體系結構與區塊鏈分層體系對比、“假如把幣圈看成一個國家這個國家的貨幣在經歷什麼”。如果有其他有趣問題,歡迎投稿和提問。

區塊鏈行業大家經常會聊起跨鏈,大概半年前有很多人認為跨鏈是個特別沒意義或者太過超前的話題。不過隨著公鏈專案增多,也有更多的跨鏈專案出現,顯得這個問題更值得討論了。已有的跨鏈專案有 Cosmos、Polkadot、Fusion、Iris、 ICON 、AION、RSK、Ripple 的 Interledger 等。其中有不少還沒有落地,我最近分別採訪了跨鏈專案阿希鏈(ASH)和萬維鏈(Wanchain)的創始人吳青峰和呂旭軍。這兩個專案主網都已上線,當然也還在不斷最佳化中。

感謝兩位創業者解答了我不少問題,同時我比較推薦閱讀 V 神 2016 年給 R3 寫的一份跨鏈報告。雖然是 2 年前的報告,但是個人感覺目前很多技術依然沒有脫離開那篇的框架。為了更加清晰地描述一些技術,這篇文章也會引用到很多 literally 原文。

跨鏈是什麼?

跨鏈簡單來說就是資訊從一條鏈到另外一條鏈。由於現在我們說起區塊鏈,腦海中浮現的基本都是 token,所以其實更多的是作為資產的 token 從一條鏈去另外一條鏈。最容易理解的是拿 ETH 換 BTC,簡單來說就是資產交換。

從網際網路的角度理解,有點像資訊從一個內網到另一個內網。這對於已經有了底層標準化傳輸協議網際網路來說不成問題。可是區塊鏈每一個網路都是一個相對封閉、且互不信任的系統,每發生一件事都要“投票”(共識)一下,怎麼能輕易相信鏈外的東西呢?原來網際網路上的各個後臺資訊都是可以相互傳遞,幾乎無需驗證。呂旭軍認為,由於區塊鏈的資產屬性尤其明顯,使得其跨鏈不同於傳統網際網路資訊傳遞,參與者說謊的動機增強。

跨鏈有什麼用?

跨鏈第一個“最痛”的應用場景就是去中心化交易所,解決了剛剛提到的第一個資產交換的問題現在很多人用中心化交易所的方式也能解決,加上現行的去中心化交易所交易體驗差、速度慢、還不能跨鏈交易,小白使用者都不喜歡,看起來實在沒什麼戲。不過理想主義者會說:作為一個追求去中心化的行業,話語權最大的卻是一大堆中心化的組織,大家覺得這實在太詭異了,而且中心化交易所作惡多端。

另外一種應用場景就是部署在A鏈上的應用支援其他鏈的 token比如以太坊上的智慧合約想用比特幣支付——聽到這個場景我的同事馬上一臉懵逼地問:“為啥呀?”他這個反應也是對的,因為這個聽起來貌似沒有必要,但是有人就是希望支援比特幣或者其他token,希望擴大使用者群。其實這個問題同樣可以用中心化交易所解決。

這個問題也能泛化為,某個DAPP的不同模組可能部署在不同鏈上,那它怎麼呼叫其他鏈上的模組、不同的模組之間怎麼互動?也就是鏈A需要得知鏈B的才能進行下一步或者執行。說白了,這也還是可以用“鏈外”的方式解決,就像一個權威中介,這說起來很像預言機(提供鏈外可信資料)。

V神2016年給R3寫的那篇報告裡提到提到了五個use cases,都離不開以上三種,包括:1、資產(原子)交易(Payment-versus-payment or payment-versus-delivery - in technical circles, this concept is also often called "atomic swap");2、可轉移的資產(Portable assets,資產可以多鏈之間來回轉移和使用);3、跨鏈資料預言機(Cross-chain oracles );4、資產留置或抵押(Asset encumbrance,某資產在鏈上被鎖定,是否解鎖取決於另一鏈上的結果)5、通用跨鏈合約( General cross-chain contracts )。

跨鏈的應用場景其實都能用鏈外方式解決。因此,我曾經跟 ArcBlock CEO 冒志鴻交流過,他就對 “雙向錨定” 的跨鏈比較悲觀,一方面兩條鏈能 “互讀” 的難度非常高,“interledger 就是建起橋樑,兩條鏈的東西還得是一致的,但是兩條鏈確實是不一樣的”;一方面實際應用需求很少,“99% 都只需要應用級的跨鏈,只有很少需要 interledger 級別的跨鏈,比特幣和以太坊為了安全性,可能要這種”。

這個判斷,是他以 “資料庫歷史” 為鑑得出。他介紹,在 80、90 年代,曾經有一個概念叫聯邦分佈資料庫,願景是:兩家企業用的資料庫供應商不同,該技術希望資料庫的角度讓交易保證資料交易的原子性,難度極其高,但是後來證明在現實中根本不需要。“既然可以透過應用層保證一致性,為什麼一定要在底層做呢?因此我們其實在整體設計上比較實用主義。”

怎麼跨鏈?

其實不可能真正意義上某個幣真的 “到了” 另外一個鏈上,大部分只是 B 鏈上生成了一個 A 鏈的錨定幣,同時 A 鏈會將等值代幣“鎖定”。

如果以資產交換這個思路來理解,我理解跨鏈有三種的情況:

第一種是雙方都不知道自己在跨鏈,或者說雙方不能 “讀” 對方,比如中心化交易所這種的。

第二種是其中一條鏈能讀別的鏈,比如側鏈 / 中繼鏈的方式,就是 A 能讀 B,B 不能讀 A;如果一條 C 鏈能讀到所有鏈,按理說也能成為一個 “鏈上” 中介,整個過程就是“A-C-B”。當一條 “側鏈” 連結了很多主鏈時,它就變成一條中繼鏈。

其中資產交換的過程可能是使用者把 BTC 和 ETH“充值”到這個鏈上,各個代幣在這個網路中都能流通(其實就是給每個幣在這個跨鏈網路裡都有一個錨定幣,類似以太坊的 ERC 20),然後分別“提現”。萬維鏈和阿希鏈的模式有點像這種,他們能跟很多鏈互動,但是這些鏈之間不能直接互動。以阿希鏈為例說明:

使用者將 BTC“充值”到阿希鏈上,需要先把 BTC 轉到閘道器賬戶(就是比特幣鏈上的一個普通賬戶,但是管理者是一組節點);跨鏈閘道器收到資訊以後鎖定閘道器賬戶並驗證,經過大多數節點驗證後;閘道器會在阿希鏈上給使用者解鎖等值數字資產,使用者即可在阿希鏈上使用 BTC。BTC 和 XAS 好像是兩個國家的商人,雙方不能互相信任而且使用不同的貨幣,無法直接交易。因此,雙方協商了一套規則(相當於跨鏈閘道器協議)並且設立了一個專門的交易場所來處理交易,由本國有聲望的大商人(相當於閘道器節點)作為代表來共同管理,這些大商人還需要擁有足夠數量的資產作為擔保。

第三種是 A 和 B 都能讀到對方的,這種理論上可以透過統一的協議實現,不過現在還沒有類似協議落地。

說白了,鏈下也能做“跨鏈”;只是有人認為鏈上更安全。

結合萬維鏈的看法,這裡的安全可以拆解為兩個問題:一是保證跨鏈資訊是正確的,即如何驗證原鏈上的交易狀態。如果要考慮到使用 POW 機制的區塊鏈上沒有終局狀態(始終存在分叉的情況,只是隨著確認塊的增加,概率逐漸變小),這個問題的複雜度會更高。二是是保證交易的原子性,即如果交易處理的某個環節停止,整個交易能夠撤銷;否則,部分成功的情況可能會導致雙花。

接下來我會稍微介紹一下我瞭解到的某些相關技術。

首先是關於如何驗證原鏈上的交易狀態,現在我瞭解到的主要有兩種方式(V 神的報告原文均有提到):

第一種是有一組同時承擔兩條鏈節點的個人或聯盟,也有可能是一條單獨的鏈,告訴 B 鏈 A 鏈上發生什麼事,或者告訴 B 某個訊息的真的。比如 Ripple 開發的跨賬本價值傳輸開放協議 Interledger,但它不是鏈,只是一套閘道器協議。V 神把這種稱為公證人模式(Notary schemes)

In a notary mechanism, a trusted entity or set of entities that is trusted as a group is used in order to claim to chain X that a given event on chain Y took place, or that a particular claim about chain Y is true. Such entities may be active, listening and automatically acting based on events in some chain, or reactive, issuing signed messages only when asked. The most advanced effort that has taken steps in this direction is the Interledger project developed by Ripple. Interledger, at least in what it describes as “atomic mode”, uses a Byzantine-fault-tolerant consensus algorithm in order to achieve consensus among a set of notaries on whether or not a given event took place, and then issues a signature that can be used to finalize payments conditional on this consensus. (來自 V 神報告)

另一種則是側鏈 / 中繼 (Sidechains/relays) 。與公證人模式的 “別人告訴 B 鏈 A 鏈上發生的事” 不同,中繼模式則是更 “直接” 地 B 鏈自己讀 A 鏈。比如透過驗證 A 鏈區塊頭和默克爾樹等資訊驗證 A 鏈上的交易,比如以太坊上的 BTC Relay。

根據公開資料,BTCRelay 的運作機制如此:“一個外部的第三方,被稱為 Relayer,傳送一個交易到 BTCRelay 的智慧合約,內容是最新的比特幣區的區塊頭(當然希望的情況下這個區塊頭尚未被提交過的)。BTCRelay 基於現存的區塊頭資訊校驗傳送的區塊頭的有效性。如果校驗透過,則加入到 BTCRelay 維護的比特幣區塊頭鏈。”

由此,在 BTCRelay 的智慧合約裡,實現了一個內建的 SPV(簡單支付校驗)節點,可以用來校驗比特幣交易的有效性。在以太坊平臺的任意使用者或者是智慧合約都能請求 BTCRelay 來驗證,是否某個在比特幣網路上存在某個交易。但這種一方面只能實現單向錨定(由於比特幣指令碼語言不支援),一方面需要乙太網絡中有 Relayer 不斷往合約中提交驗證資訊,賺取使用者手續費。

其實這個模式邏輯上更困擾我的地方在於,既然側鏈也需要第三方的 Relayer 提交資訊,Relayer 的角色跟“公證人”很類似,不同之處只在於側鏈打包了主鏈的區塊頭。

Relays are a more “direct” method for facilitating interoperability, where instead of relying on trusted intermediaries to provide information about one chain to another, the chains effectively take on the task of doing that themselves. The general approach is as follows. Suppose that a smart contract executing on chain B wants to learn that either a particular event took place on chain A, or that some particular object in the state of chain A contained some value at some particular time. Suppose also that chain A is designed similarly to Bitcoin or Ethereum in that it has a notion of “blocks” and “block headers”, where a “block header” is a compact piece of information that “represents” the block (and possibly state data) in some cryptographically authenticated way, most likely using Merkle trees.(來自 V 神報告)

 V 神認為,利用輕客戶端驗證技術SPV(簡單支付驗證,Simple Payment Verificaiton)確實可行,能驗證區塊頭(Header)及其之默克爾樹(Merkle tree)中對應的交易。

This use of this so-called “light client verification” technology is ideal for relays because of how fundamentally resource constrained a blockchain is. In fact, it is impossible for a mechanism inside chain A to fully validate chain B and a mechanism inside chain B to fully validate chain A at the same time, for the same simple mathematical reason why two boxes cannot simultaneously contain each other: A would need to re-run the part of B that re-runs A, including the part of A that re-runs B, and so forth. With light client verification, however, a protocol where chain A contains small pieces of chain B and chain B contains small pieces of chain A that are pulled on-demand is entirely feasible. A smart contract on a relay on chain B that wants to verify a particular transaction, event or state information on chain A would, much like a traditional light client, verify a branch of the cryptographic hash tree of chain A, then verify the block header that the root of this branch is inside, and if both checks pass it would accept that the transaction, event or state information is correct (note that because blockchains are fully selfcontained environments and have no natural access to the outside world, the relevant bits of chain A would need to be fed into chain B by a user; however, because the data is in a cryptographic sense "selfverifying", this user that feeds this information in need not be trusted). (來自 V 神報告)

首先,怎麼驗證交易,說到這裡可能要簡單Mark一下什麼是 SPV,網路上有不少科普文,其中iBlockKim這個作者寫得比較清楚(有刪減):

根據中本聰在比特幣白皮書裡描述:“不執行全節點也可以驗證支付,使用者只需要儲存所有的區塊頭(Block Header)就可以了。使用者雖然不能自己驗證交易,但如果能夠從區塊鏈的某處找到相符的交易,他就可以知道網路已經認可了這筆交易,而且得到了網路的多個確認。”

一個區塊鏈中的資訊透過兩兩打包,最後歸納成一個節點,即根節點(如圖中的節點0),區塊頭中包含了根節點的雜湊值,包含了所有交易又大大減少了區塊頭部的大小。不僅如此,當要搜尋某一個交易,比如上圖中的23的時候,可透過幾步,比如0-2-5-11即可以快速搜到。

因此,SPV在尋找交易時,只需下載尋找區塊頭而不是整個區塊。區塊頭只有80位元組,每小時6個,一年也就4M大小。

那麼如何定位區塊呢?比特幣提供了一種叫做布隆過濾器(Bloom filter)的功能,節點會在通訊鏈路上建立一個這樣的過濾器,限制只接受含有目標地址的交易,從而能過濾掉大量不相關的資料,減少客戶端不必要的下載量。比如,SPV節點會收到少於1KB的有關區塊頭和Merkle路徑的資料,其資料量只約佔一個完整區塊(目前大約1MB)的千分之一。

然後怎麼打包,用BTC舉例的話,側鏈協議實際的操作步驟是(來自碼農學習區塊鏈):

提交鎖定交易:比特幣持有者在 BTC 主鏈上傳送一個特殊交易,把比特幣鎖定在 BTC 鏈上。

等待確認:在 BTC 鏈上等待鎖定交易被更多區塊確認,以防止該鎖定是虛假的交易。

解鎖交易:鎖定交易確認後,使用者在側鏈上建立一個解鎖交易(也被叫做贖回交易)花掉鎖定交易的輸出,並提供 SPV 工作量證明(即該解鎖交易所在區塊的工作量證明),並將贖回交易的輸出匯入自己在側鏈上的地址中。

等待一個競爭期:競爭期也被稱作可修改階段,作用是防雙花。而且在此期間,解鎖交易不會被打包到區塊新轉移到側鏈上的比特幣還不能被使用

如果解鎖交易包括了比特幣主鏈更大難度的 SPV 證明,則上一個解鎖交易將被替換。

競爭期結束後,該解鎖交易將被打包到區塊中,使用者可以使用他的比特幣了(其實是側鏈上相對應的代幣)。

BTCRelay 類似,中繼模式的弊端在於成本太大,V 神也認為驗證對方鏈上的資訊會影響速度。可以想象,如果你單純用 “公證人模式”,只需要等比特幣鏈上確認就行了,可是如果驗證資訊還要上側鏈,就意味等待確認的事情多了很多。阿希鏈並沒有選擇打包區塊鏈,就是因為單青峰認為,將區塊頭打包上鍊 “成本比較大,沒有通用性,解決了比特幣的解決不了以太坊的”。同樣萬維鏈也沒有用,呂旭軍表示,Voucher 共識的模式還在驗證階段:工程上 Voucher 資訊的提交和驗證如果上鍊,需要耗費較高的鏈上資源並限制吞吐量;經濟上需要更合理的激勵機制讓 Voucher 成員積極參與並消極作惡。

較為知名的跨鏈專案還有 Cosmos 和 Polkadot,不過都未落地。在 Cosmos 中,不同空間(Zone,獨立區塊鏈)透過 IBC(區塊鏈通訊)協議分別和 “中心”(Hub,管理眾多 Zone)通訊,不同空間的資訊包裹經過中心傳輸。為了保證傳輸無誤,一個證明(Merkle-proof)需要被髮布在接收方的區塊鏈上。接收方為了驗證這個證明,需要時刻了解傳送方的區塊頭,類似側鏈採用的機制。

Polkadot 中繼鏈的區塊包含平行鏈的區塊頭,還有一些確認資訊,以避免雙花。驗證人負責運營中繼鏈節點,並驗證平行鏈上的區塊;可能還會有一個收集人執行特定平行鏈的全節點,負責提交新區塊。

萬維鏈暫時使用的方式,是雜湊鎖定,也叫原子互換(Atomic Swap),主要是透過雜湊時間鎖(hash time lock)和密數(Secret)讓雙方完成交易,不需要第三方公證人。這個方式通俗來說可以這樣理解:

假設小明要轉 10 個 ETH 給小紅,小紅要轉 10 個 wan 給小明;

小明在以太坊一智慧合約裡鎖了 10 個 ETH 加上一個密碼的雜湊值,並置入條件:如果小紅在 10 小時內提供了密碼,合約驗證之後小紅就能獲得 10 個 ETH,否則回滾;

小紅在萬維鏈一智慧合約裡鎖了 100 個 wan 並把密碼的雜湊值放在裡面,並置入條件如果小明在 5 小時內提供了密碼,就能獲得100 個 wan;

小明看到小紅在 wan 也鎖了錢,就憑密碼到 wan 上拿走了 100wan;

小紅也從 wan 上的合約中得知密碼,憑密碼到 ETH 合約中拿走 10 個 ETH。

我們可以把小紅換成萬維鏈的 Storeman,使用者(小明)只需要在發起交易、釋放密數、撤銷交易的環節進行操作。對於參與跨鏈的 Storeman,萬維鏈會提供專門的客戶端,客戶端根據協議進行無需值守的自動化執行。這是一個比較成熟的方案,閃電網路用的也是這個,安全度高不過似乎應用場景比較少。

如果是單純兩個使用者交換資產,其實雜湊鎖定是個挺安全的方式(不過使用者體驗不太友好),而且只靠雜湊鎖定就能完成。這跟上面兩種不太一樣,雜湊鎖定還能可以跟第一種結合使用,萬維鏈目前就是這麼做;閃電網路就是雜湊鎖定+多籤。

關於這三個不同技術的應用場景可以看看 V 神的總結。

另外一個涉及到跨鏈的技術叫做多重簽名技術,有的專案也會採用分散式私鑰。比如閃電網路中就利用了多重簽名,交易雙方需要對同一個交易簽名,交易才可以被確認。跨鏈的很多模式,都會涉及到一個作為“聯結器”的閘道器,跨鏈閘道器主要負責讀取各自公鏈上的賬戶資訊,共同對某賬戶下待跨鏈的數字資產鎖定與解鎖。為了安全,這個閘道器往往是一個多節點共同維護的中繼網路和多簽名賬戶。有一定比例的節點參與了之後,才算完成簽名。阿希鏈用的是多重簽名技術。萬維鏈中用的安全多方計算 + 門限秘鑰的技術,Storeman 必須共同參與計算才能生成鎖定賬號的公私鑰,而私鑰只是理論存在,從未出現在網路中,而是以碎片的方式分散在各 Storeman 手中,交易時參與方要再次合力才能共同構造簽名,且互不洩露碎片。為了保證可用性,只需要一定比例的 Storeman 參與計算即可構造簽名。

PS. 有小朋友看了文章之後覺得錨定幣生成跟 EOS 主網對映有點混淆,關於這點我請教了一下 MEET.ONE,他們表示,EOS 對映是類似做快照,主網上線之後可以使用對映生成的私鑰登入,在新主網上取回資產。大概是,Block.one 開發了一個對映的以太坊智慧合約。使用者如果要對映的話,需要使用 EOS 的工具生成一個秘鑰對,再呼叫合約上面對映的方法。以太坊的公鑰地址跟EOS的公鑰地址一一對應,對應關係存在了以太坊上,EOS主網啟動團隊把這些快照下載下來之後,在主網啟動之後按快照發放代幣。

我是Odaily星球日報編輯盧曉明,探索真實區塊鏈,爆料、交流請加微信lohiuming,煩請備註姓名、單位、職務和事由。

原創文章,轉載/內容合作/尋求報道請聯絡 [email protected];未經授權嚴禁轉載,違規轉載法律必究。

免責聲明:

  1. 本文版權歸原作者所有,僅代表作者本人觀點,不代表鏈報觀點或立場。
  2. 如發現文章、圖片等侵權行爲,侵權責任將由作者本人承擔。
  3. 鏈報僅提供相關項目信息,不構成任何投資建議

推荐阅读

;