面向區塊鏈輕節點的支付通道瞭望塔技術研究*

解巖凱,魏凌波,2,張 馳,王慶濤,孫啟彬

1.中國科學技術大學 網絡空間安全學院,合肥 230027

2.中國電子科技南湖研究院,嘉興 341000

1 引言

中本聰于2008年發表比特幣(bitcoin,BTC)的白皮書[1],宣告了基于區塊鏈的加密貨幣的誕生.得益于區塊鏈去中心化、不可篡改與公開透明等特點,加密貨幣受到了越來越多的關注.截止2021年2月,使用加密貨幣的人數已經超過了六千萬[2].但隨著用戶規模與交易數量的快速增長,加密貨幣的低交易吞吐量成為亟待解決的重要問題.由于區塊大小與區塊產生時間均受到限制,比特幣交易驗證速度平均只能達到7筆/秒,只相當于現有中心化支付系統VISA的約七千分之一[3].雖然第二代加密貨幣以太坊實現了更高的交易吞吐量,但目前平均交易速度也僅為11.5筆/秒[4,5].以上數據表明,低交易吞吐量是主流加密貨幣面臨的共性問題.

由于P2P網絡中消息傳播速度的限制以及節點性能的影響,直接對區塊鏈進行擴容的方案會導致區塊鏈系統安全性、可靠性和去中心化程度的下降,因此無法在比特幣社區中得到一致認同.以擴展區塊大小為例,如果比特幣希望達到與VISA相同的交易吞吐量,則比特幣需要在出塊時間不變的前提下將區塊擴大至8 GB,但是幾乎沒有多少礦工有能力承受維護這樣的區塊鏈帶來的巨額成本,這將使比特幣網絡去中心化程度急劇下降,甚至回歸中心化支付系統[3].正是基于這個原因,比特幣歷史上對區塊鏈進行直接擴容的方案[6-10]均無法在比特幣社區得到一致認同.加密貨幣低吞吐量的問題意味著加密貨幣的一部分交易將無法及時被記入鏈上[11],用戶需要通過增加交易費的方式提高交易寫入區塊鏈的優先級,目前比特幣交易的平均交易費已經超過19美元1數據來源于https://www.blockchain.com/charts/fees-usd-per-transaction,訪問時間2021年3月18日..低交易吞吐量與高交易費問題嚴重制約了小額交易與高頻交易在區塊鏈網絡上中的生存.

由于直接對區塊鏈擴容的方案存在上述問題,區塊鏈研究者提出了鏈下方案[12].鏈下方案在不改變區塊鏈共識規則的前提下將當前區塊鏈上的交易轉移至鏈外處理.鏈下方案主要分為側鏈[13]與支付通道網絡[3]兩大類,支付通道網絡在交易速度、隱私性和效率等方面均優于側鏈[14].支付通道網絡是由運行支付通道節點軟件的節點形成的對等網絡,節點通過支付通道[15]與其他節點形成點對點連接.支付通道允許交易雙方改變支付通道內資金的結算方案實現鏈下交易(off-chain transaction),區塊鏈只記錄通道的開啟和關閉,并對鏈下交易提供安全保障.交易雙方只將創建與關閉支付通道的交易寫入區塊鏈,而鏈下交易數目沒有任何限制,這從根本上解決了區塊鏈低吞吐量和高交易費的問題[16],為小額交易與高頻交易在區塊鏈網絡上的應用提供了很好的解決方案.

為了避免支付通道中一方離線而導致另一方無法關閉支付通道取回資金,支付通道允許參與者在任意時刻公布支付通道的最新狀態獨立關閉支付通道.但是區塊鏈無法判斷被提交的狀態是否是最新的,惡意的支付通道參與者可能向區塊鏈公布過期的狀態關閉支付通道,從而獲得本不應屬于他的通道份額.為了解決這個問題,關閉通道的交易擁有一個特殊的爭議時間(dispute period)屬性,公布了關閉通道交易的一方的資金在爭議時間內會被凍結,這使得通道內誠實的用戶可以在爭議時間內取出凍結的資金,挽回惡意關閉通道交易可能造成的損失,并懲罰惡意的參與者.這樣的安全保障機制要求通道參與者必須在每段爭議時間內至少監視一次區塊鏈,否則參與者可能無法發現已經被提交上鏈的惡意關閉通道交易或是來不及對鏈上的惡意交易進行反制.但在現實應用場景中,運行在手機等資源受限設備上的輕節點難以在每段爭議時間內都同步區塊鏈,因此他們在參與支付通道時存在資金損失風險.截止到2021年,比特幣網絡中僅有10 126個能夠持續同步區塊鏈的“活躍”全節點,以太坊中“活躍”的全節點只有6061個2數據來源于https://etherscan.io/charts,訪問時間2021年3月18日.,這還不到加密貨幣總用戶數的0.1%.可見大部分區塊鏈用戶使用支付通道實現鏈下交易時存在安全隱患,提高支付通道的安全性迫在眉睫.

為解決無法實時監聽區塊鏈帶來的安全隱患,輕節點可以將監聽惡意交易的任務外包給一個被稱為“瞭望塔”(watchtower)的第三方[17].瞭望塔是一個或一組特殊的全節點,他們作為代理協助輕節點監視區塊鏈,一旦發現支付通道以過期的狀態進行結算,就啟動支付通道的安全保障機制,幫助用戶挽回損失并懲罰惡意參與者.雖然瞭望塔的引入提升了輕節點的安全性,但卻帶來了額外的安全與隱私泄露問題.首先,瞭望塔可能對支付通道安全性造成影響.如果瞭望塔是一個可信第三方,則支付通道的安全隱患已被解決,輕節點可以隨意離線而不必擔心支付通道被惡意關閉.但在現實中,瞭望塔和支付通道參與者均不一定是可信的,瞭望塔可能會消極怠工,或是和通道中的惡意節點合謀令誠實節點蒙受損失.其次,瞭望塔亦存在泄露用戶隱私的可能.為了保證支付通道安全性,瞭望塔需要收集支付通道的更新日志以便于識別惡意關閉通道交易,但這侵犯了用戶的隱私,瞭望塔可以獲知通道內交易的內容,進而推斷用戶在真實世界的身份[18].最后,應用于比特幣支付通道的瞭望塔存在效率問題.比特幣支付通道瞭望塔需要保存支付通道的每一次更新才能幫助用戶挽回損失以及懲罰惡意的參與者,這代表著為多個用戶服務的比特幣瞭望塔需要存儲龐大的更新日志,并在每個新區塊產生后都遍歷一次數據庫方可完成監視.因此,如何降低存儲與計算開銷也是比特幣支付通道瞭望塔協議設計的關鍵一環.

截至目前已有大量的綜述總結了近年來支付通道的研究進展[14,19,20],但僅有Gudgeon等人[12]在其關于支付通道的綜述中介紹了瞭望塔的概念,并認為瞭望塔是解決支付通道安全問題的可行方案.但Gudgeon等人的綜述主要圍繞支付通道方案展開,并未對瞭望塔方案進行深入的研究,因此本文填補了支付通道網絡中瞭望塔方面綜述的空白.

