从哈希锁定到跨链技术
今天说说跨链技术
背景
互联网的发展历程就是从孤岛到共享， 往大了说这也是人类社会发展历程的必经之路。 现在公链一条又一条， 将来会更多， 实现最大的价值必然是互联互通， 这已经是普世价值观了。
如果说一条链的交易是国内的交易， 则跨链就对标的跨国交易。
跨链应用场景
1）资产转移（Portable Assets）：数字加密货币和资产可以在不同链中转移，抵押和使用。
2）货银对付（Payment-versus-Delivery）：即一手交钱一手交货。这里强调是一个原子性互换（Atomic Swap）原则，要么两清，要么交易失败。外汇货币间的同步交收（payment-versus-payment）也是同一个意思。这个场景应该是呼声最高的，比如去中心化交易所。但凡是个跨链项目的白皮书里都会标榜他们能做出来一个去中心化交易所，其实是个再自然不过的事。
3）跨链预言机（Cross-chain Oracle）：链A的智能合约的触发和执行依赖于来自于链B的预言机的信息。链A需要能读取链B的事件、状态等数据。
4）资产留置（Asset Encumbrances）：链A上的资产被锁定，并且解锁条件依赖于链B上的行为。类似于金融中的产权抵押，侧链中的双向锚定也有这个意思。
5）通用跨链合约（General Cross-chain Contract）：比如根据链A上的资产证明来在链B上用B的货币来分配发放红利。
跨链技术的方案有哪些
1）中心化公证人机制（Centralized Notary schemes）
2）多重签名的公证人机制（ Multi-sig Notary schemes）
3）侧链/驱动链（Side-chain）
4）哈希锁定（Hash-locking）
今天主要讲哈希锁定的方案
哈希锁定
假设Alice想用自己的ADA换取Bob的BTC，具体应用流程如下：
1 Alice创建了一个随机密码s，并且算出该密码的哈希值h，即h = hash(s)。Alice将这个哈希值h发给Bob。
2 Alice和Bob共同通过智能合约将彼此的资产先后锁定（Alice先进行锁定，Bob再锁定），并且智能合约里实现了以下逻辑：
条件1：如果任何人能在H小时内提供一个随机数值s’给智能合约，一旦合约验证了hash(s’) == h（当s’等于原始密码s），那么Bob的BTC就自动转给Alice，否则超时后发还给Bob。
条件2：如果任何人在2H小时内将原始密码s发给智能合约，则Alice的ADA将被自动转给Bob，否则转还给Alice。
3 上述的条件1是针对Alice来制定的，Alice为了拿到Bob的BTC，必然会在超时前将自己产生的随机密码s提供给智能合约，合约验证肯定会顺利通过，并且把Bob的资产转给Alice。这一笔交易在成功的同时，Alice提供的原始密码s也被公开地广播并记录在了区块链上。此时，Bob可以拿着公开了的密码s，发给智能合约，依照条件2，便能获得Alice锁定在智能合约中的ADA，理论上Bob有1H到2H小时的充裕时间来完成操作（取决于Alice多快能完成她的操作）。于是皆大欢喜。
当然，哈希锁定的交易中，Alice拥有主动权，是更具优势的一方。在更加复杂一些的交易中，比如引入了具有波动性的交换比例（fluctrate exchange rate），那么Alice可以选择等待，直到出现自己更加满意的交换比例时再触发兑换，而Bob只能被动接受。当然Alice也有可能等到最后才发现错过了之前最好的比例，不过总的来说，Alice获得了更多的选择权，在交易中占到了便宜。
跨链哈希锁定通常会和“状态通道”（State channel）搭配起来，使得交易速度更快，从而避免上述的Alice优势问题。
小结： 设置密码， 提供密码哈希值； 智能合约锁定条件设定； 提供密钥拿到交易资产， 对方随后也拿到交易资产；交易完成。
基于哈希锁定的方案： ILP
Interledger（ILP）是大名鼎鼎的瑞波Ripple发起的一个跨账本协同的协议。Interledger专注于实现连接各个账本不同资产的统一支付标准，而非单独的区块链，也没有自己的代币。这里支持的账本包括区块链，银行，p2p支付，传统的ACH，移动支付机构，甚至央行操作的实时全额支付系统（Real-time Gross Settlement，RTGS）。
在付款方和收款方中间，起到核心作用的是一系列的“连接器”，这里的架构有点类似于互联网模型里的网络层（之前NKN，Mainframe，兰花简评都有所涉及），每个连接器犹如路由器节点一般试图将ILP数据包转发到更接近终点的地方，最终收敛到终点。付款方和连接器之间，连接器之间，连接器和收款方之间都是通过HTLC来完成有条件的转帐，从而做到安全的多跳支付。而每个参与者只需要信任直接对接的上下家就可以了。
实际上InterLedger将HTLC进一步泛化成HTLA（Hashed Timelock Agreement），这个由第三方执行的协议，可以用来在不支持HTLC的账本间执行HTLC。
ILP的资产转移过程说明
场景：Alice要从网上购买Bob的笔记本电脑，定价为29230个ripple币。
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上监测到一个涉及自己的“托管”确认操作。
相关参考与链接：