為了鞏固對跨鏈的認(rèn)識化戳，為此對跨鏈的知識點概念等進行查漏補缺宜雀，利用了周末的時間重新閱讀了一份關(guān)于跨鏈的報告切平，方便更系統(tǒng)地熟悉跨鏈的應(yīng)用場景與方案。

跨鏈的定義:

跨鏈辐董，狹義上來說是兩個相對獨立[1]的區(qū)塊鏈賬本間進行資產(chǎn)互操作（Interoperability）的過程悴品；廣義上來說是兩個獨立的賬本[2]間進行資產(chǎn)、數(shù)據(jù)互操作的過程简烘。

[1]指兩個區(qū)塊鏈賬本間相互獨立苔严，沒有在某方統(tǒng)一進行清/結(jié)算的情況（交易都在母鏈賬本進行清算的母子鏈結(jié)構(gòu)不存在本文所述的跨鏈操作）

[2] 此處所指的賬本不僅指的是區(qū)塊鏈賬本，也指中心化賬本或者其他形式的分布式賬本（如DAG賬本）孤澎。

案例應(yīng)用：

1. 鏈下通道：閃電網(wǎng)絡(luò)届氢、雷電網(wǎng)絡(luò)
2. 跨賬本多跳協(xié)議：Ripple
3. 側(cè)鏈：單向/雙向錨定側(cè)鏈：Liquid、Elastos
4. 跨鏈平臺：Wanchain
5. 跨鏈平臺：Cosmos覆旭、Polkadot

跨鏈的實現(xiàn)形態(tài)主要表現(xiàn)為資產(chǎn)互換和資產(chǎn)轉(zhuǎn)移

跨鏈進化史

2012年Ripple才發(fā)布了跨賬本互操作協(xié)議《Interledger Protocol (ILP)》悼沈，通過第三方公證人的方式實現(xiàn)了跨賬本轉(zhuǎn)賬贱迟，在區(qū)塊鏈領(lǐng)域首次提出了跨賬本互操作方案。

2014年絮供，由比特幣核心開發(fā)人員組成立的BlockStream團隊首次提出錨定式側(cè)鏈（Pegged Sidechains）跨鏈交互方案衣吠，引入一條與主鏈雙向錨定（Two-way peg）的側(cè)鏈，可實現(xiàn)跨鏈資產(chǎn)轉(zhuǎn)移壤靶。

2015年缚俏，比特幣閃電網(wǎng)絡(luò)（Lightning Network）采用哈希時間鎖（Hashed Timelock）機制，實現(xiàn)了比特幣鏈下快速交易通道贮乳。

2016年忧换，BTCRelay方案發(fā)表，基于中繼跨鏈方案實現(xiàn)了比特幣到以太坊的單向跨鏈連通向拆。同年Vitalik Buterin發(fā)表的《Chain Interoperability》對區(qū)塊鏈互操作問題做了全面和深度的分析亚茬。

2017年，Polkadot和Cosmos第一次提出了建設(shè)跨鏈網(wǎng)絡(luò)基礎(chǔ)平臺的方案浓恳，目前這兩個項目還在開發(fā)過程中刹缝。

跨鏈實現(xiàn)形態(tài)：

鏈間資產(chǎn)互換：通常指兩條鏈上的不同用戶之間進行資產(chǎn)互換，但每條鏈上的資產(chǎn)總量并無增減颈将，只是資產(chǎn)所有權(quán)發(fā)生了變化梢夯，且這個所有權(quán)改變的過程需在兩條鏈同步發(fā)生。

鏈間資產(chǎn)轉(zhuǎn)移（單向/雙向）：資產(chǎn)轉(zhuǎn)移和資產(chǎn)互換雖看起來相似晴圾，卻有本質(zhì)的不同颂砸。上文所述資產(chǎn)互換中各鏈的資產(chǎn)總數(shù)是不變的，但資產(chǎn)轉(zhuǎn)移死姚，是資產(chǎn)價值的轉(zhuǎn)移人乓，各鏈中可用的資產(chǎn)總量將相應(yīng)增加或者減少。

有些項目提出了跨鏈智能合約的概念都毒，多指一條鏈上的智能合約能確認(rèn)原鏈跨鏈交易的場景撒蟀，這從技術(shù)實現(xiàn)上來說和實現(xiàn)跨鏈資產(chǎn)轉(zhuǎn)移是相似的，都需要對原鏈交易進行確認(rèn)和驗證温鸽。

1）如何保障跨鏈交易的原子性保屯。即跨鏈交易要么發(fā)生，要么不發(fā)生涤垫，否則兩條鏈的不一致和不同步狀態(tài)將成為跨鏈交易最大的系統(tǒng)漏洞姑尺，兩個系統(tǒng)的安全性都將受到威脅。

2）如何完成對另一條鏈的交易確認(rèn)蝠猬。對交易的確認(rèn)切蟋，包含了兩個層次的問題，一是確認(rèn)交易已經(jīng)發(fā)生并且上鏈榆芦，寫入了區(qū)塊賬本柄粹；二是該交易已經(jīng)獲得了系統(tǒng)足夠多區(qū)塊的確認(rèn)喘鸟，這樣由于系統(tǒng)發(fā)生重構(gòu)而導(dǎo)致交易無效的概率將非常低。區(qū)塊鏈系統(tǒng)本身是較為封閉的系統(tǒng)驻右，缺乏主動獲取外部信息的機制什黑，因此要確認(rèn)另外一條鏈的交易狀態(tài)并非一件容易的事，可以說是跨鏈交易的核心難點之一堪夭。

