深入理解闪电网络（下）
Lightning network in depth, part 2: HTLC and payment routing
在上一篇文章中，我们详细分析了支付通道的功能以及保护通过这些通道的支付的几种方法。然而，仅仅建立一个有效的通道网络是不够的：即使我们确定在每个通道中每个人都在公平竞争，我们也不能保证通过多个通道的链来交付资金。这就是称为 HTLC（散列时间锁定合约）的智能合约的用武之地。在本文中，我们将讨论它们的工作方式，并使用一个示例来展示如何在闪电网络中完成支付。
Table of contents
- HTLC
- Lightning network example
- Clearing out failures
- Transport protocol
- Benefits and use cases
- Conclusion
- Links
Hash time lock contracts (HTLC)
HTLC 合约的结构并不复杂，但非常高效，可以创建具有特定“到期日”的付款。正如您可能已经猜到的那样，HTLC 合约由两部分组成：哈希验证和时间到期验证。
让我们从哈希开始。要创建 HTLC 支付，首先应创建 secret R，然后计算其哈希值。任何图形，任何单词都可以作为秘密：无论如何，它只不过是一个字节组合。
此哈希 H 将包含在锁定脚本中。因此，只有知道被哈希得到 H 的秘密的人才能使用支付。secret R 也称为 preimage。
HTLC 合约的第二部分是支付到期时间的验证。如果秘密没有及时泄露并且付款没有被使用，则发送方可以取回所有资金。
让我们考虑一个发给某个人的 HLTC 付款示例：
如果提供了真正的 secret R，即 H 哈希的原像，我们进入 IF 流并进行验证，以了解发现 secret R 的人是否是付款的预期接收者。要花费这笔款项，收款人应该出示一个非常简单的解锁脚本：
如果提议的 secret R 为假，我们进入 ELSE 流程，首先验证分配的时间是否已过。如果是，发件人可以取回所有资金。取回资金的解锁脚本是相同的，唯一的区别是需要故意提供错误的秘密才能进入 ELSE 流程：
当然，它只是HTLC合约的一个非常基础的实现，代表了普通的时间锁定支付。您可以在脚本中添加任意数量的不同条件：例如，通过删除 IF 流中的公钥验证，我们可以让知道秘密的每个人都可以访问付款；我们还可以模仿多重签名，要求多个签名而不是一个，等等。
P.S. 在这种情况下，我们使用了操作码 CHECKLOCKTIMEVERIFY，使用绝对值来定义时间锁，例如：“此输出不能在块 #546212 之前使用。”在闪电网络中，还有另一个操作码，一个更“灵活”的操作码，它也被使用：CHECKSEQUENCEVERIFY，使用时间锁的相对值，例如：“此输出不能在交易发生后的 1000 个块内使用被广播到网络上。
Lightning Network Example
现在，当我们最终分析完所有组件时，我们就可以考虑闪电网络如何运作的全貌了。我们的这个示例将有五个参与者：Alice、Bob、Carol、Diana 和 Eric。他们每个人都有与其他人开放的支付通道，每个通道的每一侧都有 2 个比特币的余额。因此，有了一个通道链，让我们尝试执行从 Alice 到 Eric 的付款。
让我们假设 Alice 想要将 1 个比特币转移给 Eric。然而，正如我们所见，它们并没有通过直接通道连接，开辟新通道需要时间和金钱。幸运的是，Alice 连接到闪电网络，可以借助一系列 HTLC 合约进行间接支付。让我们逐步检查此付款。
- Eric 创建一个秘密 R 并将其哈希值传达给 Alice（他不会向任何人展示秘密本身）。
- Alice 使用此哈希创建一个 HTLC，其时间锁设置在前 10 个块上，数量为 1.003 BTC。额外的 0.003 BTC 将作为中间参与者参与链的费用。因此，Alice 使用以下规则将她的 1.003 BTC 余额锁定在 HTLC 中：“如果 Bob 在接下来的 10 个区块中找到秘密 R，Alice 将支付 1.003 BTC，否则资金将返还给 Alice。”通道的余额被承诺交易改变，现在如下：Bob 有 2 BTC，Alice 有 0.997 BTC，1.003 BTC 被锁定在 HTLC。
- 轮到 Bob 处理 Alice 的承诺交易（HTLC 发送到连接它们的通道），在将他连接到 Carol 的通道上创建一个 HTLC，数量为 1.002 BTC，时间锁设置在 9 个块上向前。他使用与 Alice 相同的哈希值。 Bob 知道 Carol 必须找出秘密 R 才能解锁他发送的 HTLC，一旦她这样做了，他也会知道它，因此能够解锁 Alice 发送给他的 1.003 BTC。如果 Carol 无法找到秘密 R，Bob 和 Alice 将在时间锁到期时简单地取回他们的资金。我们还要注意，Bob 发送的资金量比他收到的资金少 0.001 BTC：这是他参与链的费用。 Bob 和 Carol 之间的通道余额如下：Carol 有 2 BTC，Bob 有 0.998 BTC，1.002 BTC 被锁定在 HTLC。
- Carol 在收到 Bob 的承诺交易后，在与 Diana 的通道上创建了一个 HTLC（使用 Bob 使用的哈希），金额为 1.001 BTC，并在前 8 个块上设置了时间锁。如果戴安娜能够在 8 个区块结束前发现秘密 R 并解锁 HTLC 以获得 1.001 BTC，那么 Carol 也将获悉秘密，因此能够解锁 Bob 发送给她的 1.002 BTC，从而获得 0.001 BTC。现在Carol和Diana之间的通道余额如下：Diana有2 BTC，Carol有0.999 BTC，1.001 BTC被锁定在HTLC中。
- 最后，Diana 向她的频道发送了一个 HTLC（总是使用相同的哈希）与 Eric 的数量为 1 BTC 和一个时间锁设置在前 7 个块上。 Diana 和 Eric 之间的通道余额如下：Eric 有 2 BTC，Diana 有 1 BTC，1 BTC 被锁定在 HTLC。
- 现在，我们已经到达了链条的末端。 Eric 拥有秘密 R，其哈希值用于所有 HTLC 承诺交易，他可以解锁 Diana 发送给他的 HTLC，并获得 1 BTC。一旦 Eric 使用该秘密接收资金，Diana 也可以使用该秘密。现在 Diana 和 Eric 之间的通道余额如下：Eric 有 3 BTC，Diana 有 1 BTC。
- Diana 收到秘密后，解锁了 Carol 发送的 1.001 比特币，并通过这样做向她透露了秘密。现在他们频道的余额如下：戴安娜有 3.001 比特币，卡罗尔有 0.999 比特币。
- Carol 收到秘密后，解锁了鲍勃发送的 1.002 比特币，并通过这样做向他揭示了秘密。现在他们频道的余额如下：Carol 有 3.002 BTC，Bob 有 0.998。
- 最后，Bob 使用这个秘密从他和 Alice 之间的通道中获得了 1.003 BTC。现在他们频道的余额如下：Bob 有 3.003 BTC，Alice 有 0.997。
通过这种方式，Alice 支付了 Eric 1 BTC，而没有打开直接链接它们的新通道。没有一个链参与者有义务信任他人，他们作为中间人赚取了 0.001 BTC 作为费用。如果链中的任何人未能完成他们的部分工作，那么没有人会损失那些会一直冻结直到时间锁到期的钱。
Clearing out failures
在我们的示例中，一切都很顺利，但在现实生活中，如果有什么地方出错，那就是出错了，所以让我们来看看闪电网络的“保护”机制。
显然，用于传递资金的链条越长，他们无法到达终点的可能性就越高：一些参与者可能会关闭通道，而另一些参与者可能会直接失去互联网连接。让我们检查一下出现问题的两种可能性。
Broken channel
在第一种情况下，让我们假设资金已经成功到达链的末端，但是在返回的路上（当秘密应该升级链，到达最开始时）出现了一个问题，一个参与者拒绝或无法要合作。在我们的示例中，它将是 Bob。
Diana，当锁链到达她时，立即取回她的资金，使用秘密并将其透露给 Carol。 Carol 也希望从 Bob 那里拿回她的钱，但他没有回应，为了规避风险，她关闭了通道，将最后一个承诺交易（Bob 之前发送的 HTLC 合约）发送到区块链中，并在区块链的帮助下秘密，取回资金。在这种情况下，Bob 仍有 3 天的时间出现并从 Alice 那里拿走他的钱（因为交易已经进入区块链，他可以很容易地找到它并看到 R）。否则，在时间锁定到期时，她将能够取回她所有的钱。
可以看出，如果参与者因某种原因离开系统，则只有他或她有损失资金的风险，而链上的所有其他参与者都是安全的。
Rerouting
在我们的第二种情况下，让我们检查资金没有到达链末端的情况，同样是因为其中一位参与者的问题。现在是 Carol。
第一种也是最明显的方法就是等到 HTLC 合约的到期时间才能取回资金并发送新的付款。
但是如果 Alice 很着急，他们该怎么办？当然，也可以不用等待资金归还，就可以通过另一条链发送新的付款，但是如果 Carol 回来，与 Bob 连接并完成该链呢？在这种情况下，Alice 将结束发送双倍的金额。
那么，在失败的情况下，我们是否应该一直等到到期时间才发送新的付款？幸运的是，为了避免等待时间锁到期，我们可以“取消之前的付款”。为此，戴安娜（收款人）应该向爱丽丝发送等量的钱，使用与第一次发送时相同的哈希值，并且链可以不同。现在，如果 Carol 回来并完成她的那部分工作，那么这笔钱就会绕圈子。这意味着失败的支付可以被认为是无效的，并且可以通过另一条链发送另一笔支付。
Payment amount
您可能已经注意到，虽然 Alice “取消”了第一笔付款并且现在可以发送新的付款，但这并不能改变资金被冻结且她可能没有足够的钱来重复该操作的事实。这就是为什么在使用闪电网络时，最好使用 HTLC 发送较小的金额。由于承诺交易不会进入区块链，因此金额可以分成非常小的部分。这意味着每当连锁店停止运营时，只有一小部分付款保持冻结状态，即最后发送的那部分。
Transport protocol
应该提到闪电网络的另一个非常重要的特性：关于链的整个信息是完全匿名的。这意味着链中的每个参与者只知道他或她的“部分”：例如，对于 Carol，付款看起来像是从 Bob 到 Diana 的资金转移，她不知道 Bob 从 Alice 那里得到了钱，也不知道 Diana将其转移给 Eric。
Lightning 使用 Sphinx 多重加密协议。使用闪电网络时，Alice 将网络的每个部分都包裹在一层加密中，从链的末端开始。她使用 Eric 的公钥为 Eric 加密消息。该消息包含在给戴安娜的消息中，该消息将依次用她自己的密钥加密，而给戴安娜的消息将包含在给卡罗尔的消息中，也用她的密钥加密，依此类推，直到链的开始。这样，Bob 将只能解密发往他的消息的上层，然后将消息进一步发送给 Carol 等。在每个阶段，只透露必要的信息：发送金额的大小，时间锁定等。
为了使通过消息的权重无法猜测链的长度，它具有固定的大小，就好像二十个人参与了网络一样。除了最后一个参与者，每个参与者都看到相同大小的图像，并认为还有 20 个参与者。
Benefits and use cases
当然，闪电网络的好处并不像许多人想象的那样归结为比特币的可扩展性。让我们考虑一下闪电网络带来的某些可能性。
- Instant transactions。使用闪电网络时，交易几乎是即时的。用比特币支付咖啡成为可能。
- Exchange Arbitrage。目前，资金从一个交易所快速转移到另一个交易所似乎是不可能的，因为需要 3 到 6 个区块来确认交易。如果交易所开始使用闪电网络，用户将能够立即转移资金，允许仲裁交易。交易所也将不再需要“冷”钱包来存储资金，从而大大降低了被盗的风险。
- Micropayments。比特币的佣金对于小额支付来说太高了。很难想象有人愿意支付 0.001 BTC 来转移相同或更少的金额。使用闪电网络，您将有可能立即转移任意数量的资金，例如，您将能够以兆字节为单位支付您的互联网费用。
- Financial smart contracts and transactions。金融合约对时间极为敏感，通常需要大量计算。通过将他们的多数转移到“外部”，我们有机会创建非常复杂的交易和合同，而无需将它们记录在区块链中。
- Cross-chain payments。如果不同共识规则的区块链中存在相似的哈希函数，它们之间就有可能进行交易。在这种情况下，参与者将无需相互信任或使用中间人。
- Privacy。在闪电网络中，交易比比特币区块链更匿名，因为用于支付的链的参与者看不到发送者或接收者。
Conclusion
我们现在已经完成了对闪电网络的分析。在我们的下一篇文章中，我们将告诉您如何使用 HTLC 合约在比特币和莱特币之间进行跨链原子交换。
