Key words：BlockChain; InterLedger; Hold; ILP; Ripple; Interledger Protocal; Ledger

摘要：隨著區塊鏈網絡廣泛的出現，在不同的網絡之間實現加密電子貨幣的價值轉換的需求變得旺盛，作為價值網絡核心的跨鏈技術從而變得越來越重要。本文詳細分析了瑞波（ripple）提出的Interledger Protocal，說明協議的核心點及使用方法，同時結合Interledger Protocal的優勢列出一定的應用場景。

關鍵詞：區塊鏈；跨鏈；托管；ILP；Ripple；Interledger Protocal; 賬本；

1.

背景

自比特幣誕生以來，加密數字貨幣的區塊鏈網絡越來越多，形成了蓬勃發展之勢。但是在不同的區塊鏈之間進行價值轉移和交換，就會碰到各種各樣的問題。比如Alice有“比特幣”，想通過“比特幣”購買Bob一個筆記本電腦，筆記本電腦以“瑞波幣”來定價，不接受“比特幣”。這時Alice就得想辦法通過一定的兌換，將自己手中的“比特幣”換成“瑞波幣”，再向Bob進行支付。這筆交易的過程應該是：首先Alice把“比特幣”賣出得到USD，然後再用USD買入“瑞波幣”，在這個過程中會有一個問題----幣價穩定性，幣價不穩定將會導致價值損耗，同時交易過程也很繁瑣，周期過長。正是針對這樣的問題，ripple提出了一種跨鏈價值傳輸的技術協議InterLedger Protocal（以下簡稱ILP）。

2. 簡介

ILP創建了這樣一個系統，在這個系統中，兩個不同的賬本系統可以通過第三方“連接器”來互相自由地轉換貨幣。賬本系統無需去信任“連接器”，因為該協議采用密碼算法為這兩個賬本系統和連接器創建資金托管，當所有參與方對資金達成共識時，便可相互交易。ILP移除了交易參與者所需的信任，連接器不會丟失或竊取資金，這意味著，這種交易無需得到法律合同的保護和過多的審核，大大降低了門檻。

ILP協議的核心思想在於：“賬本”提供的第三方，會向發送者保證，他們的資金只有在“賬本”收到證明，且接收方已經收到支付時，才將資金轉給連接者；第三方也同時也保證連接者，一旦他們完成了協議的最後部分，他們就會收到發送方的資金。

區塊鏈從技術上是去中心化數據庫和分布式賬本技術，從商業層面則是價值網絡，在這個價值網絡中，連接的有效節點越多、越分布，可能產生的價值疊加會越大。區塊鏈是價值網絡空間的核心基礎設施，為了讓這種基礎設施得到互聯互通，自由進行傳值轉換，我們需要跨鏈技術，對不同區塊鏈進行連接和擴展，構建價值網絡的高速公路.

3. 賬本

各“賬本”要想利用ILP技術與其它區塊鏈或者“賬本”進行價值轉換，就要滿足一定的基礎條件，才能更好地使自己發行的代幣與其它電子貨幣幣進行交換，從而易被大眾接受。

1. 必須要支持自己“賬本”所管理下的一個賬戶向自己賬本所管理下另外一個賬戶的轉賬操作；

2. 必須要支持托管式的交易操作，該類型的交易需要兩個必要參數：一個執行“托管”交易的“原像條件”及一個“超時時間”；

3. 任何用戶，不局限於“托管”交易的創建者，在提供“托管”交易的“原像條件”時，就可以決定“托管”交易是被執行還是被拒絕；

4. 如果“托管”交易創建後超時，“托管”交易就會自動失效，“托管”交易裏所托管的貨幣會重新進入“托管”交易的創建者賬戶；

5. “賬本”所支持的交易需要具有攜帶簡短消息的能力；

6. “賬本”支持事件通知功能，使得各方能及時知道有一筆針對自己的“托管”交易。

4. 流程

4.1. 概述

整個交易流程分成“發送方--->接收方”與“接收方--->發送方”兩個主流程。每個流程又是由發生在各個“賬本”上的各個子交易（“托管創建”與“托管確認”）組成。“發送方--->接收方”流程全部是“托管”的創建動作，“接收方--->發送方”則全由“托管”的確認動作組成。

圖2

從圖2中我們可以了解到在接收方對“賬本N”上的“托管”交易進行確認前，所有“賬本”上被創建的“托管”交易並未被確認，些時每一個“賬本”上“托管”交易裏指定的源賬戶並未真正將自己的資產轉移出去，而是由“賬本”系統進行了托管。只有當接收方進行確認後，在“接收方--->發送方”的返回流程中，各個“托管”交易才被確認，此時各個“賬本”的“托管”交易裏指定的目標賬戶才真正得到源賬戶的資產，資產價值真正發生轉移。

在交易的整個鏈條過程中，每一個環節上的交易在被確認之前都是處於“托管”狀態，並沒有發生價值轉移。即使是連接者去破壞交易，比如說將交易發往另外的地址，發送者也不會有損失，因為最後托管的交易不會得到執行，超時時間條件達成後，交易中的資產會再返回給源賬戶。