3）如何保障兩條鏈的資產(chǎn)總量不變愕把。在資產(chǎn)互換的場景下，兩條鏈的資產(chǎn)并未發(fā)生實質(zhì)性的交換森爽，因此該類情況不會改變各鏈的資產(chǎn)總量恨豁。但是在資產(chǎn)轉(zhuǎn)移的場景下，每條鏈的可用資產(chǎn)數(shù)量是變化的爬迟，只有保障跨鏈交易精確記賬橘蜜，且兩條鏈的賬本記賬完全同步，才可實現(xiàn)付呕，換種說法就是兩條鏈的記賬必須是原子性的计福，要么都同時記，要么都不記凡涩。除此之外，問題的關(guān)鍵是當(dāng)某條鏈發(fā)生重構(gòu)時疹蛉，是否依然能保持兩條鏈的資產(chǎn)總量不變活箕。

4）如何保障兩條鏈的獨立安全性。當(dāng)兩個系統(tǒng)發(fā)生交互時可款，難免會對彼此系統(tǒng)產(chǎn)生影響育韩，如何在跨鏈交易的過程中保障自己系統(tǒng)和對方系統(tǒng)的安全性是個值得考慮的問題。若是安全性問題無法隔離闺鲸，那一條鏈?zhǔn)艿焦艚钐郑瑢⒂绊懻麄€跨鏈網(wǎng)絡(luò)。

5）如何實現(xiàn)多條鏈之間的跨鏈互聯(lián)摸恍。參照計算機網(wǎng)絡(luò)的發(fā)展歷程悉罕，獨立的區(qū)塊鏈網(wǎng)絡(luò)終究要走上互聯(lián)互通的未來，那如何將這些已有的和未來將要開發(fā)的區(qū)塊鏈網(wǎng)絡(luò)都聯(lián)系起來成為統(tǒng)一的整體將是未來跨鏈網(wǎng)絡(luò)最重要的問題之一立镶。

跨鏈具體的關(guān)鍵點與實現(xiàn)方式可以總結(jié)為：

1. 如何保障跨鏈交易的原子性：介紹了原子互換和哈希時間鎖協(xié)議原理壁袄。
2. 如何完成對另一條鏈的交易確認(rèn)：介紹了公證人、中繼以及榫卯式三大類模式異同媚媒。
3. 如何保障兩條鏈的資產(chǎn)總量不變：從正常和異常兩種情況分別闡述了應(yīng)對方案嗜逻。
4. 如何保障兩條鏈的獨立安全性：主要從隔離機制和安全檢測機制分析了應(yīng)對思路。
5. 如何實現(xiàn)多條鏈之間的跨鏈互聯(lián)：介紹了主動兼容和被動兼容兩種跨鏈網(wǎng)絡(luò)建設(shè)方案缭召。

保障跨鏈交易的原子性

需要兩個轉(zhuǎn)賬交易栈顷，兩個保證對方轉(zhuǎn)賬的回撤交易逆日。

1. Alice在鏈A上有1個BTC，Bob在鏈B上有20個ETH，Alice想用1個BTC換Bob的20個ETH耕赘。Alice和Bob同時在鏈A和鏈B上都有錢包地址览祖。
2. 首先Alice隨機生成一個密鑰K，該密鑰只有Alice知道狠半，然后在鏈A上發(fā)起一筆給Bob 1個BTC的轉(zhuǎn)賬交易（交易①），該交易只有在獲得Bob的簽名以及提供密鑰K之后才能完成颤难。
3. 在交易①廣播之前神年，Alice會先在鏈A上廣播一個回撤交易（交易②），若交易①在48小時內(nèi)未獲得正確的密鑰和簽名行嗤，那么交易①支付的金額將退回給Alice已日。交易②廣播出去后需獲得Alice和Bob的共同簽名，該交易才會生效栅屏。同時飘千，Alice只有在交易②成功生效的情況下才會向網(wǎng)絡(luò)廣播交易①。
4. Bob此時看到Alice發(fā)來的交易②栈雳，若Bob愿意進行這次交易护奈，則Bob會對交易②簽名，當(dāng)然Alice也會完成簽名哥纫，這樣回撤交易就能生效霉旗，Alice此時將交易①向全網(wǎng)廣播。
5. Bob此時無法得知密鑰K蛀骇，只能通過向Alice支付20個ETH后才能獲得密鑰K厌秒，因此，Bob在鏈B上發(fā)起交易③擅憔，向Alice支付20個ETH鸵闪，只有當(dāng)Alice輸入密鑰K成功解密，并附上Alice簽名才可獲得這20個ETH暑诸。為防止Alice抵賴蚌讼，保障自己能成功拿到密鑰K，Bob也在廣播交易③之前先發(fā)布一個需要Alice和Bob共同簽名的回撤交易④个榕，當(dāng)Alice在24小時內(nèi)未提供正確的密鑰K并附上簽名啦逆，就激活回撤交易④，20ETH退回給Bob笛洛。
6. Alice看到Bob發(fā)起的回撤交易④夏志，Alice和Bob為了繼續(xù)交易將會給該交易附上自己的簽名，回撤交易④生效。此時Bob也會將交易③廣播給全網(wǎng)沟蔑。
7. Alice為了獲得20ETH湿诊，將會對交易③附上自己的簽名，并且輸入正確的密鑰K瘦材，此時交易③成功厅须，Alice獲得20ETH，Bob獲得密鑰K食棕。
8. Bob拿到密鑰K后朗和，回到鏈A，輸入密鑰和自己的簽名簿晓，最終拿到Alice的1個BTC眶拉。

