Abstract：As the booming of BlockChain technology, the requirement of asset transfer between different ledgers is as imperative as possible. as the kernal of the value network, the technology about inter ledgers is more and more important。On studying the Interledger Protocal given by the ripple company, we give the core point and introduce the trasaction flows, moreover, we list some scene compatible to the ILP technology.
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 瑞波公司