初心
AaronVanWirdum的《闪电网络的历史：从头脑风暴，到测试版本》记录了2018年前闪电网络的有趣历史。
中本聪在2009年创造BTC的时候就有关于支付通道的想法，并且在Bitcoin1.0里就已经包含了支付通道的最初代码实现，之后的几年，支付通道乃至闪电网络的想法一直在被BTC社区讨论。
Vitalik早年创办的bitcoinmagazine收录了闪电网络的许多重要文章，2013年底，Vitalik在考虑如何进一步扩展比特币和Mastercoin功能的时候，向Mastercoin团队提出了一个更通用的方案，该方案允许用灵活且可编写脚本的合约取代Mastercoin的专业合约语言。虽然Mastercoin团队对此印象深刻，但这一提议太过激进，无法适应他们的发展路线图，建议被拒绝。
于是，被拒绝的Vitalik开始起草以太坊白皮书，以实现其关于链上智能合约的想法，而BTC的开发者们也逐渐形成共识-放弃在一层实现智能合约和扩容的路线，把一层的功能固定在安全性和基本功能上面，而把各种扩展放到链下实现，两条公链背后是两种理念。
成型
2015年2月是一个比较重要的时间节点，经历了程序员们的大量讨论之后，ThaddeusDryja和JosephPoon一起撰写了一份名为“TheBitcoinLightningNetwork:ScalableOff-ChainInstantPayments”的白皮书，在2015年的2月首次发布，并且在旧金山比特币开发者研讨会上首次展示了他们的构想。
在这之后的几个月，整个2015年的春天和夏天，比特币的扩展问题和区块大小上限的分歧演变成了公开的争执。在这种危机气氛中，人们在2015年底召开了连续两场大会：9月份召开了?ScalingBitcoinMontreal，10月份是?ScalingBitcoinHongKong。在蒙特利尔，Poon和Dryja?再次登台演讲，并且都在香港作了第二次更深入的演讲。
就在香港的大会之后，GregoryMaxwell在比特币开发者邮件组中提出了一份扩展方案路线图。这张路线图突出地包括了闪电网络。它获得了比特币技术社区大部分人的支持，并且变成了BitcoinCore项目在事实上的路线图。
闪电网络的白皮书包含许多技术含量很高的概念，并不太容易读懂。
闪电网络的基本组件是支付通道。
支付通道是怎么实现的呢？这里面包含着一系列的基于BTC交易逻辑的密码学技术手段和巧思，简而言之，在资金安全得到去信任保证的前提下，两个用户同时“充值”到一个2-of-2的多签地址，然后，通过互换签名交易信息来实现每次的余额更新/完成支付，在余额的限制之内，这样的支付无需上链，交易双方依靠对正确的签名交易信息的持有就可以确保自己的利益，在需要的时候，可以通过将最新的交易信息广播上链来进行链上结算，关闭支付通道。
然后，通过HTLC，大量的的支付网络可以连接起来，构成网络，支付可以通过这样的网络到达与支付者并没有直接通道连接的接受者，这样一个依赖于BTC链建立的线下支付网络，被称作闪电网络。
数据：比特币闪电网络容量在过去一年中激增近两倍:与比特币价格一样，比特币闪电网络在过去一年也显示出强劲增长。根据LookIntoBitcoin提供的统计数据，比特币闪电网络的节点数量已经从7500激增到1.4万。与此同时，闪电网络上流通的比特币数量也翻了一番。（Coin Gape）[2021/8/16 22:16:53]
当然，这样的描述过于简化了，要了解细节，还请读白皮书。
建构
目标确定之后，BTC的拥趸们满腔热情地投入了闪电网络的建设。
为了创建和优化闪电网络，BTC进行了多次的协议更新，其中最大的一次是隔离见证。
隔离见证实现的事情是，把交易中的发起方签名部分分离出来可供单独引用。
这让一件事情成为可能，就是当交易A被签名好但还没有被广播的时候，基于交易A构建的子交易已经可以被广播了。这可以用于构建预先签名承诺交易，以化解将资金注入多签地址后的对手方风险，构建支付通道需要这项功能。
隔离见证的历史参见“TheLongRoadtoSegWit:HowBitcoin’sBiggestProtocolUpgradeBecameReality”
在漫长的挣扎过后，隔离见证软分叉最终于2017年夏天在比特币区块链上激活，为闪电网络铺平了道路。
坦率讲，由支付通道自下而上构建成的闪电网络一开始就有许多问题，其中，最影响用户体验的应该是通道容量经济性问题，此外，还有支付时延问题，状态管理问题，HTLC问题，依赖于Tor的问题，详见Shinobi的《闪电网络尚不尽如人意之处》。
一个通道的生命周期中需要开通和关闭两笔链上交易，但这两笔交易的成本在许多情况下也足以构成进入门槛，而且，这种类似充值卡的模式在资金使用效率上绝对谈不上高效。
举个例子，假设推特想利用闪电网络为3亿活跃的推特用户中的1%开通打赏功能，那么就需要为这300万用户中的每一个都开通支付通道，假设每个通道占用资金0.01BTC，那么所有这些通道将占用资金3万BTC。
而按1ml.com上的统计，当前闪电网络共有82623个支付通道，通道资金5001BTC.
BOLT
“闪电网络的白皮书是一份长而复杂的文件，包含许多技术含量很高的概念；在2015年，很少有人有时间和能力读完并且理解这份文件。但Linux系统内核长期开发者RustyRussell学习了这份白皮书后，大家的基础认识提高了一大截。在2015年初的?系?列?博?客?中，Russell为更广泛的读者“翻译”了这份白皮书。
然后，在2015年3月，Russell接受Blockstream工程的聘请，开发一个C语言的闪电网络实现：?c-lightning。事实证明，这是迈向实现的关键一步。一个几个月前才刚刚提出的概念，现在就有了一个世界顶尖的工程师来实现它。后来，Blockstream的ChristianDecker也加入了Russell；其他人也为这个开源项目做了贡献。
在Russell开始开发c-lightning不久之后，Blocksteam就不是唯一一个入局实现闪电网络的公司了。在2015年夏天，ACINQ?这家更小的比特币科技公司决定也尝试一下这项富有前景的技术。这家位于巴黎的创业公司后来宣布他们开发者用Scala编程语言开发出了自己的闪电网络协议，叫做eclair。
闪电网络节点数量已达12942个:金色财经报道，据1ML.com数据，目前，支撑网络的节点数量达到12942个，相较30天前数据，环比上涨0.26%；通道数量为37160，相较30天前数据，环比上涨4.2%；闪电网络承载能力目前为970.90BTC，约合878.40万美元。[2020/6/29]
又过了几个月，第三个实现开始起步。在2016年1月，闪电网络白皮书的作者Poon和Dryja，也跟ElizabethStark和Olaoluwa“Laolu”Osuntokun一道，成立了一个全新的公司来开发闪电网络：LightningLabs。LightningLabs带头在?lnd?上开闸，这是一个用谷歌公司推出的Go编程语言实现的闪电网络——他们在公司成立之前就开始开发了。
在成立公司大概一年后，在2016年底，Dryja离开了LightningLabs，转而加入了?MITMediaLab的DigitalCurrencyInitiative，这个机构也雇用了BitcoinCore的顶尖开发者WladimirvanderLaan和多位BitcoinCore的贡献者。在MIT，Dryja继续开发他在LightningLabs起步的闪电网络实现，重命名为?lit。现在lnd和lit都可用。Lit与lnd和其它实现有差异的点在于它把钱包和节点封装成了一个整体；现在，它还支持同时使用多种币。
此外，区块链公司?Bitfury也fork了lnd实现、做了另一个版本。这个版本的特殊之处在于，它在设计上做了牺牲，使得无需修复比特币网络的熔融性——后面我们再详细说明。Bitfury也在交易路由领域作了贡献，最著名的成果是“Flare”协议，使交易变得无法跟踪；就像同一块金属可以熔成不同的形状一样）。
再后来，再2016年，主要的钱包服务商Blockchain宣布他们开发出了一个简化版的闪电网络，叫做“thunder”。这个实现对标准的闪电网络实现做了比较大的牺牲，最明显的是它需要你信任网络中的对手方。也因为这种牺牲，它得以在2016年春天推出alpha版本，比其他开发团队要早得多。
在ScalingBitcoinMilan大会之后，第三次会议在2016年底举办，大部分闪电网络的贡献者都齐聚一堂。在这里，他们讨论了如何让所有的不同实现能相互操作，从而产生了一个叫做“BOLT”的闪电网络协议规范”的缩写）。”
??????????????????????????????????????????????????????????????????-(https://www.btcstudy.org/2020/09/03/history-lightning-brainstorm-beta/)
闪电网络白皮书做了理论设计，BOLT是闪电网络的协议栈。是我们今天所知的、实际上的闪电网络的基础。
OmniBOLT
2019年8月1日出现的OmniBOLT是BOLT协议的加强版，由omnifoundation提出，顾名思义，推出这一加强版协议的最大动力是让闪电网络增加对omnilayer资产的支持。
比特币闪电网节点数量达12163个:金色财经报道，据1ML数据，当前比特币闪电网络节点数为12163个，过去30天内增加4.64%；通道数量为36315个，过去30天内增加2.7%；网络容量达到956.29个BTC，过去30天内增加10%。[2020/4/14]
github上的信息显示，OmniBOLT还支持以下功能，其中的一些还在计划阶段：
OmniBOLT#05:?AtomicSwapProtocolamongChannels
OmniBOLT#06:?AutomaticMarketMaker,LiquidityPoolandDEX
OmniBOLT#07:?HierarchicalDeterministic(HD)wallet,InvoiceEncoding
这里所说的原子交换是通过HTLC进行的，如下图。
这里需要注意一点的是，在第三步，Alice用R去解锁Tx2获取BTC时，她必然需要把R暴露给Bob，这一点是保证交换原子性的关键。
当然，进行原子交换的双方不需要拥有一个直接的支付通道，只要存在连接双方的通道路由就可以，当然，如果路由长了，就会有路由费用问题，也会有交易时延问题。
那么可不可以有跨链的原子交换呢？当然可以，前提是交易双方拥有对应两条链的两个支付通道路由，而且这两条链的相关技术结构是一致的，如BTC和LTC。
事实上，在OmniBOLT还未出现的2017年11月，LigntningLabs就进行过一次跨链的原子交换实验，详情见这里：https://blog.lightning.engineering/announcement/2017/11/16/ln-swap.html
对于那些持有BTC或者ominilayer资产的并且不愿在自家钱包之外交易的用户来说，这样的交易方式的出现是很有意义的。
OmniBOLT的AMM交易模型类似于uniswapv3。
这个交易模型是基于前面所述的原子交换构建的，这里不存在一个链上的智能合约，也不存在一个单个地址上的流动性池，所有的节点都可以用自己在通道里的资金提供流动性，这些通道里的资金被区分为“支付余额”和“流动性余额”。节点可以发消息给tracker，告知自己提供的流动性是多少，愿意参与做市的价格区间是多少。
tracker是一个交易撮合引擎，不断收集流动性信息和交易请求信息，可以匹配的时候，就帮助节点间撮合，达成交易。
节点并不需要信任tracker，节点可以去验证tracker提供的信息真伪以及是否符合自己的交易条件，然后决定是否确认交易。
动态 | 闪电网络客户端Eclair更新0.3.3版本 新增多路径支付功能:闪电网络客户端 Eclair 发布0.3.3版本，新增多路径支付功能。除此之外，还修复了多个缺陷，增加数项改进，并与之前的老版本兼容。本次最重要的更新是增加了多路径支付（Multipart payments）功能，这也就意味着单个支付流程可以拆分为多个更小的支付金额并通过不同的通道发送，所有的流程都是通过原子（atomic）的方式进行，也就是所有拆分出的小额支付同时成功或同时失败。另外，本次还新添了确定性编译（Deterministic builds）、蹦床路由功能预览（Trampoline Routing Preview）以及其他一些接口（API）层面的调整。此前消息，今年1月和去年12月，闪电网络的另外两个主要客户端lnd和c-lightning也进行了主要更新，新增多路径支付功能和其他特性。[2020/2/2]
这里节点参与做市有没有无常损失呢？跟uniswapv3一样，有，但LP可以通过设置做市价格区间将无常损失控制在较低的水平。
简而言之，这里的交易逻辑相当于uniswapv3+订单薄，只是是在一个分布式的流动性池上，基于原子交换的逻辑来实现的。
以上的种种技术手段，也可以用来实现抵押借贷，但到目前为止，github上面的信息显示，OmniBOLT的关于抵押借贷的设想还处在社区讨论可行性的阶段，并未列入开发路线图。
Taproot
2021年11月中，BTC完成了Taproot升级，这可以说是在隔离见证之后BTC最重要的一次升级，
Taproot升级则是三个BIPs的汇编，这三个BIPs分别是Schnorr签名(BIP340)、Taproot(BIP341)和TapScript(BIP342)，这三个升级统称为BIPTaproot，它为比特币带来了更高效、更灵活、更私密的传输方式，其核心在于使用了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表示版本号，Taproot中ver=1。
花费路径有两个，二选一：
签名模式：Alice和Bob全部签名产生聚合签名，填入见证脚本。利用聚合公钥P,对签名进行验证后即可花费。
脚本模式：Alice和Bob，有一个拒绝签名，可以走脚本模式。此时Alice想要完成花费，那么见证脚本中需要填入：符合Script1的执行数据D,Script1,C,Hash2。为了验证签名，首先利用Script1,Hash2，计算MerkleRoot，然后验证P==C+H(C||MerkleRoot)G是否成立，最后构建完整脚本D||Script1并执行脚本，验证结果是否为真。当上述验证通过后，即可完成花费。
动态 | 闪电网络节点数量达11145个:据1ML.com数据显示，闪电网络节点数量呈持续上升趋势。目前，支撑网络的节点数量达到11145个，在过去的30天中上涨了2.40%，而通道数量为35929，在过去的30天中增长了2.0%。闪电网络承载能力目前为885.21BTC，约合748.31万美元[2020/1/25]
Taproot按照签名模式进行花费时，多个参与方和单个参与方在区块链上看起来都长得是一样的，所以许多区块链分析将不可用，从而为所有Taproot用户保留隐私。与此同时，Taproot的脚本花费模式让用户可以实现复杂的支出条件。Taproot可以有效压缩交易脚本字节数。签名模式下随着参与者增加，EDSA交易脚本大小线性增长，Taproot交易脚本大小保持不变。脚本模式下随着脚本数量的增加，EDSA交易脚本大小线性增长，Taproot交易脚本大小对数增长。
Taproot让智能合约成为可能了吗？
Taproot的确让一些基于复杂条件的交易成为可能，Schnorr签名也的确让大批量签名变得可行，但Taproot也并没有增强多少BTC的可编程性，它对BTC进行的“智能”加持依然是很有限的。
Taproot催生的最亮眼的孩子是LightingLabs的Taro。
与Omnilayer和RGB一样，Taro在BTC链上发行资产的方式也是把资产交易元数据放到UTXO输出里面，不过Taro使用了新增的Taproot交易类型来实现这一切，因此应该更加地高效，隐私保护也更好。
RGB
比特币链下协议领域的研究和发展为比特币打开了一扇窗户，开发者们追求的已经远不止以去中心化的方式转移价值。他们开始尝试走得更远，比如说，用链下协议的方式实现智能合约，RGB是这类项目中的佼佼者。
RGB基于PeterTodd关于一次性密封和客户端验证的研究，并被GiacomoZucco和社区在2016年设想为比特币和闪电网络上更好的资产发行协议。这些想法的进一步发展导致MaximOrlovsky将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中的智能合约是一个由状态变更构成的有向无环图，该图始终只有一部分是已知的，其余部分则无法访问。RGB方案是规定智能合约如何演化的一组核心规则，是所有智能合约的起点。每个合约参与方都可以对这组规则进行补充，由此产生的图是根据这些规则的迭代式应用而构建的。
??????????????????????????????????????-?Francisco?Calderon(https://bitcoinmagazine.com/guides/a-brief-introduction-to-rgb-protocols)
听起来很美好，但既然把比特币区块链当成状态承诺层，就必然受制于BTC可编程性的局限，在许多场景之下，这些局限都是相当关键的。
RGB的开发目前也基本上只是走到了发行资产这一步，链下智能合约的实现绝不会顺利，是否真正有机会匹敌乃至超越链上智能合约更要打上一个大大的问号。
前景
几个月来，闪电网络领域大额融资频出，尤其被关注的是以下几个：
加密支付应用提供商Strike融资8000万美元。?
LightningLabs获得7000万美元融资。
lightspark从a16z和paradigm获得投资，投资额未披露。
闪电网络的通道容量近两年有了较大的增长：
背后主要是这些机构的力量：
虽然增长较快，但目前闪电网络的整体容量与粉丝们对它的期望相比还是很不相符的。下面是1ml10月20日的数据。
毕竟跨链到ETH的BTC有17万以上。
基于闪电网络的衍生品交易平台Kollider，10月22日日交易量约1.1BTC。
毕竟闪电网络更适合于微支付，并不太适合于大额交易。
闪电网络对于BTC代表的链下扩容路线有着里程碑的意义，虽然一路艰辛，但在开发者努力，大额融资与社区热望加持之下，闪电网络应该是能掀起一波应用热潮的。
毕竟气氛已经烘托到这里了。
但鉴于其局限，也不应该对其抱有不切实际的期望。
郑重声明： 本文版权归原作者所有， 转载文章仅为传播更多信息之目的， 如作者信息标记有误， 请第一时间联系我们修改或删除， 多谢。