闪电网络:构建比特币的双向支付通道
2024-04-16
未确认的事务（Unconfirmed Transactions）
比特币协议的核心是所谓的 “事务” 的概念；一般来说，一笔事务总是关联着另一笔前序事务，并且可以用在未来的事务中。每笔事务都包括 输入，指向 转出 比特币的地址；以及 输出，指向 收到 比特币的地址。此外，为了发送比特币，输入还必须满足一些条件，比如要提供数字签名来证明发送者具有输入地址的 “所有权”。同时，输出也会确立这些比特币在日后使用时候的新条件，在 后序事务 发出的时候必须满足。
（把比特币想象成一张张有面额的支票，在使用时，支票自身给出了资金的来源，而在使用后又会形成新的支票。所以对每一张支票来说，都有形成这张支票的事务，也即是前序事务；而当这些支票被再次花用时，那笔事务就可称为后序事务。）
闪电网络的一个关键特性是，它是由或多或少的常规比特币事务组成的。只是，这些事务一般不会在比特币网络里传播。相反，这些事务都是用户保存在节点本地的 —— 只不过，它们随时可以放到比特币网络中传播。
杜绝多重支付（Double-Spend Protection）
闪电网络所需的第二个模块可能不需要太多解释，因为它可以说是比特币协议本身的存在理由：多重支付的防范措施。如果两笔事务（或者说输入）依赖于同一个输出，那只有其中一笔才会得到整个网络的确认。
谨记：即使尚未确认的事务之间发生了冲突，最终也只有一笔会得到确认。
多签名（Multisig）
闪电网络的第三个模块也很好理解：多签名地址。（或者更广义地说：P2SH 地址（脚本哈希值地址）。）
顾名思义，多签名地址就是需要多个私钥来 “解锁”、使用比特币的地址。多签名地址的条件可以设置得很多样。比如，可以要求在 3 把私钥中要有 2 把参与，才能转出比特币；或者是其它的数量要求（比如 2/5，3/4，等等）。
闪电网络一般使用 2-2 的多签名要求。要从这样的地址中转出比特币需要提供跟这两把私钥相关的两个签名，少一个都不行。
时间锁（Time-Locks）
第四个模块是时间锁。时间锁功能可以在一个输出中放置一个锁定条件，让这些比特币仅在未来某个时间之后才能花用（也即被用作一笔事务的输入）。
有两种类型的时间锁：1）绝对时间锁，叫做 CheckLockTimeVerify（CLTV）；2）相对时间锁，CheckSequenceVerify（CSV）。CLTV 会锁定比特币直至未来某个（可以说是）具体的具体：一个具体时间和日期，或者一个具体的区块高度；而 CSV 只会使用相对时间。当一个 CVS 输出上链之后，就要等待一定数量的区块后，这笔输出才能花用。
哈希值和秘密值
第五个，也是最后一个模块 —— 密码学 —— 也是比特币本身最基础的模块。但在闪电网络中，用法有所不同。
简而言之，一个 “秘密值” 是一个很长而且独一无二的数字串，是几乎不可能猜测出来的，一台电脑暴力运算无数次也猜不出来。而通过特殊的计算，这个秘密值又可以 “打散” 成一个不同的数，叫做 “哈希值”。有趣之处正是这里：知道这个秘密值得人可以很容易地计算出其哈希值，但反之不成立，拿着哈希值你是反推不出那个秘密值的。
在比特币区块链上，这个机关又可以用在 “锁定比特币” 上（实际上，锁定比特币就是比特币协议运行的方式）。举个例子，你可以在一个输出中包含一个哈希值，要求后序的事务只有包含该哈希值对应的秘密值才能花费这笔输出。
双向的支付通道
在闪电网络出现之前，就已经有 “支付通道” 的概念了。标准的支付通道是用于特定用途的，因此也很局限：它们都是单向的通道。Alice 可以在链下向 Bob 发起多比支付，但 Bob 没法用同一个通道给 Alice 支付。
而闪电网络的一个关键特性就是， Poon 和 Dryja 提出的免信任的双向支付通道。
开启通道
要建立一个双向的支付通道，参与的双方都必须首先对一笔开启通道事务达成共识。这笔开启事务决定了他们俩各要在这个通道中存入多少比特币。
假设 Alice 想给 Bob 发送 1 btc。因为他们俩都预期以后会有频繁往来，他们决定开启一个双向的支付通道。（在通道里发送 1 btc 可能有点太大了，毕竟通道可能对小额支付更有用 —— 但也是完全可以做到的。）
要开启这个通道，Alice 和 Bob 每人都发送 5 btc 到一个 2-2 的多签名地址里。这就是 “通道开启事务”。这个地址里面的钱，只有 Alice 和 Bob 签名同一笔事务才能花用。
此外，Alice 和 Bot 都各自创建一个秘密值（也就是一串数字），然后交换哈希值。
现在，Alice 创建一笔通道开启事务的后序事务，且这是一笔 “承诺事务”。在这笔承诺事务里，Alice 把 4 btc 发给她自己，而 6 btc 发送给第二个多签名地址；这个多签名地址更有趣：Bob 可以独自解锁这个地址，但是，要等（Alice 的事务上链后的） 1-00 个区块之后，Bob 才能花里面的钱（这是一个相对时间锁）；Alice 也可以独自打开这个地址，前提是她 也 拥有 Bob 给她的哈希值所对应的秘密值。（当然，Alice 是完全不知道这个秘密值的 —— 她只有 Bob 给她的哈希值 —— 所以只是表面上可以这么做而已。）（译者注：比特币的交易系统允许 “IF……ELSE” 这样多层的控制，所以这第二个多签地址可以支持在不同解锁条件下产生不同的行为。）
Alice 签名了她的承诺事务。但是她不会把这笔事务广播出去！相反，她只会把这笔事务发给 Bob。
同时，Bob 也做刚好对称的操作。他也创建一笔承诺事务，把 6 btc 发给自己，4btc 发给一个新的多签地址。Alice 在等待 1000 个区块后就可以独自解锁这个地址，或者 Bob 可以拿 Alice 的秘密值来解锁这个地址。
Bob 签名了这笔事务，然后发给了 Alice。
交换完了这些承诺事务和哈希值之后，他们再共同签名并把那笔通道开启事务广播出去，使之能够上链。现在，一个双向的支付通道就开好了。
开启通道之后，Alice 和 Bob 都可以签名和广播他们从对方那里得到的、部分有效的承诺事务。如果 Alice 广播了（Bob 发给她的承诺事务），则 Bob 会立即得到 6 btc。如果 Bod 广播了，则 Alice 会立即拿到 4 btc。但签名和广播事务的那个，必须等待 1000 个区块才能解锁那个后序的多签名地址，把剩余的比特币拿走。
不过，这就是支付通道的关键技巧：不去签名和广播他们得到的承诺交易。先交互承诺事务，再广播通道开启事务，是为了避免对手欺诈；而获得承诺事务之后，不必广播，也可以获得安全性保证了。
更新通道
后来，Bob 想给 Alice 发回 1 btc，他们想更新这个通道的状态，使之回到 5：5 的状态。要实现这一点，Alice 和 Bob 需要做两件事。
首先，双方都要把上面所讲的流程再做一遍（除了开启事务的那部分，因为已经记录在链上了）。这一次，Alice 和 Bob 都把 5 btc 分配给对方，都把 5 btc 分配给那个多签名地址。这些后续的多签名地址的条件是类似的，只不过，他们都需要生成 新的 秘密值：Alice 和 Bob 都要提供 新的 哈希值。他们都签名自己的新承诺事务，并发送给对方。
其次，Alice 和 Bob 都把他们的 第一个 秘密值（用在第一次承诺事务中的那个）交给对方。
这时候，Alice 和 Bob 都能签名和广播他们最新得到的这笔承诺事务。他们的对手会立即获得 5 btc，而广播这自己则必须等待 1000 个区块。就这样，通道的状态更新了。
但是，有什么能阻止 Bob 广播旧的承诺事务呢？那笔承诺事务会给他分配 6 btc，比 5 btc 要多 ……
阻止 Bob 的，当然就是他的第一个秘密值，也就是他已经给了 Alice 的那个秘密值。
因为，这时候 Bob 已经无法随心所欲地签名和广播更老的那笔承诺事务了，因为 Alice 已经知道了 Bob 的第一个秘密值。如果 Bob 要签名和广播（Alice 给他的那笔）更老的承诺事务，他会立即把 4 btc 发给 Alice …… 且他自己要等 1000 个区块才能申领，但是，Alice 已经知道他的秘密值了，所以她可以利用这段时间先发制人，直接把剩下的 6 btc 也提走！
而且，因为 Bob 也有了 Alice 的秘密值，所以对 Bob 来说同样如此！要是 Alice 想签名和广播旧的承诺事务，Bob 就可以偷走她放在通道里所有的 btc 了！
这就意味着 Alice 和 Bob 都有充足的激励不去耍小手段，只广播最近的状态。
网络
Alice 和 Bob 建立了一个双向的支付通道。现在，Alice 想要给一个第三方 Carol 支付 1 btc。
一般来说，Alice 和 Carol 需要在彼此之间开设一个支付通道。但实际上并不需要。因为 Bob 和 Carol 之间已经有了一个通道，所以 Alice 可以通过 Bob 给 Carol 支付。
具体来说，Alice 可以给 Bob 支付 1 btc，而 Bob 再支付 1 btc 给 Carol。
但是，Alice 实际上并不信任 Bob，或者 Carol 并不信任 Bob。她担心把钱给 Bob 之后，Bob 不会给 Carol；又或者，他把钱给了 Carol，但 Carol 谎称自己压根没见到钱，而 Alice 也不知道该找哪个来追责。
因此，Alice 希望能保证，仅当 Bob 给了 Carol 1 btc，自己才需要给 Bob 支付 1 btc。
当 Alice 要给 Carol 支付 1 btc 时，她让 Carol 先生成一个秘密值（一个随机的数字串）并把对应的哈希值发给她。Alice 也告诉 Carol 可以用这个秘密值跟 Bob 交换 1 btc。
与此同时，Alice 把从 Carol 处得到的哈希值发给 Bob，并告诉 Bob 如果 Bob 能提供对应于这个哈希值的原始值，她就会给 Bob 1 btc（这个原始值当然只有 Carol 拥有）。
所以 Bob 找到 Carol，用 1 btc 换来了 Carol 的初始值。
然后，Bob 找回 Alice，提供这个初始值。Alice 因此知道了 Bob 一定给过钱了，也就是 Carol 肯定已经收到了 1 btc，于是就把钱给了 Bob。
皆大欢喜。
几乎，啊，几乎是皆大欢喜。
在这种 “过家家” 的情形下，中间人 Bob 还是需要信任 Alice 和 Carol。Bob 必须相信 Carol 给他的是一个真正有用的值（不然钱都给了就拿不回来了），而且要相信 Alice 真的会给他 1 btc，假如他能提供对应于哈希值的原像的话。
哈希时间锁合约
哈希时间锁可以让 Alice 和 Bob 用秘密值来交换 btc（当然 Bob 和 Carol 也需要这个，但我们先按下不提）。
为了使用哈希时间锁，Alice 要将 1 btc 发送至一个新的多签地址，而非直接发送给 Bob。这个地址中锁定的 btc 可以通过两种方式解锁。
第一种方式是 Bob 将自己的签名和秘密值一起发送至该地址。
第二种方式是 Alice 将自己的签名发送至该地址。但是，这个方式存在 CLTV 时间锁限制：Alice 必须等待一段时间（例如两周）才能签署并广播交易取走这个 btc。
也就是说，Bob 有两周时间来创建一个包含签名和秘密值的交易，并广播该交易，将多签地址上的 btc 发送给自己。这样一来，这笔交易就有了保证。只要 Bob 能提供秘密值，他就能取走 Alice 的 btc：在比特币网络公开广播该交易可以让 Alice 看到它。
如果 Bob 没有在规定时限内提供秘密值，Alice 就可以取回她的 btc。就这么简单。
再说回网络，因为这是哈希时间锁合约真正发挥作用的地方。
如上文所述，不仅 Alice 和 Bob 之间有哈希时间锁合约，Bob 和 Carol 之间也有。因此，如果 Carol 向 Bob 索要 btc，Bob 也可以从 Carol 那里取得秘密值。这些在区块链上都是可见的。
因此，如果发生这种情况，Bob 也一定可以从 Alice 那里拿到 1 btc。Bob 可以将从 Carol 那里拿到的秘密值在链上公开，发送至他与 Alice 的哈希时间锁合约，然后取走多签地址上的 1 btc。这两个状态通道有效地关联了起来。
最后要强调的一点是，Bob 必须在有效期内从 Carol 那里拿到秘密值，否则 Alice 就有可能取回多签地址上的 1 btc。如果等 Alice 取回 1 btc 之后 Bob 才从 Carol 那里拿到了秘密值，Bob 就会被卡在中间进退两难。因此，Bob 和 Carol 的哈希时间锁合约必须比 Alice 和 Bob 的先到期（例如，前者的时限可以设成 10 天，而非两周）。这就是为什么哈希时间锁合约需要 CheckLockTimeVerify（绝对时间锁）而非 CheckSequenceVerify（相对时间锁）。
最后还有一个问题需要解决：要保证闪电网络的可用性，所有这些必须在链下完成。具体是如何实现的将在本系列第三篇文章中揭晓。
闪电网络
目前，Alice 和 Bob 已经开通了一个双向支付通道，并分别往通道中存入了 5btc。他们已经来回完成了两笔交易。在当前通道状态下，Alice 和 Bob 可以通过终止通道各自取回 5btc。
现在，他们想要在通道中放入一个哈希时间锁合约（HTLC），以确保 Bob 在用 1btc 交换 Carol 手中的秘密值后，Bob 可以从 Alice 那里取回 1btc。
就像之前的步骤一样（详见 Part 1），Alice 和 Bob 先要各自创建一笔新的承诺事务。这两个承诺事务跟之前创建的承诺事务很像，包含一个普通的输出、一个带有 CSV 时间锁（相对时间锁）的多签地址输出和一个特殊的哈希锁。接着，像之前的步骤一样，Alice 和 Bob 交换之前的秘密值来让之前的通道状态失效。一旦交换过秘密值后，Alice 和 Bob 就可以签署各自的承诺事务，并在任何时候将这承诺事务发送到区块链上。
这些步骤与之前的步骤基本相同，除了一点。Alice 和 Bob 新创建的承诺事务包含一个新的输出，而这个输出价值 1btc。（因此，支付通道中的 btc 余额变成了 Alice：4；Bob：5；新的输出：1。）
这个新的输出本质上是哈希时间锁合约，而且相比其它输出更有趣，因为有三种方式可以解锁它。
第一种方法是，只有当后序事务包含 Bob 的签名和秘密值时，(包含在 Alice 和 Bob 的承诺事务内的）新的输出才会释放 btc。无论 Alice 或 Bob 是否签署并广播承诺事务，只有 Bob 可以解锁该输出 —— 只要他将秘密值包含在后序事务内。但是，两个承诺事务存在一处细微差别：如果 Bob 终止通道，会受到 CSV 时间锁的约束。这时，Bob 必须等待 1000 个区块才能取回自己的 btc。（如果 Alice 终止通道，Bob 就可以立即取回自己的 btc。）
为什么 Bob 需要等待 1000 个区块呢？原因跟我们之前解释的差不多：如果 Bob 试图签署并广播过期的通道状态，Alice 就可以拿走 1 btc。这就是解锁输出的第二种方法。如果 Alice 提供 Bob 的（最新）秘密值，就可以 “偷走” 通道内的资金。
Alice 和 Bob 可以玩这样一个游戏：如果 Alice 试图广播过期的通道状态，Bob 可以使用 Alice 的秘密值取走那 1 btc（甚至无需提供秘密值）。
第三种方法是，与其它哈希时间锁合约一样，这两个承诺事务也包含常见的 CLTV 时间锁（绝对时间锁）超时退回机制，即，如果 Bob 没有在限期（比如两周）内将秘密值包含在后序事务内，Alice 就可以取回自己的1btc。在这种情况下，终止通道的人是 Alice 还是 Bob 都没关系。
那么，具体是如何操作的？
Alice 和 Bob 各自持有部分有效的承诺事务。如果 Alice 将自己持有的（也是 Bob 发给她的）承诺事务发送到区块链上，就会立即发送 5btc 给 Bob。Alice 则需要等待 1000 区块之后才能取回自己的 4btc。另外，Bob 有两周时间提供秘密值，解锁 “哈希时间锁合约输出” 对应的 1 btc。（如果他没有在两周内提供秘密值，Alice 就可以取回这 1btc。）
与此同时，Bob 随时都可以将他的承诺事务上链，并立即将 4btc 发送给 Alice。接着，他必须等待 1000 区块过后才能从一个地址那里取走 5 btc，如果他在限期内提供秘密值，还能解锁 “哈希时间锁合约输出” 对应的 1 btc。（如果他没有在两周内提供秘密值，Alice 就可以取回这 1btc。）
当然了，如果 Alice 或 Bob 在将来任何时候试图作恶，签署并广播过期的通道状态，另一方都可以阻止作恶方，并偷走通道内的所有 btc。
结算状态
这时，Bob 一定会收到 1btc 来交换他手中的秘密值（假如他有的话）。他要做的只是签署并广播他从 Alice 那里得到的承诺事务，将秘密值包含在一个后序事务内，然后签署并广播该后序事务。
Alice 知道这一点。她没有办法骗走 Bob 的 btc，即使她通过其它手段得到了秘密值。
因此，Alice 和 Bob 还不如在支付通道外进行 “结算”。Bob 可以将秘密值给 Alice，Alice 可以同意更新通道状态，这样就不需要哈希时间锁合约和截止日期了。
假设 Alice 和 Bob 都想让通道保持开启，这也很正常：比起在链上终止通道省事多了。
关闭通道
最后才是闪电网络真正强大的地方：
本系列文章中所述内容几乎都不需要实际上用到比特币区块链。
如果 Alice 和 Bob 想要和平关闭通道，可以创建一个事务来完全覆盖掉开启通道事务之后的所有事务。他们可以根据最新通道状态中所示的 btc 余额归属情况，通过关闭通道事务将自己应得的 btc 余额发送给自己。
具体来说，这意味着如果 Alice 想要关闭通道，她可以创建一个事务向自己支付 4btc，同时向 Bob 支付 6btc，然后让 Bob 签署并广播该事务。Bob 没有理由不答应这个请求，他大概率会配合 Alice 关闭该通道。
最后，只会有两笔事务被广播到比特币网络并打包进区块：开启通道事务和关闭通道事务。哪怕 Alice 和 Bob 之间发生了 100 万笔交易也是这个结果，因此极大地减轻了区块链的负担。