瞭望塔方案設計需考慮支付通道的安全性、通道參與者的隱私性和瞭望塔的效率,已有的瞭望塔方案均試圖解決其中一個或多個問題.本文對目前支付通道網絡中各類瞭望塔方案進行了整理,基于方案的應用背景將其分為比特幣中的瞭望塔和以太坊中的瞭望塔兩大類,詳細闡述了每種方案的原理,并從隱私性、安全性與效率等多個角度衡量兩類方案的優劣.最后,我們對瞭望塔的未來研究進行了展望,提出了可行的研究思路.

2 支付通道技術簡介

支付通道允許交易雙方執行鏈下交易,進而降低交易費,提升交易速度.目前比較成熟的支付通道技術有比特幣閃電網絡中的支付通道[3]和以太坊的狀態通道[21]等.接下來我們分別概述比特幣和以太坊中的支付通道.

2.1 比特幣中的支付通道

比特幣支付通道中交易雙方通過多重簽名腳本建立一個聯合賬戶以鎖定資金,每次雙方進行交易,他們在鏈下更新該賬戶中資金的分配方案,并簽署新的承諾交易(commitment transaction)以完成分配狀態的更新.如圖1所示,在比特幣區塊鏈中,我們假設愛麗絲(以下簡稱A)和鮑勃(以下簡稱B)分別向支付通道中注入了0.5個比特幣(交易中黑底白字黑框代表已簽名,白底黑字黑框代表花費輸出需要的簽名),此時支付通道中總共擁有1個比特幣,其中0.5個屬于A,0.5個屬于B.一旦A和B發生了鏈下交易,A和B更新支付通道中的資金分配方案,簽署新的承諾交易.如果A和B不再進行交易了,他們將通道中最后一個承諾交易用作通道結算交易,并向區塊鏈廣播,將支付通道中鎖定的資金結算給交易雙方.

圖1 支付通道概述Figure 1 Payment channel overview

只要交易雙方沒有關閉支付通道,他們就可以生成新的承諾交易來改變支付通道中資金的分配方案.所有承諾交易除輸出不同外并無實質性差別,因此過期的承諾交易并不隨著新承諾交易生成而自動作廢,支付通道中惡意的一方可以在最新承諾交易被記入區塊鏈前向區塊鏈提交對自己更為有利的過期承諾交易,由于過期的承諾交易也是合法交易,因此也能通過比特幣礦工驗證并記入新區塊,這最終會導致誠實參與者蒙受損失.為了避免這種情況的發生,支付通道通過設計序列到期可撤銷合約(revocable sequence maturity contract,RSMC)引入爭議時間,以實現承諾交易的安全更新.

RSMC定義了三類交易:承諾交易、可撤銷的交付交易(revocable delivery transaction)和違約補救交易(breach remedy transaction).承諾交易的功能與前文是一致的,但為了保護誠實通道參與者的資金安全,承諾交易會將承諾交易發布者應得的通道份額輸出到通道參與者的新共同賬戶中,而另一個通道參與者的通道份額則可以立即到賬.可撤銷的交付交易允許承諾交易發布者將承諾交易輸出到共同賬戶中的資金取出,但這筆交易只有在鎖定時間過后才能上鏈,因此承諾交易發布者的通道份額會被鎖定一段時間,RSMC中這段鎖定時間被稱為通道爭議期,也就是爭議時間.違約補救交易的作用是對過期承諾交易進行反制.每當生成新的承諾交易后,交易雙方交換生成違約補救交易所需要的密鑰以作廢過期的承諾交易.如果惡意的參與者提交一筆過期的承諾交易,在爭議期內另一個參與者只需向區塊鏈提交與過期承諾交易對應的違約補救交易就可以獲得支付通道內的全部份額,這不僅挽回了損失還懲罰了惡意參與者;如果上鏈的是最新的承諾交易,通道參與者則無法生成對應的違約補救交易,因此提交承諾交易的參與者可以在爭議期過后將通道中自己的份額取出.

然而,只有在爭議時間內提交違約補救交易,違約補救交易才會生效.這是因為如果提交承諾交易的一方是誠實的,即公布了最新的承諾交易,那么區塊鏈不能無限期凍結其資金.這也避免了另一方突然掉線而導致提交承諾交易的一方無法結算支付通道內資金的問題.但這也意味著即使惡意的一方向區塊鏈提交了一筆過期的承諾交易,如果爭議時間內另一方沒有向區塊鏈提交違約補救交易以取出鎖定資金,其依然會遭受資金損失.為了防止這種攻擊,交易雙方需要實時監視區塊鏈,以監測對方是否公布過期的承諾交易.如果B在爭議時間內始終離線,那么惡意的一方就可以公布一筆過期的承諾交易實現對另一方的攻擊.

2.2 以太坊中的支付通道

通過智能合約,Miller等人[21]將比特幣中的支付通道拓展到以太坊為代表的第二代區塊鏈中.將支付通道建立在智能合約上有三點優勢:第一,智能合約大幅簡化了通道鏈下更新的流程.通過在交易中維護一個名為“狀態”的遞增參數,以太坊中的支付通道可以在生成新鏈下交易的同時直接將舊承諾交易作廢.由于智能合約可以通過比對狀態參數的大小來判斷鏈下交易發生的時序3與以太坊支付通道思路相同,Decker等人使用浮動交易對比特幣支付通道進行改進,從而將交易時序引入比特幣支付通道中,簡化了通道鏈下更新流程[22].但目前比特幣區塊鏈并不支持浮動交易,因此該方案并不能直接用于比特幣區塊鏈.,因此對過期交易的反制只需向智能合約提交狀態參數更大的交易即可完成,支付通道參與者只需存儲狀態通道的最新狀態,這也最小化了用戶的存儲.第二,智能合約還可以允許用戶根據其需求設計更為復雜的金融衍生工具,例如期權、擔保交易和對賭協議等.第三,由于智能合約的圖靈完備性,建構于智能合約的支付通道還可以允許多于兩名參與者在同一個通道內執行鏈下交易.正因為基于智能合約的支付通道在合約中維護的狀態參數,這類支付通道又被稱為“狀態通道”[21].

總的來說,支付通道不僅僅提升了區塊鏈的吞吐量,還提升了區塊鏈用戶的交易效率以及隱私保護[23].相比于鏈上交易,支付通道使交易雙方在限額內實現不限數量的鏈下交易,而只需要負擔支付通道創建交易以及結算交易的交易費.此外,支付通道也顯著增強了區塊鏈的支付速度.區塊鏈常規交易需要幾十秒乃至數十分鐘才能被區塊鏈確認,而基于支付通道的支付可以在數毫秒之內完成[24].最后,該方案還能增強用戶隱私保護效果.通過支付通道與其他節點相連的用戶可以形成支付通道網絡,交易雙方并不需要向區塊鏈提交交易建立直接的支付通道,而是通過現有支付通道網絡進行支付,此時所有的交易都是鏈下進行的,因此全節點無法通過公開的區塊鏈獲取任何用戶的交易信息,這也契合了加密貨幣最大化保護用戶隱私的設計目標[25].