原子互換協(xié)議并未將鏈A的資產(chǎn)轉(zhuǎn)移到鏈B，而只是同時交換了鏈A和鏈B資產(chǎn)的所有權(quán)憔儿，鏈A的資產(chǎn)總量和鏈B的資產(chǎn)總量并未改變忆植，因此原子互換協(xié)議只能實現(xiàn)鏈間的資產(chǎn)互換，無法實現(xiàn)資產(chǎn)轉(zhuǎn)移谒臼。

HTLC哈希時間鎖協(xié)議：

哈希時間鎖協(xié)議朝刊，即HTLC（Hashed Time-Lock Contract）,是原子互換協(xié)議的具體實現(xiàn)，通過哈希鎖和時間鎖機制保障了交易的原子性蜈缤。若只使用哈希時間鎖拾氓，只能實現(xiàn)跨鏈的資產(chǎn)互換，而非跨鏈資產(chǎn)轉(zhuǎn)移

哈希鎖

在2.1.1小節(jié)介紹的例子中底哥，Bob要如何驗證Alice提供的密鑰K是正確呢?這里最通常的做法是用哈希函數(shù)來實現(xiàn)咙鞍。Alice在最開始的時候產(chǎn)生一個隨機數(shù)K（即密鑰K），用一個哈希函數(shù)對該隨機數(shù)做計算得到M,即H(K)=M叠艳，Alice會將函數(shù)H和M告訴Bob奶陈，我們知道哈希函數(shù)的計算是不可逆的易阳，幾乎無法通過H和M反向計算得到K附较。所以Bob只能讓Alice主動披露一個密鑰K’，并用H和M來驗證Alice提供的K’是否能通過哈希函數(shù)H計算得到M潦俺，若驗證通過拒课，則證明Alice提供的K’就是真實的密鑰K。這種哈希函數(shù)鎖定的方式就是我們所說的哈希鎖事示，只有密鑰K才能打開的鎖早像。在比特幣系統(tǒng)中通常用OP_HASH256操作符來進行哈希計算操作。

時間鎖

在2.2小節(jié)介紹的原子互換協(xié)議中肖爵，需要交易在某個時間范圍內(nèi)不生效卢鹦，如回撤交易需要在超時以后再被觸發(fā)。時間鎖在比特幣系統(tǒng)中有兩種實現(xiàn)方式[3]劝堪。

1. CheckLockTimeVerify（CLTV）

比特幣2015年BIP65的軟分叉版本中提出了CLTV操作碼冀自，允許交易的輸出在一段時間內(nèi)被阻塞（交易的其它部分不受影響）揉稚。當(dāng)CLTV操作碼被調(diào)用的時候，會檢測交易中的nLockTime參數(shù)熬粗，只有當(dāng)nLockTime的時間大于或者等于CLTV參數(shù)指定的時間時搀玖，交易才會被完整執(zhí)行，否則交易會被阻塞在memory pool中驻呐。

nLockTime是比特幣交易最原始的參數(shù)類型灌诅，表示了該交易可最早被寫到區(qū)塊上的時間，或者是最小可寫入的區(qū)塊高度含末。nLockTime設(shè)置為0猜拾，表明該交易寫入任何一個區(qū)塊都將有效。

2. CheckSequenceVerify（CSV）

比特幣2016年BIP68/112/113軟分叉時提出了CSV操作碼答渔，相對于CLTV提出的絕對鎖定時間來說关带，CSV提出的是相對鎖定時間。當(dāng)執(zhí)行CSV操作碼時沼撕，系統(tǒng)會檢查NSequence參數(shù)宋雏，若其表示的相對時間大于或者等于CSV參數(shù)的時間，則交易開始執(zhí)行务豺；否則交易會被阻塞在memory pool中磨总。

Relative Locktime是2016年BIP68/112/113軟分叉提出來的，參數(shù)由nSequence表示笼沥，是交易輸入域參數(shù)的一種蚪燕，表明了該交易最早能被寫入?yún)^(qū)塊的時間，該時間是相對于上次UTXO寫入?yún)^(qū)塊的時間而言的奔浅。

HTLA馆纳，哈希時間鎖協(xié)定

哈希時間鎖協(xié)定[4]，即HTLA（Hashed Time-Lock Agreements）是Interledger[10]提出的HTLC泛化協(xié)定汹桦，不管系統(tǒng)是否支持HTLC協(xié)議鲁驶，不管其是分布式賬本還是中心化賬本，系統(tǒng)和系統(tǒng)之間都能使用HTLA實現(xiàn)跨鏈交換舞骆，且支持多個系統(tǒng)之間的多跳跨鏈互換钥弯。Alice和Bob可以通過HTLA在區(qū)塊鏈A、B督禽、C之間進行跨鏈交換脆霎，且每一種區(qū)塊鏈都支持不同的跨鏈協(xié)議，連接器在這其中起到了連接狈惫、隔離的作用睛蛛，將支持不同跨鏈協(xié)議的區(qū)塊鏈連接到一起，并且又起到了隔離的作用，使得區(qū)塊鏈之間不會相互影響忆肾。

有條件的支付通道（Conditional Payment Channels）

對賬本的功能性需求：支持支付通道的HTLC更新

對賬本的非功能性需求：支持高速交易

交易風(fēng)險：無

使用案例：閃電網(wǎng)絡(luò)[5]

