焦 梓, 周福才, 王 強

(東北大學 軟件學院, 遼寧 沈陽 110169)

隨著區(qū)塊鏈技術(shù)的蓬勃發(fā)展,市面上出現(xiàn)了大量不同的區(qū)塊鏈.一個現(xiàn)實世界的用戶可能在多個鏈上擁有不同的數(shù)字資產(chǎn).一旦需要將一條鏈上的數(shù)字資產(chǎn)轉(zhuǎn)化為另一條鏈上的數(shù)字資產(chǎn),往往會因為這些區(qū)塊鏈的共識協(xié)議或底層實現(xiàn)技術(shù)的不同,引發(fā)跨鏈交易困難.

一種直觀的解決方案是引入一個可信的第三方,例如一個由機構(gòu)提供的中心化服務器來進行跨鏈交易轉(zhuǎn)換.如Shape shift[1]方案,兩個在不同鏈上的用戶先將其交易請求發(fā)給可信第三方,可信第三方不僅負責驗證用戶擁有足以進行交易的資產(chǎn),而且要確保這是一次等價交換的交易.隨后,在兩條鏈上各發(fā)起一筆鏈上轉(zhuǎn)賬,完成跨鏈交易.由于鏈上交易需要用戶的交易私鑰,所以用戶必須將用于鏈上交易的私鑰發(fā)送給可信第三方.一旦可信第三方遭遇黑客攻擊,或者它本身存在交易欺詐和不誠實行為時,攻擊者可以利用交易私鑰完成任何交易,從而危害用戶的資產(chǎn)安全.

去中心化的跨鏈交易方案不依賴于可信第三方.Tiernolan等[2]提出了基于哈希時間鎖合約(HTLC)[3]的ACCS(atomic cross-chain swaps)方案,該方案雖然是完全無第三方參與的,但HTLC技術(shù)耗時較長,且兩個用戶間完成一次跨鏈交易需要在兩條鏈上各發(fā)生2筆交易,這兩方面的因素顯著增加了跨鏈交易的手續(xù)費和時間開銷.另外,ACCS要求所有用戶在方案執(zhí)行時必須都同時在線上進行,這個限制對參與方案的用戶是不友好的.Lerner[4]提出了利用側(cè)鏈實現(xiàn)去中心化的RSK(root stock)方案,但RSK方案為比特幣專門構(gòu)建了一個用于在礦工收益減半時保證比特幣市場價格的側(cè)鏈.方案中所提出的跨鏈發(fā)生在比特幣和他的側(cè)鏈RSK之間.顯然,兩個現(xiàn)有的鏈無法利用這樣的方案實現(xiàn)跨鏈交易.Zamyatin等[5]提出的XClaim方案雖然移除了中心化的可信第三方,但卻通過任何人都可以注冊成為的見證人vault來監(jiān)督跨鏈交易的過程.vault要提交抵押物以防止其不誠實.XClaim事實上仍然是基于第三方的方案,此外用戶利用XClaim完成一次跨鏈交易,依然要在兩個鏈上發(fā)生多于一次的交易,這增加了交易時間并提高了交易手續(xù)費.

通過以上分析,目前的去中心化跨鏈交易方案存在以下三個問題:①多數(shù)方案往往是針對特定的兩條鏈設(shè)計的,難以適用到任意的兩條鏈;②雖然部分方案使用眾多見證人替代中心化的第三方,但見證人的本質(zhì)依然是第三方,沒有實現(xiàn)真正意義的去中心化;③跨鏈交易耗時長且手續(xù)費開銷大.

針對以上三個問題,論文提出了基于智能合約的跨鏈交易(cross chain exchange based on smart contract,CCE-SC)協(xié)議,包括策略制定、策略同步和區(qū)塊鏈共識驗證三個主要算法.對于以往的方案難以擴展的問題,參與CCE-SC協(xié)議的每條鏈只需部署一個包含資金池模塊、記錄管理模塊、鏈轉(zhuǎn)發(fā)模塊和匯率管理模塊的智能合約,就可實現(xiàn)多條鏈間的跨鏈交易.為了實現(xiàn)跨鏈交易的去中心化,在協(xié)議執(zhí)行過程中,沒有第三方參與.通過實驗與分析,CCE-SC在交易時間和手續(xù)費開銷方面相較于傳統(tǒng)方案均出現(xiàn)有效降低.