當接收者收到一個涉及自己賬戶的“托管”交易的通知時，接收者會確認交易細節從而確定交易是否正確，然後提供“托管”交易所指定條件的原像，向“賬本”系統發出“托管確認”操作，接收者真正得到所需要的加密電子貨幣。接下來整個傳輸鏈條上的每一個連接者都用同樣的“條件原像”去“托管確認”屬於自己的“托管”交易，最終每個連接者都收到自己應得的資產價值。

一個值得註意的細節就是：各個“連接者”在創建自己發出的“托管”交易時，設置的超時時間一定要小於自己收到的“托管”交易裏所設置的超時時間，從而自己在得到條件的原像時，有時間去執行自己收到的“托管”交易的確認操作，否則會出現自己創建的“托管”交易被接收方或者其它的連接者確認，但自己來不及去確認“屬於”自己的“托管”交易，從而造成損失。換句話說，在“賬本B”上把資產轉移給了另外一個賬戶，在“賬本A”上未確認到對應的資產，造成資產損失。

4.2. 步驟

我們使用本文開頭提出的場景來描述整個交易的詳細步驟：

對象：發送方--Alice，接收方--Bob, 連接者—Cot。

賬本關系：Alice擁有bitcoin的賬戶， Bob擁有ripple的賬戶， Cot擁有bitcoin與ripple賬戶。

場景：Alice要從網上購買Bob的筆記本電腦，定價為29230個ripple幣。

圖3

1. Alice通過即時通訊軟件或者其它通訊手段，得到Bob提供的一個“共享密碼”。通訊一定要以加密方式進行，使得在溝通後，只有Alice與Bob知道這個“共享密碼”；同時Bob會告訴Alice自己在ILP網絡中對應的唯一地址，例如g.ripple. rHCvhtqhXuBvWt5g79gyXfpG8VcrvUm9E9。

2. Alice去向Cot詢價，查詢自己想發送29230個ripple幣需要多個少BTC，此時Cot會按實時的BTC與ripple行情算出需要1個比特幣，同時Cot會多收0.00001個BTC作為手續費，最終Alice得到的詢價結果為:需要向Cot支付1.00001個BTC。

3. Alice按ILP規定的消息格式生成所需要的ILP包，ILP包裏指明目標地址為Cot,同時基於ILP包的私有內容與“共享密碼”生成一個“條件原像”，對“條件原像”進行哈希散列，得到一個“托管”交易的“條件”。

4. Alice在Bitcoin賬本系統上發起一個“托管”創建操作，設置了步驟3中的“托管”條件及一個超時時間，同時設置ILP包。

5. Cot在Bitcoin上監測到一個涉及自己的“托管”創建操作。

6. Cot解析ILP包，計算出自己應該向Bob轉29230個ripple幣，同時修改ILP中的目標地址為Bob。

7. Cot在ripple賬本系統上發起一個“托管”創建操作，設置了步驟3中的“托管”條件及一個超時時間，此超時時間要小於步驟4中的超時時間，同時設置ILP包。

8. Bob在ripple上監測到一個涉及自己的“托管”創建操作。

9. Bob解析ILP包,用自己的“共享密碼”及ILP包裏的私有內容生成一個“條件原像”及對應的“條件”。通過對比“托管”創建交易裏攜帶的“條件”與自己生成的是否相同，及核實“托管”交易中指定的資產數量是否是29230，來確認“托管”交易：接收或拒絕。我們這裏假定接收。

10. Bob在ripple賬本系統上發起一個“托管”確認操作，設置上“條件原像”，ripple賬本上的“托管”交易完成，Bob收到29230的ripple幣

11. Cot在ripple上監測到一個涉及自己的“托管”確認操作。

12. Cot分析“托管”確認操作的內容，得到“條件原像”。

13. Cot在bitcoin賬本系統上發起一個“托管”確認操作，設置上“條件原像”，bitcoin賬本上的“托管”交易完成，Cot收到1.00001個BTC。

14. Cot在bitcoin上監測到一個涉及自己的“托管”確認操作。

4.3. 托管

從交易流程中我們可以看到，ILP是利用各個賬本所提供的“托管”功能進行各子交易的實現。

圖4

從圖4中我們可以看到，“托管”交易包含四個主要步驟

1. 準備：此時什麽事情都沒發生，只進行了必要數據的準備。

2. 創建：隸屬於一個“賬本”系統上的某個賬戶的資產被“托管”。

3. 確認：“托管”交易完成，資產發生轉移，從“賬本”系統內的一個賬戶轉移到了另外一個賬戶。

4. 拒絕：“托管”交易被取消，資產回到“賬本”系統的源賬戶。

托管功能的特點主要有以下幾個方面：

1. “托管”交易被創建後，發送方的資產並未真正轉移。

2. “托管”交易不能被撤銷或者在一定時間內不能撤銷。