協(xié)議簡介：支持有條件支付通道協(xié)議的系統(tǒng)菠红，交易參與者需要在賬本上預(yù)付一筆資金到一個雙方共享的臨時賬戶。當(dāng)交易開始時难菌，發(fā)送者會發(fā)送一個帶有哈希鎖和時間鎖以及附帶簽名的更新到接收者试溯。若接收者能在超時前反饋哈希鎖的原像，則其可從臨時賬戶中贖回資金郊酒，并且發(fā)送者接收者同時簽名確認(rèn)共享賬戶的余額變動遇绞。當(dāng)發(fā)生爭議時，賬本將依據(jù)賬本信息進行判斷和仲裁燎窘。由于交易的傳輸和處理時間會被計算在超時的范圍內(nèi)摹闽，所以該種協(xié)議更適合支持高速交易的賬本系統(tǒng)。

On-Ledger持有/托管

對賬本的功能性需求：支持HTLC交易

對賬本的非功能性需求：支持高速褐健、低費用和高吞吐量

交易風(fēng)險：無

使用案例：以太坊第三方托管合約付鹿、Ripple第三方托管

協(xié)議簡介：當(dāng)賬本支持HTLC協(xié)議時，并且該賬本交易速度快蚜迅、費率低舵匾、吞吐量高，那么參與者之間可以直接通過HTLC協(xié)議發(fā)起跨鏈交易谁不。交易發(fā)起者將要傳輸?shù)馁Y金先放到賬本提供的特定持有賬戶中坐梯，并且附帶哈希鎖和時間鎖，只有當(dāng)接收者在超時前能提供正確的哈希原像刹帕，賬本賬戶才將資金發(fā)送給接收者吵血，否則賬本將會把資金退回給發(fā)送者。這種方式可由賬本負(fù)責(zé)全權(quán)控制交易狀態(tài)偷溺，交易雙方?jīng)]有額外的風(fēng)險蹋辅。

簡單支付通道（Simple Payment Channels）

對賬本的功能性需求：支持無條件的、單向支付通道

對賬本的非功能性需求：無

交易風(fēng)險：有交易對手風(fēng)險

使用案例：比特幣CLTV通道[8]挫掏、Ripple PayChan[9]

協(xié)議簡介：簡單支付通道是建立的off-chain交易通道，無論賬本交易速率如何砍濒，鏈下的通道可支持大規(guī)牧苌觯快速交易硫麻。在建立單向通道時爸邢，發(fā)送者需要將資金存入鏈上和接收者共享的臨時賬戶中，只有當(dāng)雙方對交易金額的數(shù)量和轉(zhuǎn)移方向都同意且同時簽名時拿愧，該賬戶的資金才可被取出杠河。發(fā)送者傳給接收者的是一個帶哈希鎖和時間鎖的消息，當(dāng)接收者在超時前提供了正確的哈希原像，發(fā)送者再發(fā)起一個新的帶有簽名的申明給接收者券敌，使得接收者能接收到全部的交易金額唾戚。

保障對另一條鏈的交易確認(rèn)

兩條鏈之間發(fā)起跨鏈交易的時候要如何才能確認(rèn)發(fā)送鏈的交易真的發(fā)生并且被它確認(rèn)了呢？

兩條鏈之間總會出現(xiàn)一個“中間人”的角色待诅，承擔(dān)了為兩條鏈進行信息交互的角色叹坦，只不過在具體實現(xiàn)時這個“中間人”的角色有很多種演化的可能性。“中間人”可能是一個也可能是一群卑雁，可能是中心化機構(gòu)也可能是分布式群體募书，兩條鏈的中間人可能是同一個/組節(jié)點，也可能不同测蹲，甚至這個“中間人”可能是一條獨立的鏈或者又只是一個功能模塊而已莹捡。“中間人”通常會同時充當(dāng)兩個區(qū)塊鏈的節(jié)點扣甲，這樣只需在同一節(jié)點上再部署一個應(yīng)用軟件獲取對方系統(tǒng)數(shù)據(jù)即可篮赢。

在交易確認(rèn)這個問題上其實隱含了三層意思:

• 第一層含義是跨鏈數(shù)據(jù)傳遞，即需要獲取/收集發(fā)送鏈的數(shù)據(jù)琉挖，為交易確認(rèn)做好準(zhǔn)備启泣；
• 第二層含義是發(fā)送鏈對交易的確認(rèn)，即發(fā)送鏈的交易并不是只要寫入?yún)^(qū)塊就能最終確認(rèn)的
• 第三層含義是目標(biāo)鏈對發(fā)送鏈已經(jīng)確認(rèn)過的交易再次核實示辈，即需要依據(jù)收集到的數(shù)據(jù)來做確認(rèn)种远，到底發(fā)送鏈聲稱的跨鏈交易是否發(fā)生，以及交易是否得到最終確認(rèn)顽耳。

公證人坠敷、中繼、榫卯

“中間人”基本上完成了前者數(shù)據(jù)收集的工作射富，那交易如何確認(rèn)膝迎，在哪確認(rèn)，以及由誰來確認(rèn)成為了問題的關(guān)鍵胰耗。根據(jù)不同的方案限次，我們可以將該過程主要概括為三種實現(xiàn)方式，即公證人模式柴灯、中繼模式和榫卯模式卖漫。

image

公證人模式是最為簡潔的設(shè)計，即“中間人”不僅進行數(shù)據(jù)收集赠群，還進行交易確認(rèn)和驗證羊始。此時的“中間人”將成為可信第三方，可以是一個雙方可信的中心化機構(gòu)查描，也可以是一群節(jié)點突委。其驗證交易是否正確的過程又將有多種演化柏卤，主要分為三種：單簽名公證人機制、多簽名公證人機制以及分布式簽名公證人機制