1 智能合約及鏈轉(zhuǎn)發(fā)技術(shù)

1.1 智能合約

智能合約的概念最早由Szabo[6]于1997年提出,最初被描述為一個由自動執(zhí)行的計算機程序所組成的無需信任的系統(tǒng).系統(tǒng)可以驗證合約的合法性,并執(zhí)行合法合約中的指令.然而這個構(gòu)想直到2015年以以太坊(Ethereum)[7]為代表的第二代區(qū)塊鏈的出現(xiàn)才成為現(xiàn)實.智能合約與傳統(tǒng)程序相比有諸多不同,例如代碼一旦被發(fā)布在區(qū)塊鏈上以后就不可進行更改以及智能合約執(zhí)行結(jié)果的正確性和可靠性由區(qū)塊鏈保證.不同的區(qū)塊鏈的智能合約有其對應的編程語言,以太坊智能合約的開發(fā)語言以Solidity[8]為主.Solidity代碼先經(jīng)過編譯轉(zhuǎn)化成類似匯編的低級字節(jié)碼,隨后以交易的形式發(fā)布到以太坊上,一旦智能合約部署成功,它將獲得一個160位的地址標志.以太坊上的用戶只要調(diào)用這個地址,并輔以相關(guān)參數(shù)即可在EVM(ethereum virtual machine)[9]中執(zhí)行智能合約.

1.2 鏈轉(zhuǎn)發(fā)技術(shù)

在交易結(jié)束前,鎖定用于跨鏈交易的資金是避免用戶產(chǎn)生損失的通用方法.鎖定操作在區(qū)塊鏈上的具體實現(xiàn)形式是向一個確定的賬戶或智能合約地址轉(zhuǎn)賬.參與跨鏈交易的某條鏈需要利用鏈轉(zhuǎn)發(fā)技術(shù)(chain relay)確認另一條鏈上用于此次交易的資產(chǎn)是否已經(jīng)鎖定完成.以BTCRelay[10]為代表的鏈轉(zhuǎn)發(fā)技術(shù)需要部署一個智能合約,合約上保存有另一條鏈上全部的區(qū)塊頭.

鏈轉(zhuǎn)發(fā)合約的參與者包含轉(zhuǎn)發(fā)者和驗證者兩種,轉(zhuǎn)發(fā)者負責提交另一條鏈的區(qū)塊頭信息,驗證者負責驗證調(diào)用合約的用戶提交的交易信息和交易對應的Merkle哈希樹路徑[11].驗證者要進行兩種驗證:交易包含驗證和共識驗證.交易包含驗證的目的是驗證用戶提交的交易存在于特定區(qū)塊中;共識驗證的目的是確保用戶提交的交易所在的區(qū)塊已經(jīng)被另外一條鏈的共識機制所接納.通過這兩項驗證的交易可認為是已被另一條鏈真實采納的交易.鏈轉(zhuǎn)發(fā)技術(shù)是一種去中心化的社區(qū)自治可信方案.

2 CCE-SC協(xié)議

2.1 CCE-SC協(xié)議

CCE-SC協(xié)議系統(tǒng)由3個實體構(gòu)成:區(qū)塊鏈、智能合約和參與跨鏈交易的用戶.

區(qū)塊鏈:底層區(qū)塊鏈提供基礎(chǔ)轉(zhuǎn)賬功能并保證轉(zhuǎn)賬的安全可靠.參與協(xié)議的兩條區(qū)塊鏈需要支持智能合約,本協(xié)議的實現(xiàn)無需修改區(qū)塊鏈本身.

智能合約:參與協(xié)議的兩條鏈各需部署一個智能合約,負責為用戶提交的跨鏈交易請求制定跨鏈交易策略;另外,智能合約通過鏈轉(zhuǎn)發(fā)技術(shù)同步到另一條鏈上交易策略的執(zhí)行狀態(tài)和區(qū)塊鏈共識情況以便為對應用戶支付跨鏈資產(chǎn).

