一个不需要对手配合的拒绝服务
大多数网络攻击要消耗攻击者资源，闪电网络的通道挤压（channel jamming）偏偏相反：攻击者锁住别人的通道，主要成本只是自己资金的短期占用，甚至可以为零。这也是它被讨论多年却仍未有协议级定论的原因——防御方难以对“合法流量”与“攻击流量”一刀切。
攻击模型：两条路径
Bitcoin Optech 的专题页对两种打法有清晰拆解。流动性挤压（早年称 loop attack）：攻击者拥有金额 x，沿二十跳路径发起一笔付给自己的付款并故意拖延结算，沿途每一跳都要为他冻结 x，一条路径冻结二十份他人资金；攻击结束后付款取消，攻击者资金原路退回，路由费分文不花，因为失败付款本来就不产生费用。HTLC 挤压：利用每条通道约四百八十三笔在途 HTLC 的槽位上限，用低于尘埃线的小额占位，两条自己的通道就能占住沿途上万槽位。两类攻击都只需要网络可达与参数合法，不需要漏洞。
防御清单（按可部署程度排序）
第一层是对端限额。按对等端设定并发 HTLC 数量与超时参数上限，是今天就能做的事：Eclair 曾把接收端 CLTV 超时窗口之外的 HTLC 直接拒收，把“拖二十天”的拖延成本变成攻击失败；CircuitBreaker 一类旁挂工具给 LND 节点按通道设定在途 HTLC 天花板，超出即拒绝转发，迫使攻击者用更多真实通道和链上费用才能达到同样效果。第二层是参数纪律：给自己的通道设置合理的 min-htlc 与最大超时预算，把尘埃线抬到值得攻击的高度。第三层是流动性分散：不把路由集中给单一大对端，单点被冻时仍有绕行路径。协议层的前沿方案——前置费、双向费率、fidelity bonds 信用抵押、以及 2026 年出现的条件消息传输合约（给“扣留”本身按时间定价）——截至本文写作时均未成为全网部署的强制标准，任何声称“已彻底解决挤压”的产品文案都值得警惕。
识别信号与处置顺序
如果你的节点出现大量槽位占满、对端 HTLC 长期悬挂，处置顺序是：确认在途 HTLC 数量与超时分布，识别可疑对端；按对端设置限额或暂时断开；记录通道与时间窗口，供后续信誉策略使用；恢复观察正常流量。对普通用户，挤压通常是环境噪声而非你的故障——付款绕行即可，不需要“修复”什么。 为什么防御只能做在节点侧？协议设计者一直不愿强制收费，因为洋葱路由的本意是让每一跳只认识相邻两跳，任何要求“证明这笔付款诚实”的机制都天然与隐私目标冲突：要么暴露路径信息，要么引入可集中发放的信用凭证。这也是各方案多年难产的真正原因——技术上都可行，代价都要从隐私账本里支取。
常见误区
“攻击者要付出与破坏相称的成本”——协议当前恰恰不收取失败路由费，这是成本不对称的根源。“关掉公开路由就没风险”——受害者多为依赖入站通道的服务，风险画像不同而非消失。“协议马上出补丁”——多年历史表明，这一问题的方案讨论远快于部署共识，防御应以节点配置为主。“付款失败一定说明有人被攻击”——绝大多数失败只是流动性不足或路由探测的正常噪声，把每次失败都归因于攻击反而会让运维动作变形。
风险提示
本文只提供防御与处置视角，不涉及任何攻击实施细节，亦不构成收益预期。闪电实现参数随版本变化，以对应软件文档为准。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。