image

中繼模式中匀油，“中間人”僅僅充當(dāng)數(shù)據(jù)收集者的角色缘缚，并將收集的數(shù)據(jù)轉(zhuǎn)發(fā)給目標(biāo)鏈，由目標(biāo)鏈依據(jù)收集的數(shù)據(jù)去完成交易確認(rèn)的工作敌蚜。中繼模式是個相對去中心化和松耦合的方式桥滨，兩個鏈之間的設(shè)計和結(jié)構(gòu)是較為獨立的，因此也具備了更高的可擴展性弛车「迷埃“中間人”更多地充當(dāng)了中繼橋梁的角色。

image

榫卯[3]模式表述的是一種通過數(shù)據(jù)強耦合關(guān)系來實現(xiàn)跨鏈互操作的模式帅韧。鏈A和鏈B通過“中間人”收集到對方的數(shù)據(jù)里初，并且將對方的數(shù)據(jù)納入到自己的區(qū)塊鏈體系中來。這種納入不一定是記錄到自己的區(qū)塊中忽舟，有可能是記錄到自己系統(tǒng)中的存儲空間双妨。若鏈A是已經(jīng)存在的區(qū)塊鏈，那鏈B要么只能單向嵌入鏈A叮阅，要么鏈A就要進行相應(yīng)的升級改造刁品。這種強耦合的結(jié)構(gòu)通常用于側(cè)鏈的設(shè)計中。

榫卯（sǔn mǎo）是古代中國建筑浩姥、家具及其它器械的主要結(jié)構(gòu)方式挑随，是在兩個構(gòu)件上采用凹凸部位相結(jié)合的一種連接方式。凸出部分叫榫（或叫榫頭）勒叠；凹進部分叫卯（或叫榫眼兜挨、榫槽）。其特點是在物件上不使用釘子眯分，利用卯榫加固物件拌汇。本文用來特指一種采用強耦合數(shù)據(jù)結(jié)構(gòu)實現(xiàn)跨鏈的技術(shù)模式。

理解三種方式的關(guān)鍵點就是：要充分理解其如何實現(xiàn)對原鏈交易的確認(rèn)弊决，即數(shù)據(jù)如何傳遞噪舀，原鏈交易如何確認(rèn)，接收鏈對原鏈交易如何驗證即可飘诗。

公證人

中心化公證人模式為:中心化公證人機制也叫單簽名公證人機制与倡，通常由單一指定的獨立節(jié)點或者機構(gòu)充當(dāng)，這是最簡單的模式昆稿，通常纺座，這種模式被用于某類單一或特定的交易。與其Alice和Bob兩個陌生人直接交易貌嫡，不如兩者都和有信用背書的第三方機構(gòu)間接交易更可靠（如支付寶模式）

多重簽名的公證人機制是由多位公證人在各自賬本上共同簽名達成共識后才能完成跨鏈交易比驻。公證人的選取可以有多種方式，比如1）隨機抽取公證人岛抄；2）對交易雙方可信公證人節(jié)點列表求交集别惦；3）直接采用可信聯(lián)盟中的可信節(jié)點等。

分布式簽名的公證人機制和多重簽名的公證人機制最大的區(qū)別在于簽名的方式不同夫椭，采用了多方計算MPC（Multi-Party Computation）的思想掸掸，分布式簽名相較于多重簽名，安全性更高蹭秋，但實現(xiàn)也更復(fù)雜扰付。

中繼Relay

中繼（Relay）是更靈活、易于擴展的跨鏈技術(shù)仁讨，其不依賴可信第三方幫助其進行交易驗證羽莺，而是在拿到發(fā)送鏈數(shù)據(jù)后由接收鏈自行驗證，自行驗證的方式依據(jù)系統(tǒng)結(jié)構(gòu)不同而不同洞豁，例如BTC-Relay依賴于SPV證明（如下文SPV小節(jié)所示）盐固，Cosmos還依靠驗證節(jié)點簽名數(shù)量等。

Vitalik在其互操作性論文[2]中提到Relay丈挟，指出鏈A和鏈B可通過對方的區(qū)塊數(shù)據(jù)來進行信息同步和跨鏈函數(shù)調(diào)用刁卜，目前信息同步是可以做到的，但是跨鏈函數(shù)調(diào)用還沒有成熟的技術(shù)方案曙咽。但兩個鏈不能同時驗證對方區(qū)塊的有效性蛔趴，否則將陷入互為嵌套的死循環(huán)。如鏈A擁有鏈B的區(qū)塊數(shù)據(jù)例朱，則鏈A需在鏈B交易確認(rèn)的情況下才能進行確認(rèn)孝情，而鏈B因為同時擁有鏈A的區(qū)塊數(shù)據(jù)，鏈B又需等待鏈A的交易確認(rèn)洒嗤，……,這樣咧叭，交易確認(rèn)就陷入了死循環(huán)。

BTC-Relay

2016年Consensys團隊推出的BTC-Relay是最經(jīng)典的中繼（Relay）跨鏈方案烁竭，實現(xiàn)了以太坊和比特幣之間的跨鏈交易菲茬，使得以太坊的DApp應(yīng)用可以支持BTC支付。