3 原始瞭望塔協議概述與其面臨的挑戰

運行在手機等資源受限設備中的輕節點無法保證時實在線并監視區塊鏈.只要輕節點的離線時間大于爭議時間,就可能面臨丟失通道資金的風險.為規避上述風險,通道參與者可以設置較長的爭議時間以避免損失,然而這會極大降低通道結算效率.但是對于輕節點來說,更長的通道結算時間將導致輕節點面臨更大的通道資金安全性風險.如果輕節點的離線時間超過了爭議時間,那么他就可能損失通道內屬于他的部分乃至全部資金.為解決長時間離線問題,輕節點會將監視操作外包給時時在線的瞭望塔.一旦支付通道中的惡意參與者在輕節點離線時公布過期承諾交易,瞭望塔就可以監測到這種行為,代替用戶向區塊鏈提交違約補救交易,挽回輕節點的損失,并懲罰惡意的用戶.

文獻[17]中給出了原始的瞭望塔的實現.在比特幣支付通道中,用戶需要將每一筆過期承諾交易對應的違約補救交易上傳到瞭望塔中.瞭望塔實時監測區塊鏈中每一筆交易,并與違約補救交易中的地址進行匹配.一旦匹配到過期的承諾交易,瞭望塔就將對應的違約補救交易提交到區塊鏈來進行反制.舉個例子,交易方A和B通過RSMC建立了一個支付通道:如圖2所示,在支付通道初始化時會生成了實線框中的所有交易,帶有A標識的弧線框交易為A持有的交易,帶有B標識的直角框交易為B持有的交易.對于A來說,即使B不響應,她也可以向區塊鏈提交承諾交易1A獨立關閉支付通道,當承諾交易A被區塊鏈確認后,B立即得到支付通道中他的份額,而A的資金會被提交到一個新的多簽名地址(A1,B1)中,只有在承諾交易1A被確認1000個區塊后,礦工才會接受A提交的可撤銷的交付交易并將其寫入新區塊內,允許A將多簽名地址(A1,B1)中的資金提取到自己的地址中4這是通過比特幣交易輸入中的Sequence_no屬性實現的,支付通道參與者可以根據需求靈活配置爭議時間..同理,如果B向區塊鏈提交承諾交易1B,A會立即得到她的份額,而B的資金也會被凍結相同的時間.

圖2 瞭望塔參與的支付通道更新流程Figure 2 Watchtower-based payment channel workflow

當支付通道更新時,交易雙方需要作廢代表更新前狀態的承諾交易,即生成作廢更新前狀態的對應違約補救交易,并將該違約補救交易上傳到瞭望塔中.例如,當支付通道更新至承諾交易2A與2B時,交易雙方需要將過期的承諾交易1A和1B作廢.為實現這樣的目標,通道雙方需要交換過期承諾交易1A與1B的多簽名輸出中各自的私鑰,進而允許交易雙方生成針對過期承諾交易的違約補救交易來處理違約.具體地說,A需要將過期承諾交易1A中自己的公鑰A1對應的私鑰發送給B;同理,B亦需要將公鑰B2對應的私鑰發送給A.為了避免實時監視區塊鏈帶來的開銷,交易雙方可以使用私鑰生成過期承諾交易對應的違約補救交易,并上傳到瞭望塔中.每次更新交易雙方都會重復這種操作,上傳作廢每一個對應過期承諾交易的違約補救交易至瞭望塔中.瞭望塔實時監測區塊鏈中每一筆交易,并與違約補救交易中的地址進行匹配.如果發現匹配,則提交對應的違約補救交易幫助用戶挽回損失.例如,一旦A發布過期承諾交易1A,實時監測區塊鏈的瞭望塔就會捕捉到這筆過期的承諾交易,他會將收到的違約補救交易1B提交到區塊鏈中,將(A1,B1)中的0.5個比特幣全部轉移到B的地址中.而公布過期承諾交易1A的A由于沒有公鑰B1對應的私鑰,因此只能等待承諾交易1A被確認1000次之后,才能提交可撤銷的交付交易1A提現(A1,B1)中的全部比特幣.此時,即使B不監視區塊鏈,他也不會損失任何資金.

不幸的是,這種簡單的瞭望塔機制存在諸多問題.在效率方面,由于使用的密鑰不同,因此每一個過期的承諾交易對應唯一的違約補救交易,因此瞭望塔需要存儲全部的違約補救交易,并在新區塊產生后遍歷支付通道中所有的違約補救交易進行匹配,這為瞭望塔帶來了巨大的開銷.雖然瞭望塔開發者重新設計了違約補救交易的存儲結構,壓縮了瞭望塔存儲違約補救交易的開銷,但是存儲一筆違約補救交易仍需要300-350字節.只要支付通道沒有結算,瞭望塔就必須存儲所有的違約補救交易.隨著支付通道數目的不斷增長,瞭望塔的存儲壓力也會不斷增大.不僅如此,一旦一筆承諾交易被提交到區塊鏈,瞭望塔就需要遍歷整個數據庫.隨著數據庫規模的增加,交易匹配也需要越來越多的計算資源[26].

構建于以太坊狀態通道之上的原始瞭望塔不存在效率問題.與比特幣支付通道瞭望塔不同,基于智能合約以太坊狀態通道瞭望塔繼承了狀態通道的優點,最小化了瞭望塔存儲的數據量進而提升了效率.舉個例子,如圖3所示,在A,B和C參與的狀態通道中,每次交易后他們三個共同生成新的通道份額分配方案,更新狀態序號并對其進行簽名.隨后通道參與者將最新的狀態信息上傳到瞭望塔,在接受到最新的狀態信息后瞭望塔就可以刪除舊狀態最小化其存儲開銷.一旦惡意的參與者(假設為A)發布過期的狀態state2,實時監測區塊鏈的瞭望塔就會捕捉到這種行為,并向合約提交最新狀態state3.由于瞭望塔提交了狀態序號大于2的狀態,則A的鏈上更新請求無效,在爭議時間結束后通道以狀態序號最高的狀態進行結算.如果爭議時間內沒有新于state3的狀態被提交,則通道合約將把state3視為最新的合法狀態并將其記錄到區塊鏈上,完成狀態的鏈上結算.

圖3 瞭望塔參與的狀態通道更新流程Figure 3 Watchtower-based state channel workflow