用戶:協(xié)議運行后,兩條區(qū)塊鏈上都有眾多隨時向智能合約提交跨鏈交易請求的用戶,用戶在提交請求的同時,還要提交用于交易的本鏈資產(chǎn)并提供另一條鏈上的收款地址.

基于智能合約的跨鏈交易(CCE-SC)協(xié)議系統(tǒng)交易流程如圖1所示.

①用戶向原資產(chǎn)所在鏈發(fā)送跨鏈交易請求,并同時提交用于跨鏈交易的資產(chǎn);

②用戶使用另一條鏈上的收款地址接收跨鏈資產(chǎn);

③ 智能合約為參與跨鏈交易的用戶們制定跨鏈交易策略;

④智能合約使用鏈轉(zhuǎn)發(fā)技術(shù)同步另一條鏈的狀態(tài)及協(xié)議執(zhí)行情況;

⑤智能合約使用鏈轉(zhuǎn)發(fā)技術(shù)為制定好的跨鏈交易策略進行區(qū)塊鏈共識驗證.

圖1 協(xié)議系統(tǒng)交易流程

2.2 協(xié)議模型

本協(xié)議主要由策略制定算法、策略同步算法和區(qū)塊鏈共識驗證算法三個主要算法組成.CCE-SC 協(xié)議可形式化描述為 CCE-SC=(MkSTG, Syn, Cons).下面對協(xié)議的3個算法進行形式化定義.

1) 策略制定算法:STself←MkSTG(Reqself, Reqsyn)為確定性算法.輸入本鏈用戶請求Reqself和同步來的另一條鏈上尚未加入策略的用戶請求Reqsyn,輸出本鏈策略表STself.

2) 策略同步算法:ST′←Syn(STsyn, Reqself, Reqsyn)為確定性算法.輸入通過鏈轉(zhuǎn)發(fā)技術(shù)同步來的由另一條鏈制定的策略表STsyn,本鏈用戶請求Reqself和同步來的另一條鏈的用戶請求Reqsyn,輸出本鏈對STsyn的采納結(jié)果ST′.

3) 區(qū)塊鏈共識驗證算法:tag←Cons(ST,KA,KB)為確定性算法.輸入為兩條鏈均認可的策略ST,兩條鏈的安全參數(shù)KA和KB,輸出策略ST是否已經(jīng)安全包含在兩條鏈上的判斷布爾值tag∈{true, false}.

3 關(guān)鍵算法描述

CCE-SC協(xié)議涉及的3個主要算法的實現(xiàn)依賴智能合約.為使算法描述更為清晰,同時減少現(xiàn)實中協(xié)議實現(xiàn)代碼的耦合性,智能合約的設(shè)計應包含如圖2所示的4個模塊:資金池模塊(pool)、記錄管理模塊(record manager)(簡記為RM模塊)、鏈轉(zhuǎn)發(fā)模塊(chain-relay)(簡記為CR模塊)和匯率管理模塊(oracle).模塊間的連接線表示在協(xié)議運行時存在交互.

圖2 智能合約模塊設(shè)計

資金池模塊主要用于對資產(chǎn)直接的操作,并維護一個由資產(chǎn)組成的資金池.鏈轉(zhuǎn)發(fā)模塊用于同步另一條鏈的狀態(tài).匯率管理模塊用于協(xié)商參與協(xié)議的兩條鏈資產(chǎn)的兌換比例.記錄管理模塊用于記錄用戶請求及策略制定和執(zhí)行情況,利用record函數(shù)將請求記錄在智能合約上,記錄的格式是{ timestamp, src, dst, amount, split_p, blocknum, hash, state}.參數(shù)依次代表請求時間戳,請求發(fā)送者地址,B鏈上的收款地址,用于交易的A鏈資產(chǎn)數(shù)量,請求分割情況,提出請求時A鏈的區(qū)塊號,請求哈希和請求執(zhí)行狀態(tài).新請求的state為0.在關(guān)鍵算法描述中會對模塊中包含的函數(shù)進行解釋.算法涉及的符號定義如表1所示.