3. 任何人只要知道“托管”交易列出的“條件原像”，都可以使得“托管”交易被確認，不必要發送方去執行“托管”交易的最終確認操作。

4. 任何人只要知道“托管”交易列出的“條件原像”，都可以拒絕“托管”交易，不必要發送方去執行“托管”交易的拒絕操作。

5. “托管”交易可以設置超時時間，在規定時間內無人進行“確認”操作或者“拒絕”操作，“托管”交易自動失效。

“托管”交易是ILP實現的前提條件，實現“托管”的方式多種多樣，可以是“賬本”本身具有的功能，也可以是通過雙方信任的第三方來代替實現。只有通過“托管”的方式，才能保證各方的利益不受侵害。

5. 安全

ILP用了一種帶“條件”的交易來保證資產價值在各個“賬本”系統之間傳遞時的安全，發送方用一種加密證明來保證發出去的資產要麽被接收方接收，要麽返回到發送方的賬戶。在整個過程中。連接者可能會遭受一定的損失，但是此風險基本可控，風險只與連接者選用的賬本系統及直接連接的節點有關。

5.1. 連接者

在ILP協議中，連接者是一個重要的角色，支撐起整個跨鏈網絡，使得跨鏈的資產交換得以正常進行。連接者之所以有積極性是因為在提供資產轉換的過程中會收取一定的費用，像做市商時收取的傭金一樣來獲得收益。

但在這個過程中連接者是有一定的風險的，當連接者發出去的“托管”交易被成功確認，但是自己沒有及時去確認自己收到的那個“托管”交易，這樣本該發給自己的資產就會返回到源賬戶的地址，造成一定的損失。

當連接者未能及時確認發往自己的托管的交易時，只能靠發送方再次發送帶有同樣執行“條件”的同樣的“托管”交易過來，當連接者拿到這個“托管”交易時，用上次記下來的“條件原像”去確認這個新的交易。

要想讓發送方願意重復再發送已經失效的交易，就需要給這樣做的發送方一定的獎勵，比如降低傭金、優先進行資產轉換等。

5.2. 問題

1. 接收方是否會在沒有確認涉及自己的“托管”交易時，泄露“條件原像”？

答：如果接收方正常的話，是不會有此現象發生，因為這樣自己的權益不會被保證，會造成發送方已經發送，接收方收不到資產的情況，這種情況下接收方要承擔責任。

2. 接收方是否會只把對方的“托管”交易確認，卻不公布“條件原像”？

答：不會，“托管”確認交易的必要參數之一就是“條件原像”，只要“托管”交易被確

認，“賬本”系統上就可以查看此交易，從而得到“條件原像”。

3. 連接者在未來得及確認涉及自己的“托管”交易時，同時發送方又不再次發送，怎麽辦？

答：沒辦法，確實無法回避此問題。

4. 發送方與接收方之間有多個連接者的情況下，如果第一個連接者先於第二個連接者拿到了“條件原像”，是否會給第二個連接者造成損失？

答：不會，因為第一個連接者創建的“托管”交易在一定時間內不能取消，只要在超時

時間內第二個連接者拿到了“條件原像”，就可以確認涉及自己的“托管”交易。

5. 誰可以做連接者？

答：任何擁有2個以上“賬本”系統賬號的個人都可以做連接者。

6. 核心

縱觀本文，大家已經發現了ILP並未創建一個統一的“賬本”系統，也未要求參與的各方去信任任何個人或者機構，而是依靠現有的、已經存在的“托管”交易來保證各方的利益，那ILP事實是做了什麽事呢？

ILP提出了一種跨鏈資產轉移的方法，但是其首先是一個協議，協議的核心在於以下兩點：

1. 確定了各個“賬本”系統上的每個賬戶的地址規則，即通過層級關系來確定某一個賬號是屬於某個範圍內某個賬本上的。

例如 g.ripple.bob，表示公鏈ripple上的一個賬戶bob

2. 定義了在跨鏈交易時的消息傳遞格式，使得發送方、接收方、連接者之間可以用同樣的消息格式進行信息的傳遞，用以確認收到消息及得到自己的目標地址。

核心點一使得交易流程中的各個子交易能確定轉移的賬戶，核心點二使得各方采用統一的格式進行消息傳遞。

7. 應用場景

1. 只擁有加密電子貨幣A的情況下以加密電子貨幣B的形式進行支付；

2. 擁有不同加密電子貨幣的賬戶，想在隸屬於不同“賬本”的賬戶之間進行貨幣的價值轉換；

3. 同一集團下不同私有鏈之間進行同類型貨幣的價值互換。

8. 小結

本文系統介紹了Interledger protocal，同時以實例的形式完整說明了整個ILP交易的詳細流程，同時對交易過程中的安全性能進行了深入分析，針對ILP的技術特點，本文也給出了它的一些典型應用場景。

參考文獻

1. http://blog.csdn.net/elwingao/article/details/53410750 高誌豪

2. https://interledger.org 瑞波公司

跨鏈技術之ILP詳解及應用