這兩種原始瞭望塔都面臨著隱私和安全問題.在隱私方面,將監視任務外包給瞭望塔會泄露用戶的隱私.簡單來說,每次支付通道的更新都會產生新的違約補救交易,或者最新狀態,用戶需要將全部更新信息提交給瞭望塔以便于瞭望塔提供監視服務.然而,通過用戶每次提交的更新信息,瞭望塔可以了解用戶支付通道的全部狀態變化,進而推斷出用戶進行的每一筆交易信息,造成對用戶隱私的侵犯.更重要的是,將監視任務外包給原始瞭望塔還面臨安全隱患.信任單一瞭望塔違反了區塊鏈去中心化的原則:如果瞭望塔因為網絡等故障而無法監視區塊鏈,或者欺騙用戶而實際上不監視區塊鏈,甚至與支付通道中惡意的一方共謀,這都將導致用戶遭受無法索賠的資金損失.而且原始瞭望塔協議無法幫助用戶收集證據,來向瞭望塔追償[27].一種可行的方案是讓用戶與多個瞭望塔相連,只要有一個瞭望塔是誠實的,用戶的資金就是安全的.最后,激勵機制也會影響支付通道資金的安全,若沒有足夠的激勵,瞭望塔就沒有動力為用戶提供服務.

針對文獻[17]中原始瞭望塔的缺陷,區塊鏈開發者已經提出了多種解決方案.我們搜集了目前的瞭望塔解決方案[26-34],根據其底層支付通道的不同,將它們分為比特幣支付通道瞭望塔協議和以太坊狀態通道瞭望塔協議兩大類,并從瞭望塔效率、鏈下交易隱私保護以及支付通道資金安全性等三個方面衡量每一種方案.接下來我們首先介紹兩類支付通道瞭望塔協議.

4 比特幣支付通道瞭望塔協議

針對原始比特幣支付通道瞭望塔存在的隱私、安全性與效率問題,比特幣開發者提出了許多解決方案.由于解決瞭望塔的效率挑戰是通過減少上傳到瞭望塔的數據實現的,這必然提升了用戶隱私.因此,我們把隱私和效率視為一個整體,將這些方案按其核心側重點分為隱私提升方案以及安全提升方案,并分別闡述方案的實現細節以及優缺點.

4.1 隱私提升方案

為了保護用戶的鏈下交易隱私,比特幣開發者利用比特幣部分操作符的特性改進了瞭望塔協議.Dryja[28]提出使用過期承諾交易的ID(transaction ID,TXID)作為密鑰來加密違約補救交易,以提升輕節點的隱私保護效果.

當支付通道更新時,B就使用過期承諾交易的TXID加密對應的違約補救交易,并將其提交給瞭望塔.只要A是誠實的,她就不會將過期的承諾交易提交到區塊鏈中.那么瞭望塔就無法獲取解密違約補救交易所需的TXID,因此瞭望塔無法獲知交易雙方的通道份額.一旦A提交了過期的承諾交易(即A希望竊取B的資金),瞭望塔就可以從區塊鏈中獲取過期承諾交易的TXID,并用該TXID解密對應的違約補救交易并將其提交到區塊鏈中挽回B的損失.除了提交到公開區塊鏈中的交易信息,瞭望塔無法破解其余承諾交易.如果B擁有多個支付通道,這樣還可以隱藏每個支付通道的更新頻率,因為瞭望塔無法通過加密數據定位更新的支付通道.故該瞭望塔方案最大程度地保護了用戶的隱私.

為了安全提取對方過期承諾交易的TXID,Dryja的瞭望塔方案還使用了隔離見證技術[35].隔離見證技術通過引入SIGHASH_NOINPUT操作符,將交易的TXID與簽名分離,B只需要知道A過期承諾交易對應的輸入輸出,即可計算出交易的TXID.由于沒有簽名,B亦無法惡意公布A持有的過期承諾交易以竊取A在支付通道中的份額.隔離見證技術解決了TXID獲取過程中的安全性問題,是Dryja的瞭望塔方案的基石.

另一方面,雖然支付通道中資金分配方案信息熵較低,但即使瞭望塔猜中違約補救交易對應的過期承諾交易中的資金分配方案,他也無法推導出過期承諾交易的TXID,解密對應的違約補救交易獲得隱私數據佐證其猜測.如圖2所示,在承諾交易每次更新時,A和B每次都會隨機生成新的一次性地址鎖定交易輸出,這是因為作廢舊狀態需要向對方公布鎖定輸出地址對應的私鑰.由于這些地址在區塊鏈上從未出現過,因此瞭望塔無法猜測過期交易使用的地址.即使瞭望塔猜中過期承諾交易中的資金分配方案,他也無法猜中隨機生成的地址,故無法推導出TXID來破壞B的隱私.

雖然Dryja的瞭望塔方案提升了輕節點的隱私保護效果,但瞭望塔所需的資源仍是整個系統的瓶頸.每當監測到一筆承諾交易,瞭望塔就需要提取其TXID,并遍歷數據庫中存儲的全部加密信息以提取違約補救交易.由于引入了加密算法,這種方法所需的計算資源更多;另一方面,這種方法也會增加瞭望塔的存儲開銷.最后,沒有支付通道參與方的幫助,瞭望塔無法識別已關閉的支付通道對應的違約補救交易,因為它們被TXID加密.這帶來了額外的存儲開銷.

Khabbazian等人在Dryja的瞭望塔方案基礎上提出了Outpost協議[26],在保護用戶隱私的前提下顯著提升了瞭望塔效率.在Outpost協議中,瞭望塔僅存儲解密違約補救交易的密鑰,提交承諾交易的一方必須向區塊鏈提交一筆數據輸出交易(通過OP_RETURN操作符實現)才可以關閉支付通道提取相應份額,數據輸出交易以密文的形式記錄了對應的違約補救交易.如果上鏈的是過期的承諾交易以及相應數據輸出交易,瞭望塔就可以使用用戶提交的密鑰解密違約補救交易.因此這種方案顯著提升瞭望塔的存儲效率,且沒有犧牲用戶的隱私.

該方案重新設計了比特幣支付通道的更新支付通道的流程以及鏈下交易的數據結構,使得提交承諾交易的一方必須向區塊鏈提交數據輸出交易,否則他無法提取支付通道中的份額.如圖4所示,新承諾交易有三個輸出,除了原有的兩個結算輸出,該方案使用第三個輸出生成一筆數據輸出交易以記錄當前承諾交易的違約補救交易.為了保證惡意的支付通道參與者A一定需要生成并公布數據輸出交易,數據輸出交易包含另一個有少量比特幣的輸出,A在提取其支付通道余額時必須將該輸入包含在可撤銷的交付交易的輸入中,否則她將無法關閉支付通道.可撤銷的交付交易的兩個輸入存在兩個相互獨立的鎖定時間,只有這兩個鎖定都解除,參與者A才能夠提交可撤銷的交付交易取回資金.在這兩個鎖定時間形成的爭議期間內,只要瞭望塔監視到這筆數據輸出交易,他就可以從中提取違約補救交易并將其提交到區塊鏈,幫助合法用戶挽回損失.

圖4 Outpost方案示例Figure 4 Outpost scheme overview