3.1 策略制定算法

策略制定算法MkSTG(Reqself, Reqsyn):請求發(fā)起鏈A上的用戶提交跨鏈交易請求后由aSC調(diào)用.算法的主要工作是將A鏈提交的請求Reqself與鏈轉(zhuǎn)發(fā)模塊同步來的B鏈尚未加入交換策略的請求Reqsyn進行匹配,以生成策略STself.具體算法執(zhí)行步驟如下:

1) 將用戶提交的請求加入到請求隊列request_list中.

2) 驗證B鏈是否生成了新塊,若產(chǎn)生了新塊則通過CR模塊將B鏈上尚未加入策略中的請求同步到request_list中.

3) 依據(jù)匯率管理模塊提供的匯率,對request_list中來自不同鏈的請求進行匹配以生成交易策略.因為現(xiàn)實世界中幾乎找不到價值完全相同的請求,所以需要對請求進行分割,執(zhí)行如下操作:

①aSC分別選取一個A鏈和B鏈請求ReqA,ReqB;

②匯率管理模塊計算ReqA和ReqB包含的價值,假設(shè)計算結(jié)果顯示ReqA包含的資產(chǎn)價值更高;

表1 符號說明

4)A鏈的RM模塊將經(jīng)過以上步驟得到的包含相等資產(chǎn)價值的A鏈和B鏈請求的狀態(tài)屬性state設(shè)置為1,表明它們被加入了策略STself.

5)A鏈持續(xù)為用戶上傳的請求制定策略,當A鏈產(chǎn)生新塊后,B鏈可同步到A鏈RM模塊中記錄及記錄狀態(tài)的變化.B鏈選取記錄狀態(tài)為1的請求構(gòu)成集合STsyn后依據(jù)策略同步算法進行策略協(xié)商.對記錄狀態(tài)為0的請求,B鏈將進行策略制定.

策略制定算法偽代碼:

01A鏈上的用戶向aSC發(fā)送ReqA,資金池模塊鎖定AssetA并記錄ReqA;02Pool.getReq(ReqA,AssetA);03request_list<>←RM.record(ReqA);04若B鏈產(chǎn)生了新區(qū)塊:05request_list<>←synchronize(B);06從兩條鏈上各取一個請求,分割包含資金較多的請求并制定交換策略STself;07ReqA←RM.from(request_list<>, A);08ReqB←RM.from(request_list<>, B);09Reqp1A←Pool.split(ReqA, ReqB);10ReqA. split_p=Reqp1A,Reqp1A. split_p=NULL;11STself← makeStrategy(Reqp1A, ReqB);12Reqp1A.state=1, ReqB.state=1;13request_list<>←RM.record(Reqp1A);14request_list<>←RM.record(ReqB).

3.2 策略同步算法

具體算法執(zhí)行步驟如下:

1)A鏈CR模塊在B鏈產(chǎn)生新塊后,將同步獲得bSC中RM模塊存儲的請求記錄.

2) 使用RM模塊將STsyn使用的請求依據(jù)發(fā)起位置分為來自A鏈的請求RequestA和來自B鏈的請求RequestB兩類.

3) 對于STsyn使用的每個來自B鏈的ReqB,驗證請求對應的TxReqB真實存在于B鏈區(qū)塊中.若STsyn使用的請求來自分割后的請求,還需要驗證分割的合法性.

4) 調(diào)用匯率管理模塊計算RequestA中全部請求對應B鏈資產(chǎn)價值是否等價于RequestB的資產(chǎn)價值.

5) aSC將STsyn使用的全部請求狀態(tài)更改為2,表示A鏈認同STsyn.

圖3 策略同步算法流程圖

策略同步算法偽代碼:

01request_list<>← CR.synchronize(B)02for all i∈[request_list.length]03 if request_list[i].state=2 and RMi.state=104 RMi.state=205 if request_list[i].state=1 and (RMi=1 or not exist)06 RequestA← RM.from(request_list[i], A)07 SumA +=request_list[i].amount08RequestB← RM.from(request_list[i], B)09 SumB +=request_list[i].amount10for all j∈[RequestB.length] and RMinot exists11 若RequestB[j]對應的交易TxReqB確實在B鏈上12for all j∈[RequestB.length] and RMi=113 RM.verifySplit(RequestB[j])14 匯率管理模塊驗證:15 Oracle.rate(SumA)=SumB16RMi.state=217else RM.changeStrategy(request_list<>)

3.3 區(qū)塊鏈共識驗證算法

區(qū)塊鏈共識驗證算法Cons(ST,KA,KB):CR模塊執(zhí)行該算法.判斷兩條鏈經(jīng)協(xié)商產(chǎn)生的最終交換策略ST是否被安全包含在兩條鏈上的依據(jù)是:A鏈與B鏈都達到了各自的安全參數(shù)KA和KB.安全參數(shù)[12]指第i個區(qū)塊被認為安全的包含到區(qū)塊鏈上直到第j個區(qū)塊的產(chǎn)生,其中j-i≥K.對于比特幣[13]而言KBTC為6,以太坊的安全參數(shù)KETH為12.具體算法執(zhí)行步驟如下:

1)A鏈CR模塊獲取B鏈最新的區(qū)塊.

2) CR模塊判斷ST′所在A鏈和B鏈區(qū)塊是否均達到安全參數(shù)KA和KB.先判斷出ST′已安全包含在兩條區(qū)塊鏈的鏈A(假設(shè)是A鏈).ST′內(nèi)的請求state屬性為3,表明已確認待支付狀態(tài).

3)B鏈同步到ST′狀態(tài)的變化后,B鏈資金池模塊為ST′中ReqA支付對應資產(chǎn).

4)B.RM模塊設(shè)置ST′中包含的全部請求狀態(tài)為已支付(state=4).

5)A鏈會在下一次同步后獲悉B鏈已支付,并執(zhí)行步驟3)和步驟4).

6) 最終算法輸出跨鏈交易完成判斷標志tag∈{true, false}.

區(qū)塊鏈共識驗證算法偽代碼:

01request_list<>← CR.synchronize(B)02if CR.reachK(A.ST′, A)=true andCR.reachK(B.ST′, B)=true03 for any Req[i]in A.ST′04 Req[i].state=305 bSC進行如下操作:06request_list<>← CR.synchronize(A)07if CR.reachK(A.ST′, A)=true ANDCR.reachK(B.ST′, B)=true08Pool.pay(ST′)09 for any Req[i]in B.ST′10 Req[i].state=411aSC進行如下操作:12Pool.pay(ST′)13for any Req[i]in A.ST′14 Req[i].state=415錯誤時處理: Pool.rollback()

4 協(xié)議測試與分析

本協(xié)議在有2臺實體機構(gòu)建的實驗環(huán)境中進行測試,實體機硬件配置:Intel(R)Core(TM)i7 CPU 10510 @ 1.8 GHz處理器,16 GB內(nèi)存;實體機軟件環(huán)境:Windows 10 64位操作系統(tǒng).跨鏈交易的兩條區(qū)塊鏈為經(jīng)常被用來做跨鏈交易的以太坊(ETH)和以太坊經(jīng)典(ETC).截止到2021年4月26日,ETH和ETC的平均出塊時間、平均手續(xù)費和原生幣的價值如表2所示.理論上本方案與傳統(tǒng)方案在交易時間效率和交易手續(xù)費開銷的對比如表3所示.

表2 ETH和ETC基本信息

表3 協(xié)議與傳統(tǒng)方案的對比