BTC-Relay本身為以太坊的一個智能合約派撕，該合約的功能就是對比特幣上的某些交易進行驗證婉弹，并且提供驗證信息給以太坊上的其它DApp用戶。Relayer是從比特幣獲取區(qū)塊頭數(shù)據(jù)的一群用戶终吼，并擁有以太坊網(wǎng)絡(luò)的賬戶地址镀赌，最快向BTC-Relay合約提交區(qū)塊頭數(shù)據(jù)的Relayer可以得到以太坊的交易費獎勵。BTC-Relay智能合約獲得區(qū)塊頭數(shù)據(jù)以后就可以依據(jù)SPV證明的原理對某交易進行驗證际跪，當(dāng)比特幣網(wǎng)絡(luò)中的某交易確實發(fā)生商佛，則可觸發(fā)以太坊網(wǎng)絡(luò)的特定交易或者智能合約執(zhí)行喉钢。

SPV證明

SPV，Simplified Payment Verification良姆，即簡單支付證明肠虽，其中，“支付”是關(guān)鍵字玛追，即該種證明只是對是否發(fā)生支付行為做驗證税课，而不是對“交易”做驗證。

比特幣一個區(qū)塊的大小為1M痊剖，而區(qū)塊頭只占了80個字節(jié)（Byte）韩玩，交易列表則占用了區(qū)塊中的絕大部分空間。SPV的基本原理就是在只有區(qū)塊頭數(shù)據(jù)的情況下驗證某交易是否發(fā)生陆馁，這樣既方便快速也節(jié)省了大量的存儲空間找颓。

通過區(qū)塊鏈頭數(shù)據(jù)來驗證某交易是否已發(fā)生，可以按照如下的步驟進行：

1. 下載區(qū)塊中最長鏈的區(qū)塊頭數(shù)據(jù)
2. 計算該交易的哈希值叮贩，得到Tx_hash;
3. 通過Tx_hash索引定位到包含該交易的區(qū)塊
4. 為驗證該交易是否存在于該區(qū)塊中叮雳，需重新計算與該交易相關(guān)的哈希值，直到根部妇汗，并將計算得到的哈希值與區(qū)塊頭中的Merkle根哈希進行比較帘不；若一致，則表明該交易確實發(fā)生并存在于該區(qū)塊中杨箭；若不一致寞焙，則說明該交易并未被打包到最長的鏈中，即未被驗證確認(rèn)互婿。

榫卯式

榫卯式是一種強耦合結(jié)構(gòu)的跨鏈模式捣郊，通過某種方式直接將原鏈的部分?jǐn)?shù)據(jù)嵌入到自己的區(qū)塊或者存儲空間中。在進行跨鏈交易時慈参，直接通過本系統(tǒng)存儲的原鏈數(shù)據(jù)便可完成交易驗證呛牲。這種方式一般在系統(tǒng)設(shè)計之初就進行了雙向考慮，通常用于主鏈+側(cè)鏈的設(shè)計中驮配，多采用協(xié)同挖礦模式娘扩。若主鏈已經(jīng)存在，則側(cè)鏈通常是單向錨定主鏈壮锻，即側(cè)鏈錨定了主鏈的數(shù)據(jù)琐旁，但主鏈卻無法識別側(cè)鏈狀態(tài)。

榫卯式更直接猜绣，耦合度也更高灰殴，雙方緊密地綁定在一起，一條鏈的狀態(tài)將直接地反應(yīng)到另外一條鏈的數(shù)據(jù)中掰邢。當(dāng)一條鏈被攻擊時牺陶，另外一條鏈也可能會受到影響伟阔。這種模式更適用于同一個系統(tǒng)的主鏈+側(cè)鏈的設(shè)計，這讓雙方能成為有機的整體掰伸，又不失賬本的相對獨立性皱炉。

主鏈通過礦工可獲取側(cè)鏈的區(qū)塊頭數(shù)據(jù)，并將其存儲在自己的區(qū)塊體中碱工，這樣主鏈在驗證側(cè)鏈的交易時娃承，只需查看自己區(qū)塊體中該側(cè)鏈的區(qū)塊頭信息就能進行交易的驗證（類SPV證明）奏夫，同時也是對側(cè)鏈交易的間接確認(rèn)怕篷。由于主鏈將側(cè)鏈的信息寫入到了自己的區(qū)塊體中，因此酗昼，對于這些數(shù)據(jù)的正確性廊谓，主鏈需要額外地再做一次共識。比如一條聯(lián)盟鏈咬定ETH來給自己增加公信力

保障兩條鏈的資產(chǎn)總量不變

保障資產(chǎn)總量不變麻削，這里面隱含了兩層含義蒸痹，一是在正常的情況下，未被攻擊的情況下如何保障資產(chǎn)總量不變呛哟；二是在異常的情況下叠荠，即受到攻擊的情況下要如何確保資產(chǎn)總量的恒定。

在正常的情況下扫责，雖未受攻擊榛鼎，但還是有網(wǎng)絡(luò)狀態(tài)不穩(wěn)定、宕機鳖孤、部分節(jié)點作惡或者部分用戶作惡等情況的存在者娱，因此，要保障資產(chǎn)總量不變苏揣，必須要確保資產(chǎn)轉(zhuǎn)移的過程在兩條鏈上都是精確記賬黄鳍。拆開了來說，就是要保障

1. 跨鏈交易在兩條鏈上必須是同步的平匈，即交易的原子性框沟，要么都發(fā)生，要么都不發(fā)生增炭。
2. 跨鏈交易在兩條鏈上都是真實有效的街望，被整個網(wǎng)絡(luò)確認(rèn)過大概率有效的，后期分叉的可能性很小弟跑。