在該方案中,違約補救交易以密文的形式被打包到數據輸出交易中,這是為了保證誠實的用戶能夠正常關閉支付通道.如前所述,當前承諾交易對應的數據輸出交易記錄的是當前承諾交易的違約補救交易,如果違約補救交易是以明文存儲的,當A公布最新的承諾交易時B就可以從數據輸出交易中提取違約補救交易以竊取A的資金.為了避免這種情況,A會加密違約補救交易.當支付通道更新時,交易雙方不僅要交換過期承諾交易中鎖定輸出地址的私鑰,還需要交換加密違約補救交易的密鑰.在每次更新支付通道后,B只需要將128比特的密鑰上傳給瞭望塔.相比于動輒幾百字節的違約補救交易,該方案顯著壓縮了瞭望塔的存儲開銷.此外,該方案也繼承了Dryja的瞭望塔中的隱私保護的特性,除了被提交到區塊鏈中用于關閉支付通道的承諾交易,瞭望塔無法破解B的鏈下交易內容.

總的來說,Outpost協議顯著提升了瞭望塔效率以及用戶隱私,并與現有比特幣區塊鏈完全兼容.但是這類方案沒有討論瞭望塔面臨的資金安全隱患:信任單一瞭望塔違反了區塊鏈去中心化的原則[36,37].并且這類方案缺乏針對惡意瞭望塔反制措施:假使瞭望塔不作為,甚至共謀則導致用戶資金損失,用戶也無法收集證據向瞭望塔索賠.

4.2 安全提升方案

為了解決原始瞭望塔方案中存在的安全隱患,Avarikioti等人首次將分布式理念引入瞭望塔協議中,為支付通道中的資金提供了更強的安全保障.安全性提升的另一種思路是通過引入保證金作為抵押,即使用戶因瞭望塔不作為等原因損失了通道中的份額,他仍可以向區塊鏈提交瞭望塔違約的證據,從而獲得瞭望塔的保證金以補償損失.

4.2.1 分布式瞭望塔協議

單一瞭望塔架構在瞭望塔不作為或共謀的情況下存在安全問題,將單一瞭望塔擴充為一組瞭望塔節點形成的分布式瞭望塔系統可以為用戶提供更強的安全保障.Avarikioti等人在2018年首次提出分布式瞭望塔協議DCWC[29]以提升支付通道的安全性,并設計了相應的激勵機制獎勵誠實的瞭望塔:為支付通道安全做出貢獻的瞭望塔可以參與分配支付通道中惡意參與者的份額.在DCWC中,只要有一個瞭望塔是誠實的,惡意參與者就無法竊取用戶的資金.

DCWC中的違約補救交易是由支付通道參與者B生成,并層層轉發到多個瞭望塔的.如果支付通道的另一個參與者A違約,先收到違約補救交易的瞭望塔有優先追索權與優先受償權.換句話說,按照接收到違約補救交易的順序,瞭望塔形成了一個隊列.當區塊鏈中出現過期的承諾交易時,只有隊列前端的瞭望塔不作為,后續瞭望塔才能獲得相應激勵份額.舉個例子,如果B向瞭望塔W1提交了違約補救交易,這筆違約補救交易經由瞭望塔W2傳播到瞭望塔W3.如果A違約,并且W1履行了他的義務,他將獲得全部的獎勵.如果W1在規定的時間內不作為,W2最終幫助B挽回了損失,那么W1獲得轉發獎勵,W2獲得支付通道中A剩余的份額.只有當W1與W2皆不作為時,W3才會獲得獎勵.

這種瞭望塔的激勵策略是通過切割爭議時間實現的.其分配方式如圖5所示:當A違約時,按照協議,所有瞭望塔都會向區塊鏈提交違約補救交易,我們假設違約補救交易中有1.5 BTC的輸出用于激勵瞭望塔.激活該輸出的解鎖腳本有兩種策略:如果瞭望塔W1實時在線,他就可以向區塊鏈提交交易T11提取所有獎勵.若在區塊鏈生成s個區塊后,W1仍未提取這筆輸出,這代表W1實際上掉線了,違約補救交易是后續瞭望塔提交的.在這種情況下,后續瞭望塔可以提交交易T12,此時W1僅獲得轉發獎勵,即0.5個比特幣.同樣,對于瞭望塔W2,他同樣有生成s個區塊的時間提取剩余全部獎勵.若未提取,在扣除轉發獎勵后,通道內剩余比特幣會被提交給后續瞭望塔進行分配.以此類推直至最后一個瞭望塔.所有生成s個區塊對應時間之和即支付通道的爭議時間.

圖5 DCWC方案示例Figure 5 DCWC scheme overview

使用樹狀結構代替隊列可以進一步提升支付通道的安全.在例子中,每個瞭望塔僅轉發了一次違約補救交易,而在實際情況中,每個瞭望塔可以向多個瞭望塔轉發違約補救交易,進而形成一個樹.引入更多的瞭望塔進一步保證了用戶的通道資金安全.不同分支中的瞭望塔是相互競爭的,換句話說,只有一條分支中的瞭望塔會獲得獎勵.

但是DCWC的激勵措施缺乏吸引力,這會使DCWC方案在現實中無法達到預期的安全水平.由于瞭望塔只能從參與者惡意行為中獲利,而理性的參與者并不會作惡,因此DCWC中的瞭望塔并無穩定的期望收益.另一方面,DCWC中越靠近葉子節點的瞭望塔存儲壓力會越大,而期望收益卻越少.如圖5所示,對于瞭望塔W2,他不僅僅需要存儲違約補救交易,還需要存儲交易T12.以此類推,相比于W2,瞭望塔W3需要再多存儲一筆交易.總的來說,越靠近葉子節點的瞭望塔,所需要存儲的交易就越多,由于需要向父節點分配轉發獎勵,其獲得的獎勵卻更少.綜上所述,理性瞭望塔不會參與這種協議[31],在現實中實現DCWC幾乎是不可能的.

Leinweber等人認為可以通過分布式瞭望塔和可信執行環境(trusted execution environments,TEE)設計可靠的日志審查機制,以解決瞭望塔不作為的問題.該方案在現有瞭望塔系統中引入日志機制,通過日志審查識別不作為的瞭望塔.為了保證日志的可靠性,他們提出結合TEE,例如目前最受歡迎的Intel SGX[39],設計可靠的瞭望塔日志審查系統[30].簡單來說,通過在服務器內部TEE運行瞭望塔以及日志程序,進而為用戶提供可審查的瞭望塔服務.為了避免服務器中不可信部分干擾TEE中的代碼執行,TEE被設計為與操作系統分開的隔離部分,以確保TEE中處理的數據不被具有特權的操作系統識別、修改.換句話說,具有管理權限的服務提供者不能影響TEE中信任代碼的執行和輸出,也不能識別其內部數據或者篡改其內部狀態,因此惡意的服務器無法干擾TEE內部的日志生成程序,進而保證了日志的準確性.