通過實驗,測試使用CCE-SC的用戶將ETH資產(chǎn)與ETC資產(chǎn)交易的時間效率和手續(xù)費開銷.實驗中,在ETH和ETC上使用Ganache隨機生成400個用戶地址和400個收款地址,由coinbase為每個用戶地址隨機分配一定資產(chǎn)用于跨鏈交易.智能合約中匯率管理模塊內(nèi)的匯率rate(ETH,ETC)=79.411 783 44.由于ETH和ETC的現(xiàn)實價值差別較大,每個ETH用戶隨機分配0.5～1個ETH,每個ETC用戶根據(jù)兩條鏈的資產(chǎn)匯率比例隨機分配39.7～79.4個ETC,在進行跨鏈交易時假定每個用戶投入全部資產(chǎn).由于現(xiàn)實中區(qū)塊鏈上的交易是隨時涌進的,為體現(xiàn)這一動態(tài)過程,設(shè)置每條鏈上每秒有一名用戶發(fā)起跨鏈交易請求.為保證測試中每個新塊中包含12～19個本鏈請求,CR模塊能同步到12～19個來自另一條的請求.

實驗結(jié)果如圖4和圖5所示,一個用戶使用CCE-SC協(xié)議安全交換到另一條鏈資產(chǎn)所需時間平均為452 s,手續(xù)費開銷平均為28.378美元.CCE-SC相較于傳統(tǒng)的ACCS[3]和XClaim[5]方案在交易時間和交易手續(xù)費方面都有下降.CCE-SC與XClaim方案在手續(xù)費開銷方面較為接近的原因是:實驗采用的以太坊與以太坊經(jīng)典的現(xiàn)實價值差距過大.理論上每進行一次跨鏈交易,CCE-SC比XClaim方案只少花費約0.005 2美元,和XClaim方案一次跨鏈交易就需要約28.39美元相比,手續(xù)費開銷較為接近.

圖4 三種方案交易手續(xù)費總開銷與交易次數(shù)的關(guān)系

圖5 三種方案總交易時間與交易次數(shù)的關(guān)系

ETH用戶利用CCE-SC協(xié)議提交的跨鏈請求在經(jīng)歷策略制定算法、策略同步算法和區(qū)塊鏈共識算法后,最終在ETC上完成支付.策略制定和策略同步的總時間最短為2ΔETH,受到網(wǎng)絡(luò)延時或者兩條鏈出塊順序排列的影響,最長為4ΔETH.區(qū)塊鏈共識到智能合約支付最短時間為12ΔETH,最長為14ΔETH.再加上支付所需要的安全時間12ΔETH,ETH上的用戶自發(fā)起跨鏈交易請求到能安全收到ETC資產(chǎn)的總時間最短為2ΔETH+12ΔETH+12ΔETH=26ΔETH.最長時間為4ΔETH+14ΔETH+12ΔETH=30ΔETH.

在協(xié)議安全性方面,區(qū)塊鏈網(wǎng)絡(luò)中各節(jié)點間是不可信的,定義敵手Eve可能對協(xié)議進行攻擊的2個事件:

event1:敵手篡改偽造請求或交換策略.

event2:敵手在交換策略協(xié)商階段中斷請求.

對于event1,假設(shè)A鏈上一個合法的請求是request0,敵手使用算法E篡改或偽造后的請求是request1.敵手隨機選擇b←{0,1},并將requestb提交給協(xié)議的智能合約(SC).智能合約輸出b′∈{0,1}表示其采納了request0或request1.

對于event2,若敵手在交換策略協(xié)商階段中斷了請求,則在制定交換策略時對應請求就會被移除.所以CCE-SC協(xié)議可以保證誠實的參與者在敵手的攻擊下不蒙受任何損失.

5 結(jié) 語

本文在研究了去中心化傳統(tǒng)跨鏈交易方案的基礎(chǔ)上,通過在參與跨鏈交易的兩條區(qū)塊鏈各自部署一個智能合約,解決了傳統(tǒng)方案難以推廣的問題.在協(xié)議運行的全過程中無第三方參與,實現(xiàn)了真正意義上的去中心化跨鏈交易.同時,因為用戶僅需要向原資產(chǎn)所在鏈發(fā)送一次跨鏈交易請求就能在另一條鏈上收到對應價值的資產(chǎn),使得交易時間和手續(xù)費開銷相較于傳統(tǒng)方案均出現(xiàn)有效降低.