所以灾前，正常情況下本章的難點三的解決是依賴于上文提的難點一和難點二的，只要前面兩者可以實現(xiàn)孟辑，難點三就自然不攻而破了哎甲。

具體情況：

在異常情況下蔫敲，假如鏈A已經(jīng)完成了一筆從鏈A到鏈B的跨鏈交易，如下圖所示：

image

隨后鏈A被黑客攻擊發(fā)生了分叉炭玫，之前的跨鏈交易已經(jīng)不在鏈A最長的那條鏈上了奈嘿，那么之前轉(zhuǎn)賬的賬戶可以發(fā)起一筆雙花攻擊，再次給鏈B發(fā)送一筆跨鏈交易吞加，這樣裙犹，鏈B將第二次接收到從鏈A某賬戶發(fā)來的資產(chǎn)，鏈A和鏈B的資產(chǎn)總和將因雙花攻擊而增大衔憨。由于資產(chǎn)總價值不變叶圃，那么鏈B中資產(chǎn)數(shù)量不對等的增多將導(dǎo)致鏈B的資產(chǎn)貶值，鏈B的每一個用戶都要為此次雙花攻擊買單践图。

image

同理掺冠，如果發(fā)生雙花攻擊的是鏈B，則鏈A和鏈B資產(chǎn)總和將減小码党，鏈A轉(zhuǎn)到鏈B的資產(chǎn)由于不在主鏈上德崭，就如同消失了一樣，鏈A上發(fā)起轉(zhuǎn)賬交易的用戶將受到損失揖盘。

image

相應(yīng)的處理眉厨。總體來說兽狭，有以下幾種處理方向：

1. 首先憾股，隔離受攻擊的鏈。由于鏈和鏈之間的通信通常不是直接進行的椭符，而是需要經(jīng)過第三方的荔燎，公證人也好，“中間人”也好销钝，中繼節(jié)點也好有咨，這個第三方角色不僅承擔(dān)了鏈接人的角色，也同時承擔(dān)了隔離者的作用蒸健。當(dāng)發(fā)現(xiàn)某條鏈出現(xiàn)安全問題時座享，隔離者應(yīng)該拒絕該鏈所有的跨鏈交易請求，直至安全問題被解決似忧。

2. 凍結(jié)跨鏈交易創(chuàng)建的失效資產(chǎn)渣叛。對于異常攻擊的第一種情況，鏈B憑空增多了資產(chǎn)盯捌，原因就是之前確認(rèn)過的跨鏈交易由于鏈A重構(gòu)淳衙，交易已然失效，對于這種失效的跨鏈交易，應(yīng)該在鏈B對其相關(guān)資產(chǎn)實施凍結(jié)處理箫攀，以確保資產(chǎn)總量的恒定肠牲。

3. 釋放跨鏈交易凍結(jié)的資產(chǎn)。對于異常攻擊的第二種情況靴跛，鏈A會因為鏈B被攻擊而失去已經(jīng)發(fā)生跨鏈轉(zhuǎn)移的資產(chǎn)缀雳，由3.2小節(jié)可知，實際上鏈A轉(zhuǎn)移的資產(chǎn)是凍結(jié)在鏈A的特殊賬戶里梢睛，如果攻擊發(fā)生后肥印，能釋放凍結(jié)在鏈A特殊賬戶中的資產(chǎn)，即可為鏈A中的用戶挽回?fù)p失绝葡。

以上3種處理思路更多的是邏輯的自洽深碱，而非實際的落地方案。思路1是針對公證人機制而言的挤牛，也是較容易實現(xiàn)的莹痢，目前wanchain等項目已有落地方案种蘸。思路2和思路3的實現(xiàn)相對復(fù)雜墓赴，目前還未有項目發(fā)布具體的技術(shù)實現(xiàn)方案

保障兩條鏈的獨立安全性

在跨鏈交易的過程中保障兩條鏈的安全系數(shù)不會被降低，或者不被過度降低是一個重要的命題航瞭〗胨叮總體說來，可從以下幾個方面進行考慮：

1. 適度隔離刊侯。兩條鏈之間應(yīng)該保持各自的獨立性章办，盡量通過第三方節(jié)點或者獨立的模塊處理跨鏈?zhǔn)聞?wù)，當(dāng)跨鏈交易發(fā)生問題時滨彻，也不會影響鏈本身交易的處理藕届。特別是對于高度耦合的系統(tǒng)設(shè)計，如榫卯式模式亭饵，需要更多地從其他角度進行系統(tǒng)的安全性保證休偶。

2. 檢測安全事件。系統(tǒng)架構(gòu)上做了隔離只是第一步辜羊，重要的是這個第三方節(jié)點或者獨立模塊要具備檢測安全事件的能力踏兜，并且具備響應(yīng)能力。

3. 跨鏈交易正確性八秃。這一點是最基礎(chǔ)的碱妆，只有在保障跨鏈交易正確和安全的前提下才能保障其相關(guān)的區(qū)塊鏈體系不受影響。而這主要由跨鏈交易的原子性以及保障交易最終確認(rèn)性來完成的昔驱，詳情可見上文疹尾，此處不再贅述。

多條鏈之間的跨鏈互聯(lián)

上文討論的主要是兩條鏈之間的互聯(lián)互通，那如何實現(xiàn)多條鏈的連通呢纳本？其實睡雇，這個問題隱藏了兩個潛在問題：一是已經(jīng)存在區(qū)塊鏈系統(tǒng)如何實現(xiàn)互聯(lián)互通；二是對于未來要開發(fā)的區(qū)塊鏈饮醇，如何為其互聯(lián)互通做好準(zhǔn)備和鋪墊它抱。