但是依靠單一瞭望塔仍無法為用戶提供強安全保證.這是因為惡意的服務器可以切斷TEE與外部的通信,或者切斷電源.不僅如此,由于TEE內部存儲空間有限,因此TEE會將日志數據外包到不可信的外部存儲中.盡管惡意的服務器無法篡改日志,但是他可以刪除這些數據.為了解決這個問題,該方案將單瞭望塔擴展為分布式瞭望塔,從而為用戶提供支付通道的強安全保障以及可靠的日志審查服務.當區塊鏈產生新的區塊,或者支付通道的狀態發生更新,瞭望塔之間會互相審查并創建相關的審查日志,并對其進行簽名.通過對比不同瞭望塔之間的日志數據,用戶就可以驗證瞭望塔是否持續監視區塊鏈.

該方案亦利用TEE保護其內部數據機密性的特點,結合了BOLT#3方案[39]中的密鑰推導算法生成RSMC中進行鏈下交易所需的密鑰集,壓縮了瞭望塔的存儲開銷,并保護了用戶的隱私.只需要一個前面都是字節的種子,支付通道參與者就可以使用BOLT#3方案中的密鑰推導算法生成248?1對公私鑰,這完全滿足支付通道更新的需求.因此,在支付通道初始化時,運行在TEE中的瞭望塔只需要獲取支付通道雙方的私鑰種子.如果支付通道惡意的一方A提交過期的承諾交易,TEE使用種子生成對應私鑰,進而生成對應違約補救交易,并將其提交到區塊鏈幫助瞭望塔用戶B挽回損失.相比于Outpost協議,這種方案進一步壓縮了瞭望塔的存儲開銷.由于TEE只按照規定的代碼提供瞭望塔服務,具有管理權限的服務提供者也不能識別TEE內部數據,因此惡意的服務器也無法獲知支付通道雙方用于更新支付通道的密鑰種子,亦無法窺探用戶隱私.

雖然這種方案可以允許用戶識別不作為的瞭望塔,但是使用這種瞭望塔的用戶仍需要向多個瞭望塔支付服務費.此外,信任TEE可能會威脅支付通道雙方的資金安全.目前有很多研究者指出SGX面臨信息泄露風險[40-44].如果惡意的服務器能夠識別SGX內部的數據,這不僅僅破壞了用戶的隱私,攻擊者還可以獲取支付通道雙方用于更新支付通道的私鑰種子,進而竊取其在支付通道中的資金.

4.2.2 保證金擔保方案

文獻[31]借鑒了以太坊狀態通道瞭望塔PISA[29]的設計思路,提出了Cerberus channel方案,該方案通過重新設計比特幣支付通道協議,將保證金機制引入到比特幣支付通道瞭望塔中以增強瞭望塔安全性.在提供服務前,瞭望塔通過抵押交易將一大筆擔保金鎖定在與用戶形成的聯合賬戶中,作為瞭望塔提供服務的擔保.與之前的方案不同,在該方案中瞭望塔需要參與支付通道的更新環節:當支付通道更新時,交易雙方與瞭望塔不僅要生成新的承諾交易、可撤銷的交付交易、違約補救交易,還需要生成對應反制瞭望塔的懲罰交易.在關閉支付通道結算通道內余額時,即使A公布承諾交易,B亦無法直接獲得屬于他的通道余額.只有在爭議時間過后,或者獲得瞭望塔的簽名授權,他才能夠提取屬于他的份額.這是為了便于反制惡意的瞭望塔:舉個例子,如圖6所示,如果A公布過期的承諾交易,若在爭議時間內瞭望塔不作為,B就可以在一個索賠時限內公布懲罰交易,進而沒收保證金以彌補損失.如果瞭望塔及時向區塊鏈提交了違約補救交易,即使B再向區塊鏈提交懲罰交易,這筆交易也不會被區塊鏈接受,因為他們花費了一筆相同的輸出.

圖6 Cerberus channels方案示例Figure 6 Cerberus channels scheme overview

需要注意的是,比特幣區塊鏈也不能無限鎖定瞭望塔的保證金,在索賠時限后瞭望塔就可以贖回保證金,但用戶索賠的時間期限遠大于支付通道的爭議解決時限.總的來說,該方案繼承了PISA方案的部分優點:通過引入保證金擔保的瞭望塔,在沒有增加爭議時間的前提下延長了用戶的離線時間,在沒有犧牲通道資金靈活性的前提下提升了安全性.

另一方面,惡意的支付通道雙方無法騙取誠實瞭望塔的保證金.首先,如果A是誠實的,B是無法通過公布懲罰交易騙取誠實瞭望塔的保證金.如果沒有過期的承諾交易,懲罰交易花費的輸出就是不存在的,自然不會被區塊鏈礦工接受.其次,即使A和B共謀,他們也無法騙取瞭望塔保證金.這是因為瞭望塔需要參與支付通道的每一次更新.換句話說,沒有瞭望塔的幫助,他們無法更新支付通道生成新的懲罰交易.因此,只要瞭望塔實時監測區塊鏈,惡意的支付通道雙方不可能騙取瞭望塔保證金.

雖然該方案保證了用戶資金安全,但并不保護用戶隱私,因為瞭望塔需要參與每一次支付通道的更新.此外,該方案不僅增加了瞭望塔的存儲與計算壓力,還增加了用戶的存儲開銷.不僅瞭望塔需要存儲全部的違約補救交易,用戶也需要存儲全部的懲罰交易,以保證支付通道被惡意關閉時能索取保證金補償.

5 以太坊狀態通道瞭望塔協議

以太坊智能合約的引入使得瞭望塔可以同時兼顧用戶的隱私性與安全性.在隱私性方面,通過使用哈希函數重新設計狀態通道合約以及通道結算流程,瞭望塔無需知曉承諾交易的細節,亦可保證用戶的通道資金安全.而在安全性方面,借助智能合約,開發者引入了保證金機制,即使瞭望塔未及時對過期交易做出反制,用戶亦可以向合約提交瞭望塔違約的證據,來提取瞭望塔抵押在智能合約中的保證金,從而獲得補償.

5.1 隱私提升方案

最早的基于智能合約的瞭望塔由McCorry等人提出,作者設計了名為PISA的瞭望塔方案[27],來改善以太坊支付通道瞭望塔中存在的隱私問題.PISA調整了狀態通道的結算流程,通道參與者只需向合約上傳包含所有參與者簽名的狀態序號,以及狀態序號對應的支付通道狀態的哈希值即可開啟鏈上結算.舉個例子,在支付通道參與者進行狀態更新的時候,瞭望塔用戶只需要上傳所有通道參與者簽名的狀態序號以及哈希值即可.在爭議時間內,瞭望塔也僅需向合約發送上述最新的狀態信息(包括狀態序號和狀態哈希值)即可完成對過期交易的反制,狀態哈希值的原像將在爭議時間過后才需要被發送至區塊鏈上.這樣的調整使得瞭望塔只需要獲得最新狀態的哈希值,以及所有通道參與者對哈希值的簽名,即可擁有反制過期狀態的能力,而不再需要獲知完整的狀態,從而最大化通道參與者的隱私.此外,這樣的設計還減少了鏈上內容對通道參與者隱私的泄露,因為不成功的鏈上強制結算請求將不再泄露狀態的內容.

