在上一篇文章里|深入解读闪电网络：HTLC 的工作方式与多跳支付的实现方式( 三 ) 在上一篇文章里

清除故障
在我们这个例子中，整个流程都是很平滑、没有阻碍的，但在现实生活就像所谓的“墨菲定律”：如果某种坏事可能发生，那这种坏事就一定会发生。于是我们要考虑闪电网络的“保护”机制。
从实践来看，支付链条越长，最终无法交付资金的概率就越大：某些参与者可能会关闭通道，或者某些节点会掉线。我们来考虑两种可能的出错情形。
通道故障
先考虑一种情形：我们假设资金已经达到了目的地，但在秘密数值一路返回到支付起点的过程中，某个参与者拒绝合作或者无法配合。假设是Bob 。

文章图片
-因为一个通道关闭，资金无法交付-
当Diana收到了秘密值时，就立即取回了资金，并把秘密值暴露给了Carol 。 Carol也想从Bob发出的HTLC里面拿回资金，但Bob没有响应，为了避免风险，她关闭了通道，将自己手上的最后一笔承诺事务（也即Bob之前发出的、带有HTCL输出的事务）广播到了比特币网络中，而且，因为她知道秘密值，所以能取回资金。此时， Bob还有三天时间可以从Alice处拿回自己的钱（因为Carol的事务已经上链， Bob可以很容易地知道R的数值）。否则，等时间锁一解锁， Alice就可以收回资金。
可以看出，即使某个参与者因为某种原因离开了网络， TA自己是唯一一个可能损失资金的人，而其他人的资金都是安全的。
重新路由
在第二种情形中，我们假设资金无法到达目的地，也是因为某个参与者出了错。假设是Carol 。
第一种也是最明显的解决方法是，等待HTLC的时间锁过期，然后各参议者各自拿回自己的资金。
-支付路径中的某个节点没有响应-
但如果Alice就是着急支付，该怎么办呢？当然， Alice可以通过另一条路径发起新的支付，不需要死等资金返回，但要是Carol突然之间又回来了，跟Bob把链条续上了呢？那Alice不就发送了两倍资金了吗？
-Alice如果使用另一条路径-
这是否意味着，但凡出现了支付失败的情形，都应该乖乖等时间锁超时，然后再发起新的一笔支付呢？
好在，要避免这种等待，我们可以“取消”这一次的支付。 Diana（收款方）要发送等量的一笔资金给Alice ，也使用跟原来一样的哈希值，也可以使用另一条路径。现在，如果Carol重新上线并参与中介，那么资金会走完一个环路，这就意味着那笔原来失败的支付被抵消了， Alice可以安全地使用另一个路径来支付了。
-Alice“取消”了旧的支付，新的支付现在可以安全地发送了-
支付数额
你可以也注意到了，当Alice“取消”其第一笔支付时，现在的确是可以安全地发起新的一次支付了，但这并没有改变一个事实：她的第一笔支付的资金现在仍然是锁定的，而她可能没有足够的钱来发起第二次支付了。这就是为什么在使用闪电网络时，用HTLC来支付时资金额度应该更小。因为承诺事务不会上链，数额可以分割成多个很小的额度。这样，无论什么时候一个路径不通了，都只有一小部分资金会被冻结（就是最后发送的那一笔）。
传输协议
闪电网络的另一个非常重要的特点是：有关这个路径的所有信息都是完全匿名的。也就意味着对于任何一个参与者来说， TA都只知道跟自己有关的这部分，比如，对于Carol来说，这笔支付就像是Bob在给Diana转账，她不知道Bob会从Alice处收到资金，也不知道Diana会继续转账给Eric 。
闪电网络使用Sphinx多重加密协议。在使用闪电网络时， Alice会为网络的每一部分都做一层加密，从支付路径的末端开始。她使用Eric的公钥为Eric加密了消息。这条加密消息会被嵌套在给Diana的消息里，并用Diana的公钥对整个消息再做一次加密。再然后，这条给Diana的消息又会嵌套在给Carol的消息里，也用Carol的公钥对整个消息再做一次加密。如此不断重复，得出可以交给下一个人的消息。这样一来， Bob只能解密消息的最外一层，得到本意发给他的内容；然后把消息转给Carol；Carol也是如此。每经过一个人，都只会公开绝对必要的消息：支付的数额、佣金的数额、时间锁的内容，等等。