主動兼容

主動兼容方案是自上而下進行的，主要針對的是已有的區(qū)塊鏈系統(tǒng)朴艰，先有了上層不同的區(qū)塊鏈應(yīng)用系統(tǒng)观蓄，再進行底層的跨鏈機制研發(fā)。通常這些系統(tǒng)都是異構(gòu)鏈祠墅，需要一一進行對接侮穿，不過一一對接也有不同的方案被碗，如下圖左側(cè)所示长赞。

一種是兩兩鏈之間直接進行互聯(lián)搪桂，這種方式若無統(tǒng)一的底層協(xié)議支持空民，是最費時費力的了壶谒，四條鏈之間需要建立6條鏈接通路才可實現(xiàn)兩兩互聯(lián)黔姜，且兩兩之間的通路需要定制化實現(xiàn)甘有。這種方式雖然可擴展性不強律适，但能保障較好的安全性和獨立性腔长，一旦有攻擊事件發(fā)生袭祟，難以影響到整個網(wǎng)絡(luò)。

image

第二種是建立一個第三方跨鏈平臺捞附，鏈和鏈之間都通過這個跨鏈平臺進行間接互聯(lián)巾乳，這樣要實現(xiàn)兩兩之間的互聯(lián)只需要四條鏈接通路即可，如上圖所示鸟召。但這樣胆绊，跨鏈平臺將成為整個跨鏈網(wǎng)絡(luò)的關(guān)鍵點和性能瓶頸（目前還不一定是瓶頸，但未來有可能是）欧募，一旦跨鏈平臺受到攻擊压状，那整個跨鏈網(wǎng)絡(luò)都將陷入癱瘓。

被動兼容

被動兼容方案是自下而上進行設(shè)計的槽片，主要針對的是未來還未開發(fā)的區(qū)塊鏈體系何缓，先搭建好底層的跨鏈平臺，讓其它區(qū)塊鏈系統(tǒng)能簡單还栓、便捷碌廓、安全地接入進來，共享跨鏈平臺的系統(tǒng)便利剩盒。

跨鏈平臺會優(yōu)先將適用于各鏈之間進行互操作的系統(tǒng)和協(xié)議標(biāo)準(zhǔn)開發(fā)出來谷婆，后續(xù)只需在其已有的平臺上進行符合標(biāo)準(zhǔn)的開發(fā)就可建立天然具有系統(tǒng)內(nèi)跨鏈功能的區(qū)塊鏈。

不過這里說到的跨鏈?zhǔn)侵傅姆线@套協(xié)議標(biāo)準(zhǔn)的鏈之間能簡單地互相連通，若是要和該體系外的其它鏈之間進行互操作纪挎，還需要開發(fā)單獨的中間件來進行連通期贫。此外，不同的跨鏈平臺其支持的區(qū)塊鏈類型也可以不同异袄，如Cosmos支持的是同構(gòu)鏈通砍，而Polkadot則可支持異構(gòu)鏈，兩者都有很高的可擴展性

小結(jié)

我們回顧一下前文提到的五個難點與具體解決方案參考：

1. 如何保障跨鏈交易的原子性：介紹了原子互換和哈希時間鎖協(xié)議原理烤蜕。
2. 如何完成對另一條鏈的交易確認(rèn)：介紹了公證人封孙、中繼以及榫卯式三大類模式異同。
3. 如何保障兩條鏈的資產(chǎn)總量不變：從正常和異常兩種情況分別闡述了應(yīng)對方案讽营。
4. 如何保障兩條鏈的獨立安全性：主要從隔離機制和安全檢測機制分析了應(yīng)對思路虎忌。
5. 如何實現(xiàn)多條鏈之間的跨鏈互聯(lián)：介紹了主動兼容和被動兼容兩種跨鏈網(wǎng)絡(luò)建設(shè)方案。

本章從問題出發(fā)梳理了一個跨鏈項目將要面對的主要問題橱鹏，并給出了業(yè)界的一些主流解決方案和解決思路膜蠢。但并不是每個涉及到跨鏈的項目都需要解決以上所有問題，而是各取所需：

1. 若要實現(xiàn)跨鏈資產(chǎn)互換功能莉兰，解決難點一即可挑围；
2. 若要實現(xiàn)跨鏈資產(chǎn)轉(zhuǎn)移，解決難點一和難點二即可
3. 若是能在此基礎(chǔ)上盡量解決難點三和難點四那將得到更安全和穩(wěn)定的系統(tǒng)贮勃；
4. 若要建立一個跨鏈平臺贪惹，那么難點五是必須要考慮的問題苏章。

對跨鏈技術(shù)的研究現(xiàn)在僅僅是個開始寂嘉，跨鏈過程中的眾多難題還需要一步步去解決，特別是跨鏈安全性的研究現(xiàn)在還較為缺失枫绅，期待未來有更多優(yōu)質(zhì)的跨鏈項目能推動區(qū)塊鏈網(wǎng)絡(luò)的建立和完善泉孩。

后續(xù)資料整理集中在具體的技術(shù)實現(xiàn)案例，可參考跨鏈調(diào)研（下）

原文引用自：
【火幣區(qū)塊鏈產(chǎn)業(yè)專題報告】跨鏈篇（上）跨鏈難點解決方案剖析 http://www.reibang.com/p/f2d2e83473fc
【火幣區(qū)塊鏈產(chǎn)業(yè)專題報告】跨鏈篇（下）跨鏈案例解析 http://www.reibang.com/p/b19b1f3cb9c7