闪电网络
闪电网络（Lightning Network）是建立在比特币之上的双向支付通道网络。参与者把比特币锁定在通道内，随后可在不把每笔支付写入比特币区块链的情况下更新资金分配。通常只有开通、关闭或强制执行通道需要基础层确认。
闪电网络适用于频繁且相对小额、需要较低延迟和手续费的支付。它不会增加比特币基础层的区块容量，而是减少发布每个中间余额的需要，同时引入流动性、可用性、路由及软件风险。
设计
支付通道
双方先用一笔链上注资交易开通通道，随后交换表示当前余额分配的已签名承诺交易。每次有效更新取代旧状态，但无需立即广播至区块链。
例如，Alice与Bob可建立一个通道，初始分配为Alice 0.06 BTC、Bob 0.04 BTC。若Alice向Bob支付0.01 BTC，双方签署各0.05 BTC的新状态。通道保持开放期间，他们可继续更新余额，而无需把每次中间支付分别上链。
协议阻止一方公布过时承诺。在传统惩罚式通道中，若旧状态被使用，另一方可在限定时间内取得通道资金。因此，非托管用户必须监控区块链或委托监控。
路由支付
Alice无需与每个收款人建立直接通道。若Alice与Bob有通道，而Bob至Carol的通道具有足够出向流动性，支付便可经Bob到达Carol。实际路径可包含多个中间节点。
哈希时间锁合约（HTLC）把路径上的转账连接起来。收款人公开加密秘密后各段结算；否则转账按时间锁到期。中间节点不会取得发送者资金的单方面控制权，但可收取转发费。
互操作规则由Basis of Lightning Technology规范（BOLT）定义，涵盖节点消息、通道交易、洋葱路由、网络gossip、发票及功能协商。[1]
流动性与路由
通道只能发送付款方一侧的可用余额，也只能在反方向空余容量内接收。路径每一跳都必须在正确方向具备足够流动性。因此，公开的通道或网络总容量不等于任意用户可发送的金额。
节点可通过收款、开设或调整通道、submarine swap，或向闪电网络服务提供商购买通道流动性来取得入向流动性。部分提供商可以在客户收到第一笔付款时按需开设通道，而无需客户预先购买通道。[2]运营者也可以在自己的通道之间重新平衡资金。这些操作有成本，并可能需要链上交易。
由于精确通道余额不会全网公布且会变化，路由具有概率性。钱包可尝试其他路径或把付款拆分。成功付款可在数秒内完成，但失败尝试、节点不可用或流动性不足会增加延迟。
通道关闭与执行
只要双方合作，通道可长期保持开放。在合作关闭中，双方同意最终余额并广播关闭交易，通常比单方执行更快、更节省费用。
若对方离线或拒绝合作，另一方可公布最新承诺进行强制关闭。时间锁延迟部分输出，关闭会消耗区块空间和链上手续费；这段时间允许对过时状态作出响应。
监控可委托给瞭望塔（watchtower）。瞭望塔监视区块链，发现过时关闭时可代表客户广播惩罚或恢复交易。它不托管客户资金，但其可用性以及钱包正确准备的补救数据仍属于安全模型。[3]
备份也需谨慎：恢复过时的通道数据库不同于恢复普通链上钱包，可能导致资金损失。用户应遵循所用实现的恢复流程。
速度、费用与区块链负载
已有且流动性充足的路径可在无需等待新区块的情况下完成支付，适合销售点及不适合单独作为基础层交易的小额付款。
闪电支付不一定免费。转发节点可收取固定费、比例费或两者；开通及关闭通道还需支付链上手续费。经济优势取决于金额、路径、流动性和当前比特币手续费。
由于多数余额更新留在链下，通常只有注资、关闭及执行交易进入比特币账本。重复使用通道可降低每笔支付的基础层负载，但不会消除对区块空间的需求。
隐私与信任
BOLT洋葱路由只向每个转发节点提供识别上一跳和下一跳所需的信息。相较于公开每笔支付，这提高了隐私，但不保证匿名：通道开关是公开的，时间、金额、网络或端点分析仍可能揭示关系。
双方运行自己的通道时，不会把通道资金的单方面控制权交给路由中介。但信任取决于钱包模式：非托管钱包让用户掌握密钥并承担协议义务；托管钱包隐藏通道管理，却要求用户信任服务商的偿付能力、安全性及提款规则。
实现
独立实现包括Lightning Labs的LND、Elements Project的Core Lightning、ACINQ的Eclair及Lightning Development Kit库。BOLT使它们互操作，但API、存储格式、运行模式和发布周期不同。
Core Lightning原名c-lightning，是自2018年起运行于比特币主网的开源实现。[4] 维护者在2026年披露两个可远程触发、因无限制内存消耗导致的拒绝服务漏洞。connectd问题在26.04版修复，gossipd问题在26.06候选版本系列修复。[5]这些问题影响节点可用性，不会改变闪电网络协议。
另一则2026年8月报道未作为事实收录，因为本草稿准备时没有相符的维护者公开通告、技术披露或修复版本。
局限与故障
- 流动性：即使发送者拥有足够比特币，若没有正确方向容量充足的路径，支付仍会失败。
- 在线可用性：节点正常转发需保持连接；离线收款需要特定支持。
- 通道监控：非托管用户必须发现过时关闭或使用瞭望塔。
- 链上依赖：开通与执行取决于比特币确认和手续费状况。
- 运行复杂度：路由节点需要管理资金、连接、备份、升级和费率。
- 支付可靠性：过时信息、节点离线、金额限制或流动性变化可使路径失败。
因此，闪电网络是补充支付层，而非比特币结算层的替代品。
历史
Joseph Poon和Thaddeus Dryja于2015年发表闪电网络论文。[6]该设计在较早的比特币支付通道基础上，加入使用哈希锁和时间锁的路由双向通道。
c-lightning、Eclair和LND开发者在2017年展示跨实现支付。LND于2018年3月发布首个比特币主网测试版，到2018年6月三个实现均有测试版。[7][8]后续开发改进了路由、多部分支付、瞭望塔、通道管理、移动支持及协议扩展。
参见
外部链接
参考资料
- ↑ Basis of Lightning Technology specifications，闪电网络规范仓库，检索于2026年8月27日。
- ↑ bLIP 52: LSPS2 JIT Channel Negotiation，闪电网络规范仓库，检索于2026年9月3日。
- ↑ Watchtowers，Bitcoin Optech，检索于2026年8月27日。
- ↑ Core Lightning documentation，Elements Project，检索于2026年8月27日。
- ↑ Vulnerability disclosure: twin memory exhaustion DoS vulnerabilities in Core Lightning，Delving Bitcoin，2026年。
- ↑ The Bitcoin Lightning Network: Scalable Off-Chain Instant Payments，Joseph Poon、Thaddeus Dryja，2015年。
- ↑ Announcing our first Lightning mainnet release, lnd 0.4-beta，Lightning Labs，2018年3月15日。
- ↑ Announcing c-lightning 0.6，Blockstream，2018年6月25日。