区块链神吐槽闪电网络（Lightning Network）可能是比特币区块链上最受期待的创新（编者注：原文撰写于 2016 年）。这种支付方案最早由 Joseph Poon 和 Tadge Dryja 在一年多以前提出，号称能支持用户之间在链下发送无限次的交易，而且成本极低 —— 还能借用比特币网络提供的安全性。
至少有三家公司 —— Poon 和 Dryja 的 Lightning、Blockstream 和 Blockchain 正在开发这种技术的实现。但在技术人员的小圈子之外，很少有人理解 “微支付的未来”如何能引爆比特币的潜能。
在本系列文章里，Bitcoin Magazine 尝试列举闪电网络最基础的砖石，并展示这些东西如何能组合出闪电网络这种即将到来的协议。
本系列的第一篇文章将列举必要的模块并展示这些模块如何能组合起来创建 “智能合约”；这个概念可以用来理解闪电网络的第一个前提：双向的支付通道。
（提示：非常熟悉比特币的读者可以跳过对这些模块的介绍。）
比特币闪电网络（Lightning Network）原理风险节点基础设施
模块 #1：未确认的事务（Unconfirmed Transactions）
比特币协议的核心是所谓的 “事务” 的概念；一般来说，一笔事务总是关联着另一笔前序事务，并且可以用在未来的事务中。每笔事务都包括 输入，指向 转出 比特币的地址；以及 输出，指向 收到 比特币的地址。此外，为了发送比特币，输入还必须满足一些条件，比如要提供数字签名来证明发送者具有输入地址的 “所有权”。同时，输出也会确立这些比特币在日后使用时候的新条件，在 后序事务 发出的时候必须满足。
（译者注：把比特币想象成一张张有面额的支票，在使用时，支票自身给出了资金的来源，而在使用后又会形成新的支票。所以对每一张支票来说，都有形成这张支票的事务，也即是前序事务；而当这些支票被再次花用时，那笔事务就可称为后序事务。）
闪电网络的一个关键特性是，它是由或多或少的常规比特币事务组成的。只是，这些事务一般不会在比特币网络里传播。相反，这些事务都是用户保存在节点本地的 —— 只不过，它们随时可以放到比特币网络中传播。
- （译者注：如图所示，比特币就像支票一样可以拆分，且其流转会形成清晰的链条。） -
模块 #2：杜绝多重支付（Double-Spend Protection）
闪电网络所需的第二个模块可能不需要太多解释，因为它可以说是比特币协议本身的存在理由：多重支付的防范措施。如果两笔事务（或者说输入）依赖于同一个输出，那只有其中一笔才会得到整个网络的确认。
谨记：即使尚未确认的事务之间发生了冲突，最终也只有一笔会得到确认。
模块 #3：多签名（Multisig）
闪电网络的第三个模块也很好理解：多签名地址。（或者更广义地说：P2SH 地址（脚本哈希值地址）。）
顾名思义，多签名地址就是需要多个私钥来 “解锁”、使用比特币的地址。多签名地址的条件可以设置得很多样。比如，可以要求在 3 把私钥中要有 2 把参与，才能转出比特币；或者是其它的数量要求（比如 2/5，3/4，等等）。
闪电网络一般使用 2-2 的多签名要求。要从这样的地址中转出比特币需要提供跟这两把私钥相关的两个签名，少一个都不行。
模块 #4：时间锁（Time-Locks）
第四个模块是时间锁。时间锁功能可以在一个输出中放置一个锁定条件，让这些比特币仅在未来某个时间之后才能花用（也即被用作一笔事务的输入）。
有两种类型的时间锁：1）绝对时间锁，叫做 CheckLockTimeVerify（CLTV）；2）相对时间锁，CheckSequenceVerify（CSV）。CLTV 会锁定比特币直至未来某个（可以说是）具体的具体：一个具体时间和日期，或者一个具体的区块高度；而 CSV 只会使用相对时间。当一个 CVS 输出上链之后，就要等待一定数量的区块后，这笔输出才能花用。
模块 #5：哈希值和秘密值
第五个，也是最后一个模块 —— 密码学 —— 也是比特币本身最基础的模块。但在闪电网络中，用法有所不同。
简而言之，一个 “秘密值” 是一个很长而且独一无二的数字串，是几乎不可能猜测出来的，一台电脑暴力运算无数次也猜不出来。而通过特殊的计算，这个秘密值又可以 “打散” 成一个不同的数，叫做 “哈希值”。有趣之处正是这里：知道这个秘密值得人可以很容易地计算出其哈希值，但反之不成立，拿着哈希值你是反推不出那个秘密值的。
在比特币区块链上，这个机关又可以用在 “锁定比特币” 上（实际上，锁定比特币就是比特币协议运行的方式）。举个例子，你可以在一个输出中包含一个哈希值，要求后序的事务只有包含该哈希值对应的秘密值才能花费这笔输出。
第一个挑战：双向的支付通道
在闪电网络出现之前，就已经有 “支付通道” 的概念了。标准的支付通道是用于特定用途的，因此也很局限：它们都是单向的通道。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 给她的哈希值 —— 所以只是表面上可以这么做而已。）（译者注：即，这第二个多签地址既有时间锁，也有哈希锁。）
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 都要重组的激励不去耍小手段，只广播最近的状态。
好了，有了双向的支付通道之后，我们要把它拓展成一个支付网络。这就是我们第二篇的主题。
感谢 Rusty Russell 和 Joseph Poon 的专门反馈。
（完）（文内有许多超链接，可点击左下 ”阅读原文“ 从 EthFans 网站上获取）
原文链接:
https://bitcoinmagazine.com/technical/understanding-the-lightning-network-part-building-a-bidirectional-payment-channel-1464710791
作者: AARON VAN WIRDUM
翻译: 阿剑
https://mp.weixin.qq.com/s/CEn4BvbHHlp0lnWgE8YNaw
网络
在上一篇文章中，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，假如他能提供对应于哈希值的原像的话。
这时候，我们就需要哈希时间锁合约（HTLC）啦！
哈希时间锁合约
哈希时间锁可以让 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（相对时间锁）。
最后还有一个问题需要解决：要保证闪电网络的可用性，所有这些必须在链下完成。具体是如何实现的将在本系列第三篇文章中揭晓。
原文链接:
https://bitcoinmagazine.com/technical/understanding-the-lightning-network-part-creating-the-network-1465326903
作者: AARON VAN WIRDUM
翻译&校对: 闵敏 & 阿剑
以太坊爱好者
微信号：ethfans
功能介绍：以太坊爱好者