然而,簡單地將通道狀態替換為狀態的哈希值并不能很好地保護通道參與者的隱私.這是因為通道中資金分配方案信息熵較低,瞭望塔可以枚舉通道可能的狀態并計算哈希值.通過與狀態通道參與者上傳的哈希值進行比較,瞭望塔就可以獲知通道參與者的資金分配狀態,也就破壞了通道參與者的隱私.為此,通道參與者向支付通道狀態中添加了一個隨機數以提升隱私.簡單來說,狀態哈希值對應的原象中包含了一個隨機數用于最大化分配狀態的信息熵.在這種情況下,即使瞭望塔猜中對應狀態中的資金分配方案,他也無法猜中該隨機數,故無法推導出狀態哈希來破壞其用戶的隱私.

另一方面,PISA中的瞭望塔還引入了保證金機制以進一步提升用戶資金安全性.簡單來說,通過維護一個保證金合約賬戶實現保證金的抵押機制,一個瞭望塔的所有服務都在同一個合約賬戶上完成,這樣獨立又唯一的賬戶設置有利于瞭望塔宣傳與開展服務.如圖7所示,在提供服務前,瞭望塔需要向保證金合約中存入一大筆保證金,以作為瞭望塔提供服務的擔保.當B向瞭望塔訂購服務時,他需要向瞭望塔發送需要瞭望塔監視的通道狀態哈希值hstate3和所有參與者對該狀態的簽名供瞭望塔使用,這表示state2及之前的狀態不應被用于通道鏈上更新.如果瞭望塔同意提供服務,瞭望塔會向B發送一個用自己私鑰簽名的收據,這個收據包含了瞭望塔應該監視的通道狀態信息,隨后雙方建立一個單向支付通道供B支付服務費.在向B發送收據后,瞭望塔監視區塊鏈上與通道合約相關的交易,一旦發現A將hstate2用于鏈上狀態更新,瞭望塔就可以在通道的爭議解決時限前提交{hstate3,3}和所有參與者對{hstate3,3}的簽名來完成對過期狀態hstate2的反制.一旦B發現瞭望塔沒有完成監視通道的任務,他可以在一個索賠時限內向保證金合約提供這個收據和狀態通道當前狀態,證明瞭望塔不作為,從而將瞭望塔鎖定在保證金合約里的保證金取出,而瞭望塔只能在這個索賠時限后才能贖回保證金.需要注意的是,B索賠的時間期限應遠大于狀態通道的爭議解決時限.總的來說,PISA通過引入保證金機制,在沒有犧牲通道資金靈活性的前提下提升了安全性.

圖7 PISA方案示例Figure 7 PISA scheme overview

相比于之前的方案,PISA瞭望塔方案在實現了強安全性的同時保護了用戶的隱私.首先,由于持有瞭望塔簽名過的收據,用戶可以在瞭望塔未正常提供服務后通過保證金合約單方面取走瞭望塔的保證金.其次,狀態通道參與者也無法私下更新狀態通道進而騙取瞭望塔的保證金,因為只要不上傳最新狀態,他們就無法獲得帶有瞭望塔簽名的收據,保證金合約不會接受沒有瞭望塔簽名收據的索賠請求.基于以上兩點,用戶與瞭望塔的資金安全都得到了保障.在隱私性方面,PISA中的瞭望塔只會獲得狀態的哈希值而無法獲知狀態的內容,這有效地維護了通道的隱私性.除此以外,相比于分布式瞭望塔協議,該方案顯著降低了用戶服務費.只需要一個瞭望塔,該方案就能提供合理的安全保障,另外,用戶只有在更新狀態時才需要付費,這種付費機制對于絕大部分交易量不大的用戶也更為友好.

但PISA方案設計存在兩個核心缺陷.首先,PISA瞭望塔可以向多個通道提供服務,這些通道中包含的資金總額可能超過瞭望塔抵押的保證金,這使得保證金帶來的安全性擔保會隨著用戶數量增多而嚴重減弱.當瞭望塔對多個用戶不作為時,后提交證據的用戶將無錢可取,這是PISA方案最致命的安全漏洞.第二,瞭望塔用戶需要監視瞭望塔是否正常工作,雖然用戶索賠的時間期限長于通道爭議期限,但用戶仍不能完全離線.PISA方案只是延長了用戶可以安全離線的時間,但并未從根本上解決用戶無法離線的問題.

5.2 安全提升方案

Avarikioti等人提出了BRICK方案,該方案通過引入分布式瞭望塔機制實現了比PISA更強的安全性保證[32].BRICK方案將瞭望塔從單個節點擴充為多個節點構成的委員會,并假設委員會中至少三分之二以上的節點是誠實的.與PISA不同,BRICK方案采取了“主動防御”策略:瞭望塔不再對過期交易進行反制,而是讓過期交易無法被合約接受,從根本上失去上鏈的可能.為此,該方案直接讓瞭望塔委員會介入鏈下狀態更新與鏈上通道關閉中.在鏈下狀態更新環節,每個通道參與者都需要將包含所有參與者簽名的通道狀態哈希hstatei發送給瞭望塔委員會并等待委員會成員對hstatei進行簽名,只有超過t個委員會成員簽名的狀態才被視為合法狀態,t是綜合考慮委員會成員離線或懷有惡意等問題后設定的閾值,一般按照拜占庭容錯機制設置為瞭望塔節點總數的三分之二.對于鏈上關閉通道環節,如果關閉通道的close(statei)指令集齊了所有通道參與者的簽名,則通道無需經過委員會即可關閉.如果參與者無法集齊簽名,則任何通道參與者都可以將當前通道狀態statei連同一個關閉通道請求發送給委員會成員.委員會成員會在一個共識周期內驗證此狀態是否為他們簽署過的最新通道狀態,所有認同statei的委員會成員對statei簽名并發送給通道參與者,只有收集到超過t個委員會成員簽名的關閉通道請求才會被合約接受,完成委員會批準的通道關閉操作.

BRICK方案的安全性來源于分布式系統和保證金兩個方面.與單瞭望塔相比,這種分布式瞭望塔能夠在三分之一的節點是惡意的情況下提供可靠的服務,而進行惡意行為的瞭望塔節點也會在初次作惡后被沒收保證金并開除出瞭望塔委員會.這說明BRICK方案的安全性不再完全依賴于瞭望塔抵押的保證金,與PISA方案相比實現了更高的安全性保證.與此同時,分布式的瞭望塔設計使得瞭望塔委員會抵押的保證金由全部瞭望塔節點分攤,單一瞭望塔不在需要抵押大額保證金.但BRICK沒有設計與分布式瞭望塔相匹配的激勵機制,而是讓全部參與簽署新狀態的瞭望塔均攤用戶的服務費.在不提升用戶服務費總額的情況下,這種方案在實際中很難部署.

