哈希時間鎖起源於閃電網絡，而後應用到 Interledger、雷電網絡、Sprites 通道等。
撰文：錢柏均，就職於 HashKey Capital Research
審校：鄒傳偉，萬向區塊鏈、PlatON 首席經濟學家
本文研究哈希時間鎖的合約機制、主要特點、應用瓶頸以及改進方向。哈希時間鎖是去中心化和去信任化環境中進行條件支付的基礎，是理解數字貨幣和數字資產的可編程性的基礎。除了對密碼學的應用，哈希時間鎖的核心是序貫博弈。多個哈希時間鎖可以組成多跳支付，是比特幣閃電網絡支付通道的基礎，也在用央行數字貨幣進行跨境支付有廣泛應用，被很多中央銀行所關注。相向而行的哈希時間鎖可以組成原子交換，在區塊鏈應用於證券結算以及去中心化交易所中有應用。
哈希時間鎖（Hash Time Locked Contract，HTLC) 起源於閃電網絡，而後應用到 Interledger、雷電網絡、Sprites 通道等。哈希時間鎖使多個用戶之間「條件支付」（Conditional Payment）能以去中心化、無需第三方受信任中介的方式完成，這些用戶不一定在同一條區塊鏈上。哈希時間鎖可以組成多跳支付 (即雙方在交易過程中可藉助多箇中間節點來完成交易）和原子交換（Atomic Swap），是鏈下支付通道和跨鏈交易的基礎，並在央行數字貨幣跨境支付、證券結算以及去中心化交易所中有廣泛應用。
本文共分三部分：第一部分介紹 HTLC 合約機制，提出對 HTLC 的序貫博弈分析方法，並分析 HTLC 在應用中遇到的瓶頸；第二部分以 Interledger 的 HTLAs(哈希時間鎖定協議) 和雷電網絡爲例，分析 HTLC 的改進方向；第三部分討論 HTLC 的兩個重要應用案例：跨境轉賬，以及證券結算和去中心化交易所。
HTLC 合約機制
HTLC 工作流程
HTLC 支持「條件支付」：通過多個首尾相連的支付通道串聯起來形成的支付路徑，支持首尾雙方通過支付路徑完成支付。HTLC 的核心是時間鎖和哈希鎖。時間鎖指，交易雙方約定在某個時間內提交纔有效，超時則承諾方案失效（無論是提出方或接受方）。哈希鎖指，對一個哈希值 H，如果提供原像 R 使得 Hash® = H，則承諾有效，否則失效。如果交易因爲各種原因未能成功，時間鎖能夠讓交易參與各方拿回自己資金，避免因欺詐或交易失敗造成的損失。接下來，我們用一個例子說明 HTLC 工作流程。
假設 Alice 想開啓一個與 Bob 的交易，交易金額爲 0.5 BTC，但 Alice 需要通過 Carol 才能與 Bob 建立通道進行交易（圖 1）:
圖 1: HTLC 與支付路徑
第一步：Bob 設定原像 R （也被稱爲暗示數），把哈希值 H=Hash® 告訴 Alice。
第二步：Alice 通過 HTLC 向 Carol 進行條件支付：當且僅當 Carol 在 T 時刻前提供與哈希值 H 對應的原像 R，Alice 才向 Carol 支付 0.5 BTC。類似地，Carol 通過 HTLC 向 Bob 進行條件支付：當且僅當 Bob 在 t 時刻前提供與哈希值 H 對應的原像 R，Carol 才向 Bob 支付 0.5 BTC，其中 t<T。
第三步：Bob 如果在 t 時刻前向 Carol 提供 R，獲得 0.5 BTC，此時 Carol 知悉 R。反之，0.5 BTC 會返回給 Carol，Carol 不會遭受任何損失。
第四步：Carol 如果在 T 時刻前向 Alice 提供 R，獲得 0.5 BTC。反之，0.5 BTC 會返回給 Alice，Alice 不會遭受任何損失。
可以看出兩點：第一，在參與者理性前提下，HTLC 中所有「條件支付」要麼全部完成，要麼全不完成但所有參與者都能拿回自己的資金，因此是原子式的（Atomic）。這是序貫博弈均衡的結果（見下節）。第二，原像 R （信息）和資金相向流動，原像 R 可以被視爲收據（Receipt）。在 HTLC 中原像和哈希值的傳輸可以全部在鏈下完成，鏈上只做相關內容的檢驗，因此可以有效保護客戶隱私信息。
對 HTLC 的序貫博弈分析
在上節 HTLC 例子中，存在 Bob、Carol 和 Alice 3 人的序貫博弈 (圖 2)。圖 2 採取博弈樹形式。博弈樹的每個節點都代表一個參與者，從每節點出來的每條邊都表示該參與者可選擇的一個行動。在博弈樹的每一個末端節點上，都有一個 3 維支付向量。支付向量中的元素依次表示在不同策略組合下 Bob、Carol 和 Alice 的淨收益。
圖 2: HTLC 序貫博弈分析 (1)
序貫博弈程序如下：
首先，Bob 行動，他有兩個可選行動：「在 t 時刻前提供正確原像」，「在 t 時刻前不提供或提供錯誤原像」。
其次，Carol 行動。如果 Bob 選擇「在 t 時刻前提供正確原像」，那麼 Carol 有兩個可選行動：「向 Bob 支付，並在 T 時刻前提供正確原像」，「向 Bob 支付，並在 T 時刻前不提供或提供錯誤原像」。如果 Bob 選擇「在 t 時刻前不提供或提供錯誤原像」，那麼 Carol 只有一個可選行動：「不向 Bob 支付，並在 T 時刻前不提供或提供錯誤原像」。
最後，Alice 行動。在 Carol 選擇「在 T 時刻前提供正確原像」時，Alice 只有一個可選行動：「向 Carol 支付」。在其他場景下，Alice 只有一個可選行動：「不向 Carol 支付」。顯然，Alice 實際上沒有選擇的自由。
我們用倒推法求解序貫博弈的納什均衡：從最後階段開始分析（實際是從 Carol 開始分析，因爲 Alice 並無選擇行動的自由），每一階段分析該階段局中人行動選擇和路徑，再確定前一階段局中人行動選擇和路徑。
首先（圖 3，用 X 表示被排除掉的策略路徑，下同），在 Bob 選擇「在 t 時刻前提供正確原像」的情況下，Carol 選擇「向 Bob 支付，並在 T 時刻前提供正確原像」的淨收益是 0，選擇「向 Bob 支付，並在 T 時刻前不提供或提供錯誤原像」的淨收益是-0.5BTC。因此，Carol 的理性選擇是「向 Bob 支付，並在 T 時刻前提供正確原像」。
圖 3: HTLC 序貫博弈分析 (2)
其次 (圖 4)，Bob 如果選擇「在 t 時刻前提供正確原像」，他的淨收益爲 0.5BTC；反之，他的淨收益爲 0。因此，Bob 的理性選擇是「在 t 時刻前提供正確原像」。
圖 4: HTLC 序貫博弈分析 (3)
因此，序貫博弈的納什均衡策略是：{Bob「在 t 時刻前提供正確原像」，Carol「向 Bob 支付，並在 T 時刻前提供正確原像」，Alice「向 Carol 支付」}。序貫博弈也爲分析其他形式的 HTLC 提供了合適工具。
HTLC 主要特點
時間敏感性
HTLC 機制對交易時間的敏感性使得交易發起者不必浪費時間持續等待以確定他們的付款是否通過。如果設定時間已過，資金將被退回交易發起者，能夠有效避免惡意拖延交易，降低交易對手風險。
去信任化
HTLC 的最大優勢是去信任化。HTLC 消除了對中心化交易和受信任中介的依賴。交易可以經由兩方或多方執行而不需要它們彼此信任。由於用戶不需要將資金提供給第三方託管機構，安全性也會相對提高。交易可以直接從用戶的個人錢包發起，大幅地降低了第三方參與的風險。
跨資產交互性
在 HTLC 中，資金鎖定實現了質押效果，爲不同資產之間的交易提供了信任基礎。而原像及哈希祕鑰的傳遞，則保證了交易的原子性。
HTLC 應用瓶頸
協議兼容性較低
HTLC 實施需要滿足一些必要條件：一是用戶資產所在區塊鏈需要基於相同哈希算法（比如都使用比特幣的 SHA-256 哈希算法）；二是區塊鏈需要兼容 HTLC 和其他可編程功能；三是交易雙方需要在同一區塊鏈上有交易賬戶。這些條件可能會成爲 HTLC 推廣應用的主要障礙。
時間鎖機製造成退款時間過長
時間鎖有效降低了交易對手風險。但如果有中間節點因故無法進行交易，則必須等時間鎖設定時間結束才能退款。如果發送者在設定時間結束前改變路徑，將會承擔極大風險。
例如圖 1 中， Alice 利用 HTLC 通道，通過節點 Carol 給 Bob 轉賬，但現在由於某些原因，Carol 出現故障，無法在時間鎖設定時間內在線，從而 Alice 無法通過 Carol 轉賬。如果原來的 HTLC 沒有到期，Alice 要換路徑的話，會面臨很大風險。原因是，Bob 可以與 Carol 共謀，Bob 在通過新路徑拿到支付金額後，再向 Carol 透露原 HTLC 的原像，從而 Alice 在原來那條路徑鎖定的資金也就會被 Carol 解鎖取走，Alice 就相當於支付了兩次。因此，一旦有節點掉線，等待時間鎖解鎖成爲唯一選項。
HTLC 改進方向
Interledger 的 HTLAs(哈希時間鎖定協議)
HTLAs （Hashed Time-Lock Agreements）是 Interledger 提出的基於 HTLC 的泛化協議，目標是不管區塊鏈賬本是否支持 HTLC 協議，不管其是分佈式區塊鏈還是中心化賬本，系統和系統之間都能使用 HTLAs 實現跨鏈交換，並且支持多個系統之間的多跳跨鏈互換。在 HTLAs 下，不同用戶節點可以根據交易所需通過不同種類的 HTLAs 完成交易，而 Interledger 協議可以確保每個 HTLAs 擁有獨立的安全性，不會受其他區塊鏈交易失敗的影響。
HTLAs 根據系統支持的功能性主要可區分成四種：條件支付通道（Conditional Payment Channels with HTLC）、鏈上持有 / 託管 (On-Ledger Holds/Escrow with HTLC)、簡單支付通道 (Simple Payment Channels) 以及信任線 (Trustlines)。
圖 5: Interledger 跨鏈交易過程
條件支付通道
此種協議需要區塊鏈賬本支持 HTLC 條件支付通道，並可以在交易結束後更新通道餘額。閃電網絡的 HTLC 機制屬於這類。交易參與者需要在區塊鏈上預先支付一筆資金至雙方共有的臨時賬戶中 (即通道餘額)。當交易開始時，發送者會發送一個帶有哈希鎖和時間鎖以及附帶簽名的更新到接收者。若接收者能在約定時間內告知哈希鎖的原像，則可從賬戶中獲取資金，並且發送者與接收者需要同時簽名確認共有賬戶的餘額變動。由於交易的傳輸和處理時間會被計算在交易時間範圍內，所以該種協議更適合支持高速交易的區塊鏈系統。
鏈上持有 / 託管
此種協議需要區塊鏈支持 HTLC 協議，並且費率低、交易速度快、吞吐量高。以太坊和 Ripple 第三方託管合約屬於此類。交易參與者可以直接通過 HTLC 協議發起跨鏈交易。交易發起者將要傳輸的資金先放到區塊鏈提供的特定持有賬戶中，並且附帶哈希鎖和時間鎖。只有當接收者在約定時間前能提供正確的哈希原像，區塊鏈纔將資金髮送給接收者，否則區塊鏈會把資金退回給發送者。只要區塊鏈是可信賴的，這種方式可由區塊鏈全權控制交易狀態，交易雙方沒有額外風險。它與條件支付通道的差異是，交易參與者是將資金存放在區塊鏈賬戶，而非雙方共有賬戶。
簡單支付通道
簡單支付通道的特點是交易雙方可以合併多個交易而只清算最終賬戶的淨軋差。簡單支付通道交易發生在區塊鏈之外而非鏈上，且雙方需要在同一區塊鏈上擁有賬戶。交易分爲以下三個階段 : 設立階段、狀態更新階段以及清算階段。
(1) 設立階段 : 假設 Alice 和 Bob 進行交易準備，其中一方或雙方需要將一定數量的資金託管在一個暫時性且共享的支付通道中。
(2) 狀態更新階段 : 在交易開始前，雙方先簽署一個狀態聲明，用以表示支付通道中雙方資金佔比。Alice 會傳送一個簽署過後帶有哈希鎖及時間鎖的狀態聲明給 Bob(而非區塊鏈)。該更新後的狀態聲明呈現了交易結束後雙方在支付通道的資金佔比分配。唯有當 Bob 在時間鎖設定的時間內傳送哈希值的原像，狀態聲明纔會更新。交易通道並無方向限制，只要雙方餘額爲正值便可持續雙向交易。
(3) 清算階段：一旦有一方參與者想停止使用支付通道，可以執行退出操作——將最後的狀態聲明更新提交至區塊鏈，結算後的餘額會退給發起支付通道的兩方。主鏈可以通過覈實簽名和最後結餘來驗證狀態更新的有效性，從而防止參與者使用無效狀態來退出支付通道。
簡單支付通道與閃電網絡所使用的條件支付最大差異在於是否有強制性。在兩個方法下，雙方同樣是通過鏈外協議交換籤署過的狀態聲明進行交易。但在條件支付下，一旦在設定時間內 HTLC 條件滿足，區塊鏈會強制執行轉賬。而在簡單支付通道下，即使在設定時間內 HTLC 條件滿足，鏈上轉賬與否仍是雙方操作，並無強制性，因此較依賴雙方之間的信任程度。
信任線
信任線是交易雙方憑藉信任基礎進行的一種交易方式。信任線交易發生在鏈下而非鏈上，只有最後清算在鏈上發生。交易可以分爲以下三個階段 : 設立階段、狀態更新階段以及清算階段。
(1) 設立階段 : 假設交易發送者 Alice 及交易接收者 Bob 在同一個區塊鏈上擁有賬戶，想要開始一個信任線交易。Alice 首先需要設定 Bob 的信任線額度，這個信任線額度關係到 Bob 可以在雙方的信任線做的交易額度而無須清算。同樣，Bob 也需要設定 Alice 的信任線額度。
(2) 狀態更新階段 : 在交易開始時，Alice 會傳送一道帶有哈希鎖及時間鎖的交易訊息給 Bob。當 Bob 在時間鎖設定的時間內傳送哈希值的原像至 Alice 後，雙方的信任線狀態會更新，一方餘額增加而另一方餘額減少。此階段尚未清算。信任線爲雙向通道，只要交易總金額並未超過雙方信任線額度便可一直進行交易，而無須在鏈上進行清算。
(3) 清算階段 : 交易雙方將總淨額在區塊鏈上清算以結束交易。
信任線和簡單支付通道的主要有兩個差異 : 一是在信任線機制下，交易雙方無須存一筆保證金至通道，可以以最初設定的餘額進行逐筆交易，相當於信用交易。二是一旦交易總金額超過雙方信任線額度，或是雙方同意清算，便可以直接進行一筆鏈上轉賬結束交易。而在簡單支付通道機制下，任何一方均可主動結束交易，不需雙方同意。
表 1 爲四種 HTLAs 支付方式的比較。可以看出，區塊鏈功能複雜程度與風險程度反向變化：支付方式越複雜，交易風險越低，反之亦然。
表 1：四種 HTLAs 支付方式比較
以太坊的雷電網絡
雷電網絡是以太坊的一個鏈下交易方案。據官網開發路線圖，目前方案尚未完備，還在測試階段。2017 年 11 月底，µRaide(微雷電) 正式在以太坊主鏈上線，可以支持每秒 100 萬筆交易。2018 年 3 月，Liquidity.Network 正式加入了雷電網絡。雷電網絡目標是將交易場景從以太坊轉移到支付通道上，期望解決以太坊兩大問題——通道擁堵及交易費用高。雷電網絡的 HTLC 機制大多承襲閃電網絡，但也有部分技術創新。以下介紹兩個新增機制 : 智能條件及重試哈希鎖。
智能條件
雷電網絡引入「智能條件」(Smart Condition) ，比閃電網絡的 HTLC 機制更爲通用。閃電網絡的 HTLC 機制是以哈希函數的原像作爲祕鑰，但在雷電網絡中，用戶可以設定基於任何函數的祕鑰作爲智能條件。這種設計能夠讓雷電網絡的交易更加智能化，但同時也增大了交易風險與變數。
重試哈希鎖
在閃電網絡中，HTLC 的原像一般由收款人設置，然後將原像的哈希值提供給付款人。但這種設計存在一定問題：如果付款人想在原先 HTLC 時間鎖解鎖前發起另一個相同交易，中間人與收款人將有合謀的可能性，導致付款人重複付款（見前文）。爲了緩解這個問題，雷電網絡設置了重試哈希鎖 (Retry Hashlock)。爲區分兩個哈希鎖，下文把閃電網絡的哈希鎖改稱爲收據哈希鎖 (Receipt Hashlock)。
假設 Alice 在雷電網絡上支付一筆款項給 Bob，並且 Alice 需要通過 Carol 建立通道才能與 Bob 進行交易。以下爲重試哈希鎖機制 :
第一步：Bob 設定原像 R （收據哈希鎖），把哈希值 H=Hash® 告訴 Alice。
第二步：Alice 設定原像 R（重試哈希鎖），其哈希值爲 H=Hash®。Alice 通過 HTLC 向 Carol 進行條件支付：當且僅當 Carol 在 T 時刻前提供分別與哈希值 H、H對應的原像，Alice 才向 Carol 支付資金。
第三步 : Carol 通過 HTLC 向 Bob 進行條件支付：當且僅當 Bob 在 t 時刻前提供分別與哈希值 H、H*對應的原像，Carol 才向 Bob 支付。其中，t<T。
第四步：當 Alice 確認 Carol 發起交易併成功設定與 Bob 的 HTLC 後，Alice 纔會向 Bob 提供哈希值 H對應的原像 R。
第五步：Bob 已知 R 和 R。Bob 在 t 時刻前向 Carol 提供 R、R，獲得資金，此時 Carol 知悉 R、R*。反之，資金會返回給 Carol，Carol 不會遭受任何損失。
第六步：Carol 在 T 時刻前向 Alice 提供 R、R*，獲得資金。反之，資金會返回給 Alice，Alice 不會遭受任何損失。
在上述機制中，如果在交易途中 Carol 因故無法向 Bob 進行條件支付（第三步），Alice 可以重新設置重試哈希鎖，改以另外途徑進行支付。Bob 因爲不掌握 R*，不能與 Carol 共謀進行雙重支付攻擊。
重試哈希鎖也適用序貫博弈分析法。因篇幅限制，本文就不展開闡述了。感興趣的讀者可以參考圖 2-4 的做法。
HTLC 應用案例
跨境轉賬
目前，跨境轉賬依賴於 SWIFT 網絡，存在手續費高、無法實時收款等問題。區塊鏈在跨境轉賬中的應用一直備受關注，集中體現爲央行數字貨幣和以 Libra 項目爲代表的全球穩定幣，目標是通過區塊鏈替代代理行模式，以降低交易費用和所需時間。如果兩個央行數字貨幣使用不同的區塊鏈網絡，那麼兩個貨幣區之間跨境轉賬就涉及跨鏈操作和交易對手信用風險管理。這本質上是涉及多個條件支付的多跳支付，是 HTLC 能發揮作用的地方。
2019 年中，加拿大銀行與新加坡金管局成功利用 HTLC 技術完成一筆跨境轉賬（圖 6）。加拿大銀行和新加坡銀行分別利用 Corda 和 Quorum 區塊鏈平臺進行合作。試驗使用 HTLC （具體來說，前文介紹的 Interledger 的 HTLAs 協議）來連結兩個區塊鏈平臺，以提升跨鏈交易的安全性和清算同步率，提高跨境轉賬效率。儘管轉賬過程仍然離不開中間銀行（Intermediary Bank)，但位於新加坡和加拿大的中間銀行是同一家。
圖 6: 加拿大銀行與新加坡金管局跨境轉賬試驗
日本銀行和歐央行的 Stella 項目 在第三階段進行了類似試驗。他們比較了四種 HTLAs 支付方式和第三方託管的安全性（表 2）。
表 2：不同支付方式的比較
Stella 項目特別分析了以下情形：如果付款人破產，託管資金是否安全？具體而言，就是圖 7 的多個條件支付中：如果在第 4 步完成後，Connector 1 破產，Connector 2 能否執行第 5 步以拿到資金？
圖 7：多跳支付中有中間機構破產的情形
Stella 項目發現，條件支付通道、鏈上持有 / 託管和第三方託管都是安全的，而信任線的安全性最差。
證券結算和去中心化交易所
在跨境轉賬，資金是單向流動。如果除了資金流動，還涉及另一種經濟資源的反向流動，比如證券結算中的券款對付 (DvP，Delivery vs Payment)。這就涉及原子交換。原子交換也是去中心化交易所的基礎。
原子交換介紹
原子交換是一種能實現資產在不同網絡間進行點對點交換的智能合約，由多重簽名及 HTLC 構成。原子交換具有三個特性 : 第一，交易具有原子性；第二，如果交易中出現惡意節點作惡，其他節點不會遭受損失 ; 第三，根據序貫博弈分析，理性節點無作惡動機。HTLC 是原子交換中最核心的概念，確保了原子交換過程中的去中介化。基於 HTLC 的原子交換是跨鏈解決方案的一種。相對於其他跨鏈方案，原子交換不需要通過生成新的映像資產完成跨鏈，交易雙方的資產還是通過原有的區塊鏈進行確認，資產的安全性不會發生本質性變化，因此不具備資產託管的金融屬性。
原子交換有兩種類型 : 鏈上原子交換 (On-chain Atomic Swap) 和鏈下原子交換 (Off-chain Atomic Swap)。鏈上原子交換顧名思義就是發生在兩個不同區塊鏈系統的交易。例如，萊特幣和比特幣都是基於比特幣協議的區塊鏈網絡，可以進行鏈上原子交換。鏈上原子交換需要相當長時間進行交易驗證，因此並不適合作爲常規交易使用，較適合應用在大型且頻率低的場景。鏈下原子交換髮生在 Layer 2 ，利用鏈下支付通道來進行原子交換。閃電網絡是其中一個例子。鏈下原子交換支持同構或異構的區塊鏈系統，可以實現不同協議的加密資產轉換，交易速度較快。
原子交換在去中心化交易所的應用
去中心化交易所是由區塊鏈上的智能合約構築的交易平臺。用戶資金由自身錢包或去中心化的方式儲存，且用戶在區塊鏈上能實現自動點對點撮合交易。在整個交易處理過程中，用戶保留對私鑰唯一保管權。去中心化交易所有多種實現方式，原子交換是其中一種。原子交換在去中心化交易所最核心的功用有三個 : 第一，用戶可以控制自己的私鑰，而非由第三方託管 ; 第二，實現實時且全額的鏈上結算 ; 第三，用戶可以跨鏈進行多種加密資產交易，過程無須通過中心化機構。
Komodo 交易所是原子交換領域先驅。目前，Komodo 交易所超過 95% 的加密資產交易基於原子交換技術實現。其跨鏈功能兼容比特幣協議網絡和以太坊、ERC20 代幣。
幣安 DEX 與 TrustToken 合作，利用 HTLC 實現穩定幣跨鏈交易。TrustToken 之前發行的穩定幣都是 ERC20 版。在幣安鏈主網使用 HTLC 後，這些穩定幣可以實現 ERC20 和幣安鏈 BEP2 兩個標準之間的跨鏈轉換，爲用戶在加密貨幣和銀行賬戶之間進行資產轉移提供更多選擇。
原子交換在證券結算的應用
目前，證券結算採用中心化機構的「限制交付」方法實現 DvP。而在去中心化環境下，DvP 可以基於原子交換來實現。日本銀行和歐州央行的 Stella 項目在第二階段進行了類似試驗，分爲單鏈 DvP (Single-ledger DvP) 以及基於 HTLC 的跨鏈 DvP(Cross-ledger DvP with HTLC)。基於 HTLC 的跨鏈 DvP 並不依賴證券結算網絡的連結，可以通過鏈下原子交換進行，因此較有可擴展性及可交互性，應用場景較廣。
目前基於 HTLC 的跨鏈只是概念上的實現，具體技術實現有兩個主要的風險 : 第一，當雙方並未在時間鎖時間內完成交易時，現金和證券會被退回買方及賣方，雙方會承受流動性風險。第二，基於 HTLC 的跨鏈 DvP 的實現需要現金方及證券方兩個哈希時間鎖條件同時滿足。當其中一個哈希時間鎖條件（假設爲現金）滿足而另一個條件（假設爲證券）不滿足時，現金交易結算上鍊，證券交易退回，證券賣方會獲得交易對手的現金並拿回自身的證券，造成證券買方的實質損失。因此，原子交換要成爲跨資產交易和結算的金融底層結構，還需要解決許多技術上的問題。