初心
Aaron Van Wirdum的《闪电网络的历史：从头脑风暴，到测试版本》记录了2018年前闪电网络的有趣历史。
中本聪在2009年创造BTC的时候就有关于支付通道的想法，并且在Bitcoin 1.0里就已经包含了支付通道的最初代码实现，之后的几年，支付通道乃至闪电网络的想法一直在被BTC社区讨论。
Vitalik早年创办的bitcoinmagazine收录了闪电网络的许多重要文章，2013年底，Vitalik在考虑如何进一步扩展比特币和Mastercoin功能的时候，向Mastercoin团队提出了一个更通用的方案，该方案允许用灵活且可编写脚本（但不是图灵完备的）的合约取代Mastercoin的专业合约语言。虽然Mastercoin团队对此印象深刻，但这一提议太过激进，无法适应他们的发展路线图，建议被拒绝。
于是，被拒绝的Vitalik开始起草以太坊白皮书，以实现其关于链上智能合约的想法，而BTC的开发者们也逐渐形成共识 – 放弃在一层实现智能合约和扩容的路线，把一层的功能固定在安全性和基本功能上面，而把各种扩展放到链下实现，两条公链背后是两种理念。
成型
2015年2月是一个比较重要的时间节点，经历了程序员们的大量讨论之后，Thaddeus Dryja 和 Joseph Poon 一起撰写了一份名为 “The Bitcoin Lightning Network: Scalable Off-Chain Instant Payments ” 的白皮书，在 2015 年的 2 月首次发布，并且在旧金山比特币开发者研讨会（Bitcoin Devs Seminar）上首次展示了他们的构想。
在这之后的几个月，整个 2015 年的春天和夏天，比特币的扩展问题和区块大小上限的分歧演变成了公开的争执。在这种危机气氛中，人们在 2015 年底召开了连续两场大会：9 月份召开了 Scaling Bitcoin Montreal，10 月份是 Scaling Bitcoin Hong Kong。在蒙特利尔，Poon 和 Dryja 再次登台演讲，并且都在香港作了第二次更深入的演讲。
就在香港的大会之后，Gregory Maxwell 在比特币开发者邮件组中提出了一份扩展方案路线图。这张路线图突出地包括了闪电网络。它获得了比特币技术社区大部分人的支持，并且变成了 Bitcoin Core 项目在事实上的路线图。
闪电网络的白皮书包含许多技术含量很高的概念，并不太容易读懂。
闪电网络的基本组件是支付通道。
支付通道是怎么实现的呢？这里面包含着一系列的基于BTC交易逻辑的密码学技术手段和巧思，简而言之，在资金安全得到去信任保证的前提下，两个用户同时“充值”到一个2-of-2的多签地址，然后，通过互换签名交易信息来实现每次的余额更新/完成支付，在余额的限制之内，这样的支付无需上链，交易双方依靠对正确的签名交易信息的持有就可以确保自己的利益，在需要的时候，可以通过将最新的交易信息广播上链来进行链上结算，关闭支付通道。
然后，通过HTLC，大量的的支付网络可以连接起来，构成网络，支付可以通过这样的网络到达与支付者并没有直接通道连接的接受者，这样一个依赖于BTC链建立的线下支付网络，被称作闪电网络。
当然，这样的描述过于简化了，要了解细节，还请读白皮书。
建构
目标确定之后，BTC的拥趸们满腔热情地投入了闪电网络的建设。
为了创建和优化闪电网络，BTC进行了多次的协议更新，其中最大的一次是隔离见证。
隔离见证实现的事情是，把交易中的发起方签名部分分离出来可供单独引用。
这让一件事情成为可能，就是当交易A被签名好但还没有被广播的时候，基于交易A构建的子交易已经可以被广播了。这可以用于构建预先签名承诺交易，以化解将资金注入多签地址后的对手方风险，构建支付通道需要这项功能。
隔离见证的历史参见“The Long Road to SegWit: How Bitcoin’s Biggest Protocol Upgrade Became Reality”
在漫长的挣扎过后，隔离见证软分叉最终于 2017 年夏天在比特币区块链上激活，为闪电网络铺平了道路。
坦率讲，由支付通道自下而上构建成的闪电网络一开始就有许多问题，其中，最影响用户体验的应该是通道容量经济性问题，此外，还有支付时延问题，状态管理问题，HTLC问题，依赖于Tor的问题，详见Shinobi的《闪电网络尚不尽如人意之处》。
一个通道的生命周期中需要开通和关闭两笔链上交易，但这两笔交易的成本在许多情况下也足以构成进入门槛，而且，这种类似充值卡的模式在资金使用效率上绝对谈不上高效。
举个例子，假设推特想利用闪电网络为3亿活跃的推特用户中的1%开通打赏功能，那么就需要为这300万用户中的每一个都开通支付通道，假设每个通道占用资金0.01BTC，那么所有这些通道将占用资金3万BTC。
而按1ml.com上的统计，当前（2022年10月20日）闪电网络共有82623个支付通道，通道资金5001BTC.
BOLT
“闪电网络的白皮书是一份长而复杂的文件，包含许多技术含量很高的概念；在 2015 年，很少有人有时间和能力读完并且理解这份文件。但 Linux 系统内核长期开发者 Rusty Russell 学习了这份白皮书后，大家的基础认识提高了一大截。在 2015 年初的 系 列 博 客 中，Russell 为更广泛的读者 “翻译” 了这份白皮书（但还是比较挑人的）。
然后，在2015 年 3 月，Russell 接受 Blockstream 工程的聘请，开发一个 C 语言的闪电网络实现： c-lightning。事实证明，这是迈向实现的关键一步。一个几个月前才刚刚提出的概念，现在就有了一个世界顶尖的工程师来实现它。后来，Blockstream 的 Christian Decker 也加入了 Russell；其他人（包括 Corné Plooy） 也为这个开源项目做了贡献。
在 Russell 开始开发 c-lightning 不久之后，Blocksteam 就不是唯一一个入局实现闪电网络的公司了。在 2015 年夏天，ACINQ 这家更小的比特币科技公司（一开始计划开发基于智能卡的硬件钱包）决定也尝试一下这项富有前景的技术。这家位于巴黎的创业公司后来宣布他们开发者用 Scala 编程语言开发出了自己的闪电网络协议，叫做 eclair。
又过了几个月，第三个实现开始起步。在 2016 年 1 月，闪电网络白皮书的作者 Poon 和 Dryja，也跟 Elizabeth Stark 和 Olaoluwa “Laolu” Osuntokun 一道，成立了一个全新的公司来开发闪电网络：Lightning Labs。Lightning Labs 带头在 lnd 上开闸，这是一个用谷歌公司推出的 Go 编程语言（也叫 “golang”）实现的闪电网络 —— 他们在公司成立之前就开始开发了。
在成立公司大概一年后，在 2016 年底，Dryja 离开了 Lightning Labs，转而加入了 MIT Media Lab 的 Digital Currency Initiative，这个机构也雇用了Bitcoin Core 的顶尖开发者 Wladimir van der Laan 和多位 Bitcoin Core 的贡献者。在 MIT，Dryja 继续开发他在 Lightning Labs 起步的闪电网络实现，重命名为 lit。现在 lnd 和 lit 都可用。Lit 与 lnd 和其它实现有差异的点在于它把钱包和节点封装成了一个整体；现在，它还支持同时使用多种币。
此外，区块链公司 Bitfury（因其矿池服务和挖矿硬件而知名）也 fork 了 lnd 实现、做了另一个版本。这个版本的特殊之处在于，它在设计上做了牺牲，使得无需修复比特币网络的熔融性（malleability）—— 后面我们再详细说明。Bitfury 也在交易路由领域作了贡献，最著名的成果是 “Flare” 协议（只不过现在 Bitfury 版本的 lnd 开发似乎已经停滞下来了）（译者注：“熔融性” 的例子是，本质上是同一个签名的交易，可能会产生完全不同的哈希值（交易 ID），使交易变得无法跟踪；就像同一块金属可以熔成不同的形状一样）。
再后来，再 2016 年，主要的钱包服务商 Blockchain 宣布他们开发出了一个简化版的闪电网络，叫做 “thunder”。这个实现对标准的闪电网络实现做了比较大的牺牲，最明显的是它需要你信任网络中的对手方。也因为这种牺牲，它得以在 2016 年春天推出 alpha 版本，比其他开发团队要早得多。（虽然 thunder 也可能兼容闪电网络，但这一实现的开发似乎也已经停滞了。）
在 Scaling Bitcoin Milan 大会之后，第三次会议在 2016 年底举办，大部分闪电网络的贡献者都齐聚一堂（这场大会因此被称为第一次闪电网络峰会）。在这里，他们讨论了如何让所有的不同实现能相互操作，从而产生了一个叫做 “BOLT”的闪电网络协议规范（BOLT 是“闪电网络技术技术（Basis of Lightning Technology）” 的缩写）。”
-[《**闪电网络的历史：从头脑风暴，到测试版本**》](https://www.btcstudy.org/2020/09/03/history-lightning-brainstorm-beta/)
闪电网络白皮书做了理论设计，BOLT是闪电网络的协议栈。是我们今天所知的、实际上的闪电网络的基础。
OmniBOLT
2019 年 8 月 1 日出现的OmniBOLT是BOLT协议的加强版，由omni foundation提出，顾名思义，推出这一加强版协议的最大动力是让闪电网络增加对omnilayer资产的支持。
github上的信息显示，OmniBOLT还支持以下功能，其中的一些还在计划阶段：
OmniBOLT #05: Atomic Swap Protocol among Channels
OmniBOLT #06: Automatic Market Maker, Liquidity Pool and DEX
OmniBOLT #07: Hierarchical Deterministic (HD) wallet, Invoice Encoding
这里所说的原子交换是通过HTLC进行的，如下图。
这里需要注意一点的是，在第三步，Alice用R去解锁Tx 2获取BTC时，她必然需要把R暴露给Bob，这一点是保证交换原子性的关键。
当然，进行原子交换的双方不需要拥有一个直接的支付通道，只要存在连接双方的通道路由就可以，当然，如果路由长了，就会有路由费用问题，也会有交易时延问题。
那么可不可以有跨链的原子交换呢？当然可以，前提是交易双方拥有对应两条链的两个支付通道路由，而且这两条链的相关技术结构是一致的，如BTC和LTC。
事实上，在OmniBOLT还未出现的2017年11月，Ligntning Labs就进行过一次跨链的原子交换实验，详情见这里：https://blog.lightning.engineering/announcement/2017/11/16/ln-swap.html
对于那些持有BTC或者ominilayer资产的并且不愿在自家钱包之外交易的用户来说，这样的交易方式的出现是很有意义的。
OmniBOLT的AMM交易模型类似于uniswap v3。
这个交易模型是基于前面所述的原子交换构建的，这里不存在一个链上的智能合约，也不存在一个单个地址上的流动性池，所有的节点都可以用自己在通道里的资金提供流动性，这些通道里的资金被区分为“支付余额”和“流动性余额”。节点可以发消息给tracker，告知自己提供的流动性是多少，愿意参与做市的价格区间是多少。
tracker是一个交易撮合引擎，不断收集流动性信息和交易请求信息，可以匹配的时候，就帮助节点间撮合，达成交易。
节点并不需要信任tracker，节点可以去验证tracker提供的信息真伪以及是否符合自己的交易条件，然后决定是否确认交易。
这里节点参与做市有没有无常损失呢？跟uniswap v3一样，有，但LP可以通过设置做市价格区间将无常损失控制在较低的水平。
简而言之，这里的交易逻辑相当于uniswap v3 + 订单薄，只是是在一个分布式的流动性池上，基于原子交换的逻辑来实现的。
以上的种种技术手段，也可以用来实现抵押借贷，但到目前为止，github上面的信息显示，OmniBOLT的关于抵押借贷的设想还处在社区讨论可行性的阶段，并未列入开发路线图。
Taproot
2021年11月中，BTC完成了Taproot升级，这可以说是在隔离见证之后BTC最重要的一次升级，
Taproot 升级则是三个 BIPs 的汇编，这三个 BIPs 分别是 Schnorr 签名(BIP 340)、Taproot (BIP 341)和TapScript (BIP 342)，这三个升级统称为 BIP Taproot，它为比特币带来了更高效、更灵活、更私密的传输方式，其核心在于使用了 Schnorr 签名和 Merkel 抽象语法树(MAST)。
Taproot的原理，简单来说，就是定义了一种输出和两种花费路径。如上图所示，有Alice和Bob两个参与者，Taproot的运作过程如下:
将Alice和Bob的公钥聚合为：C=P_A+P_B
加入MerkleRoot，公钥聚合为：P=C+H(C||MerkleRoot)G，其中 H(C||MerkleRoot) 表示C和MerkleRoot的组合hash
锁定脚本中填入聚合公钥P，格式类似Segwit：[ver] [P]。ver表示版本号，Taproot中ver=1。
花费路径有两个，二选一：
签名模式：Alice和Bob全部签名产生聚合签名，填入见证脚本。利用聚合公钥P,对签名进行验证后即可花费。
脚本模式：Alice和Bob，有一个拒绝签名，可以走脚本模式。此时Alice想要完成花费，那么见证脚本中需要填入：符合Script 1的执行数据D, Script 1, C, Hash 2 。为了验证签名，首先利用Script 1, Hash2，计算MerkleRoot，然后验证 P==C+H(C||MerkleRoot)G 是否成立，最后构建完整脚本D||Script 1并执行脚本，验证结果是否为真。当上述验证通过后，即可完成花费。
Taproot按照签名模式进行花费时，多个参与方和单个参与方在区块链上看起来都长得是一样的，所以许多区块链分析将不可用，从而为所有 Taproot 用户保留隐私。与此同时，Taproot的脚本花费模式让用户可以实现复杂的支出条件。Taproot可以有效压缩交易脚本字节数。签名模式下随着参与者增加，EDSA交易脚本大小线性增长，Taproot交易脚本大小保持不变。脚本模式下随着脚本数量的增加，EDSA交易脚本大小线性增长，Taproot交易脚本大小对数增长。
Taproot让智能合约成为可能了吗？
Taproot的确让一些基于复杂条件的交易成为可能，Schnorr 签名也的确让大批量签名变得可行，但Taproot也并没有增强多少BTC的可编程性，它对BTC进行的“智能”加持依然是很有限的。
Taproot催生的最亮眼的孩子是Lighting Labs的Taro。
与Omnilayer和RGB一样，Taro在BTC链上发行资产的方式也是把资产交易元数据放到UTXO输出里面，不过Taro使用了新增的Taproot交易类型来实现这一切，因此应该更加地高效，隐私保护也更好。
RGB
比特币链下协议领域的研究和发展为比特币打开了一扇窗户，开发者们追求的已经远不止以去中心化的方式转移价值。他们开始尝试走得更远，比如说，用链下协议的方式实现智能合约， RGB 是这类项目中的佼佼者。
RGB 基于 Peter Todd 关于一次性密封和客户端验证的研究，并被 Giacomo Zucco 和社区在 2016 年设想为比特币和闪电网络上更好的资产发行协议。这些想法的进一步发展导致 Maxim Orlovsky 将 RGB 开发成一个更加全面的智能合约系统，他自 2019 年以来在社区的参与下领导了这个系统的实现。
根据官方描述，RGB 定义为一组允许我们以可扩展和保密的方式执行复杂智能合约的开源协议。它并非一个特定的网络（如比特币或闪电网络）；每个智能合约只是一组能用不同通信通道（默认为闪电网络）进行交互的合约参与者。RGB 利用比特币区块链作为其状态承诺层，并在链下维护智能合约的代码和数据，借此实现可扩展性。它利用比特币交易（以及脚本）作为智能合约的所有权控制系统；尽管智能合约的演化是通过一套链下方案来定义的。最后需要注意的是，所有内容都是在客户端验证的。
简而言之，RGB 是一个允许用户随时审计、执行和验证智能合约的系统，而无需任何额外的开销，它并没有按照 “传统” 的方式来使用区块链。
一些RGB的拥趸们看不上以太坊，下面这张出自他们之手的表很能表现他们的这种态度。
这里需要简单讨论一下比特币的可编程性以及对比一下比特币与以太坊的智能合约的不同。
比特币的运行基于两个基本的概念：交易和 UTXO。当一笔交易创造了一个新的UTXO的时候，会自带一个由锁定脚本表达的解锁条件，当下一个交易要话费这个UTXO的时候，必须提供相应数据，通过锁定脚本所指定的验证程序，否则就无法花费。若要编程比特币，不外乎要在交易层面或者脚本层面做文章。
比特币的编程工具箱，目前有签名，多重签名，哈希锁，时间锁，流程控制等工具。
对比一下以太坊和比特币，可以发现比特币的可编程性在下面这些方面有明显的限制：
它允许的验证程序不是任意的，只有有限的几种。
它不允许将资金的内部状态存储在脚本中。即使它规定了多条解锁路径，也无法限制各解锁路径能够动用的资金量，只要能解锁资金，运用任何一条路径都可以使用全部资金。也可以说，脚本是不会计算的。
它不允许限制资金的花费方式。在一个 UTXO 解锁之后，怎么花都可以，脚本完全无法限制资金的花费方式。
解锁脚本所表达的是完备、独立的解锁条件，它不允许我们表达对另一个 UTXO 的依赖。一个 UTXO 不会（也不能）根据另一个 UTXO 存不存在来决定自己能不能解锁，也不会（不能）根据另一个 UTXO 的锁定条件来决定自己能不能解锁。一言以蔽之，在花费一个 UTXO 时，该 UTXO 的锁定脚本和交易所提供的解锁脚本就是一个独立的宇宙，不受任何外在的东西干扰。
如果我们问一位热爱BTC的技术专家，BTC支持智能合约吗？他很可能会说，BTC从一开始就是支持智能合约的。
我们没法说他错，因为简单的脚本程序也可以说是智能合约，闪电网络可以说是基于BTC区块链运行的合约式协议，我们仔细研究闪电网络时，会发现一些特点，可能是BTC原生智能合约的共同特点：
可以使用交易来表达合约的状态，交易的更替就表示合约状态的变化。
如果进入一种状态会面临失控的风险，可以通过预先签名承诺交易，来约束进入这种状态之后的走向，从而消除相应的对手方风险。比如，进入一个 2-of-2 多签名输出有可能导致资金被锁定，那就先安排一笔花费这个输出的交易。
除了退出合约以外，状态的更新总是需要所有参与方在线。
表达状态的历史交易需要参与方各自存储（至少在目前是如此）。
锁定脚本的主要作用是安排合约参与者的行动优先权，而不是直接产生结果；换言之，基于比特币的协议编程是在运用博弈学。
比特币的编程对应用开发人员和应用参与者都提出了更高的要求，这些限制使得应用开发起来更不直观、更难分析，打个不恰当的比方，有点像螺丝壳里做道场，或者用汇编语言写操作系统。用户也不能依靠区块链来为他们提供充足的便利，而必须自己承担更多的责任（比如在闪电网络中，你需要自己保管历史状态交易和相应的哈希原像，或者至少要有人负责保管）。
我们不能说BTC如此限制可编程性没有意义，比特币一直在事实上奉行着一种“资源使用最小化”原则，拒绝低成本交易占用区块空间，扩展？到链下去。现在的这种状态是坚持初心的自然结果。
在以太坊的语境里，“智能合约”意味着在虚拟机环境中确定性的运行的不可变的计算机程序，合约部署在链上的合约账户中，EVM在每个以太坊节点上作为本地实例运行，但由于EVM的所有实例都在相同的初始状态下运行并产生相同的最终状态，因此整个系统表现为单台图灵完备的世界计算机。
交易的原子性由EVM运行的规则保证，无论合约在被调用时执行的是什么。仅在交易成功终止时记录全局状态（合约，帐户等）的任何更改。成功终止意味着程序执行时没有错误并且达到执行结束。如果交易由于错误而失败，则其所有效果（状态变化）都会“回滚”，就好像交易从未运行一样。失败的交易仍存储在区块链中，并从原始账户扣除gas成本，但对合约或账户状态没有其他影响。
这里，智能合约上链，所有状态上链，带来的结果是良好的开发者和用户体验，当然，还有区块链的膨胀。
我们无法简单评判哪条道路的对错，这是选择的问题。
当然，RGB团队是BTC道路的深度信仰者，他们如此解释他们的选择：
当前的区块链行业提倡把智能合约代码和数据都存储在区块链上，并由全网所有节点执行，而无视区块链体积的过度增长和计算资源的滥用。由 RGB 提出的方案则更加智能和高效，因为它通过将智能合约和数据从区块链中分离出来而摆脱了区块链范式，从而避免了在其它平台上常见的网络饱和的情况，反过来，它并不要求每个节点都执行每份合约，而是将执行者变成了合约的相关方，这带来了前所未见的保密性。
RGB 上的智能合约开发者定义了一套方案来规定合约如何随时间推移而演化。这套方案是在 RGB 中构建智能合约的标准，发行者在定义发行的合约时和钱包或交易所在面对具体的合约时，必须先以这套标准来验证合约。只有当验证无误时，每个参与方才能接受请求并处理相应的资产。
RGB 中的智能合约是一个由状态变更构成的有向无环图（DAG），该图始终只有一部分是已知的，其余部分则无法访问。RGB 方案是规定智能合约如何演化的一组核心规则，是所有智能合约的起点。每个合约参与方都可以对这组规则进行补充（在架构允许的前提下），由此产生的图是根据这些规则的迭代式应用而构建的。
- Francisco Calderon[《A brief Introduction to RGB Protocols》](https://bitcoinmagazine.com/guides/a-brief-introduction-to-rgb-protocols)
听起来很美好，但既然把比特币区块链当成状态承诺层，就必然受制于BTC可编程性的局限，在许多场景之下，这些局限都是相当关键的。
RGB的开发目前也基本上只是走到了发行资产这一步，链下智能合约的实现绝不会顺利，是否真正有机会匹敌乃至超越链上智能合约更要打上一个大大的问号。
前景
几个月来，闪电网络领域大额融资频出，尤其被关注的是以下几个：
加密支付应用提供商Strike 融资 8000 万美元。
Lightning Labs 获得 7000 万美元融资。
lightspark从a16z和paradigm获得投资，投资额未披露。
闪电网络的通道容量近两年有了较大的增长：
背后主要是这些机构的力量：
虽然增长较快，但目前闪电网络的整体容量与粉丝们对它的期望相比还是很不相符的。下面是1ml10月20日的数据。
毕竟跨链到ETH的BTC有17万以上。
基于闪电网络的衍生品交易平台Kollider， 10月22日日交易量约1.1BTC。
毕竟闪电网络更适合于微支付，并不太适合于大额交易。
闪电网络对于BTC代表的链下扩容路线有着里程碑的意义，虽然一路艰辛，但在开发者努力，大额融资与社区热望加持之下，闪电网络应该是能掀起一波应用热潮的。
毕竟气氛已经烘托到这里了。
但鉴于其局限，也不应该对其抱有不切实际的期望。