Liu等人提出了Fail-safe方案[33]進一步減少了BRICK中所需的用戶服務費.該方案通過引入審查機制進而使用單一瞭望塔取代了瞭望塔委員會.在Fail-safe方案中,瞭望塔不但需要介入鏈下狀態更新與鏈上通道關閉,它還必須定期向通道合約發送通道最新狀態序列號,并以此來向通道參與者證明其可靠性.

然而fail-safe方案只能提供與PISA方案相同的安全性保障.因為審查機制并不能保證瞭望塔不與惡意的參與者共謀,用戶仍需監視區塊鏈來收集瞭望塔違約的證據.因此Fail-safe方案在安全性保證方面和PISA完全相同,將安全性完全依托于瞭望塔抵押的保證金.不僅如此,定期向保證金合約提交最新狀態序列號還增加了運行瞭望塔的成本,如果狀態通道的參與者交易頻率不高,提交狀態所需要的交易費可能超過直接進行鏈上交易所需的交易費.

從整體上講,雖然瞭望塔方案可以通過保證金機制實現更強的安全保障,但必須超過所有用戶通道內資金總和的高額保證金也極大地增加了瞭望塔運營的成本,使瞭望塔運營者面臨巨大的資金壓力.因此,如何降低瞭望塔運行成本并實現強安全性保障是這些方案面臨的一個十分重要的待解決問題.

6 總結與展望

為了保證輕節點能夠安全地使用支付通道進行交易,區塊鏈開發者提出了瞭望塔技術.但瞭望塔技術設計面臨效率、用戶鏈下交易隱私以及用戶通道資金安全三個挑戰.本文系統地整理了自支付通道瞭望塔出現以來關于瞭望塔的研究進展,根據其底層支付通道的不同將其分為比特幣支付通道的瞭望塔技術和以太坊支付通道的瞭望塔技術,詳細闡述了每一種瞭望塔技術的原理,并將這些方案納入到統一的框架中進行比較,為了方便讀者比較,我們繪制了表1展示這些方案的優勢以及缺陷.

表1 各方案性能對比Table 1 Comparison of each watchtower scheme

在比特幣支付通道瞭望塔中,現有的解決方案只能解決瞭望塔面臨的部分挑戰.由表1所示,Dryja的瞭望塔顯著提升了用戶隱私保護效果,Outpost協議在此基礎上引入數據輸出交易進一步提升了瞭望塔效率,DCWC瞭望塔與Cerberus瞭望塔分別使用分布式協議以及保證金機制提升了用戶資金安全性.但是這些方案均無法在高隱私性低開銷的前提下實現高安全性,僅有基于TEE的方案可以同時實現瞭望塔設計的這三個目標.然而該方案將用戶私鑰托管入TEE中,這將用戶的通道資金安全完全托付于TEE,這種TEE的使用策略至今尚有爭議,不斷涌現出對TEE的側信道攻擊手段使得基于TEE的方案面臨安全挑戰[44].一旦攻擊者通過側信道攻擊破解TEE中存儲的私鑰,攻擊者就可以竊取支付通道中的資金.

在以太坊狀態通道中,雖然基于保證金的方案可以為瞭望塔用戶提供高資金安全性保證,但它們也顯著增加了運行瞭望塔的成本,終將提升用戶服務費,而這可能超過了用戶自己運行一個全節點的成本,進而降低了瞭望塔的吸引力.不僅如此,除了服務費更高的BRICK方案,其余方案僅僅提升了支付通道參與者監視區塊鏈的間隔,并不能允許用戶徹底離線.

綜上所述,支付通道的瞭望塔技術通過引入第三方(即瞭望塔)的方式為支付通道用戶提供了一道額外的安全防線.然而,由于瞭望塔并不一定可信,因此將監視區塊鏈的任務委托給瞭望塔并不能保證用戶鏈下交易的安全.除此以外,瞭望塔的介入所導致的鏈下交易隱私泄露,和第三方提供服務的效率也同樣是瞭望塔技術亟待解決的關鍵問題.目前已有的方案均未能同時兼顧安全性、隱私性與效率,這說明瞭望塔技術尚需進一步完善.完善現有的瞭望塔技術可以從以下兩個方面入手:

第一種思路是設計可約束瞭望塔行為的協議.為了避免因瞭望塔的不可信或不作為而導致用戶通道資金或者交易隱私遭受損失,約束瞭望塔的行為或許是一種可行的思路.舉例來說,使用TEE設計瞭望塔協議可以實現約束瞭望塔行為的目標,提供可信執行的TEE不會執行惡意的操作.雖然目前學術界已經存在基于TEE的瞭望塔方案[30],但該方案將用戶私鑰托管于TEE中,雖然提升了瞭望塔的效率,但無法抵抗對TEE的側信道攻擊,這是此方案的核心缺陷.因此,如何在TEE不持有用戶私鑰的情況下,設計高效的基于TEE瞭望塔方案,是未來瞭望塔技術的研究熱點.更加抽象地說,將TEE視為一道額外的安全防線,而不是完全取代現有的安全機制[45],或許是將TEE應用至瞭望塔領域的可靠思路.這樣,即使TEE出現安全漏洞,系統的信任假設也只會收縮至未使用TEE之前,而不會威脅支付通道參與者的資金安全.

另一種思路是改進現有的保證金體系.現有基于保證金的瞭望塔運行成本過高,且并沒有完全免除用戶監視區塊鏈的責任.通過引入信譽擔保機制取代保證金擔保機制可以降低瞭望塔的押金成本,并為用戶提供可靠的擔保.目前,基于區塊鏈的身份信譽系統已有諸多詳盡的研究,最受歡迎的區塊鏈自主身份管理系統如uPort[46]與ShoCard[47]已經在學術界和商業界都有較大的影響力,并積累了一定的用戶群體.這些身份系統允許瞭望塔運行者將其身份信息綁定到區塊鏈中,從而以其身份信譽取代或部分取代基于保證金的擔保機制.假使瞭望塔作惡,其作惡的證據將會被永遠記錄在區塊鏈中,用戶可以隨時同步區塊鏈收集瞭望塔作惡的證據,并根據瞭望塔身份信息向其索賠.由于瞭望塔的身份信息與作惡的證據會被永遠記錄在區塊鏈中,用戶可以在任意時間同步區塊鏈收集證據,并向瞭望塔運行者索賠.這種設計思路不僅通過身份信譽作為抵押降低了運行瞭望塔的成本,也進一步減輕了用戶定期監視區塊鏈的責任,因此值得進一步研究.

得益于交易速度、隱私性、效率等方面的優勢,支付通道協議已經成為鏈下擴容的研究熱點.作為支撐區塊鏈支付通道協議中不可或缺的一環,瞭望塔技術近年來也得到廣泛關注和大量研究.本文系統梳理了區塊鏈瞭望塔技術的主要進展,詳細分析了現有瞭望塔技術的不足,并對其發展趨勢進行了展望,從而為研究人員和開發者提供有用參考.