区块链【免费下载链接】lndLightning Network Daemon ⚡️项目地址https://gitcode.com/gh_mirrors/ln/lnd点击查看免费下载Lightning Network DaemonLND使用基于 Sphinx 协议的洋葱路由协议在闪电网络中传递报文并内置了一套名为 Sphinx-Replay-DB又称 Decayed-Log-DB的持久化存储来防御重放攻击。本文以 docs/SphinxReplayDB.md 为主线结合 LND 仓库中的源码与配置系统讲解洋葱路由的隐私属性、重放攻击的危害、sphinxreplay.db/decayedlogdb_kv在不同数据库后端下的存储细节、垃圾回收机制以及重放报文的处理流程帮助开发者理解并运维 LND 的重放防护模块。Sphinx 洋葱路由闪电网络的消息隐私基础闪电网络采用 Sphinx 协议构造多跳消息每个节点在处理并转发一枚洋葱报文时只知道自己的前驱节点报文从哪来与后继节点报文转发到哪去无法获知整条路径的终点与原始发起者。只有报文的创建者发送方掌握完整的路由信息接收方同样无法推断报文源自哪个节点。下面的示意图展示了 Sphinx 洋葱路由在闪电网络中的工作方式以及每一跳所掌握的隐私信息范围Alice (Sender) | | Knows Full Route: Alice → Bob → Carol → David → Eve | v Bob (Hop 1) | | Knows: Alice → Carol | v Carol (Hop 2) | | Knows: Bob → David | v David (Hop 3) | | Knows: Carol → Eve | v Eve (Receiver) | | Knows: From David | v Privacy Properties: - Each hop only knows its immediate neighbors - Receiver doesnt know the original sender - Only sender knows the complete route - Each hop peels one layer of the onion四类隐私属性跳级隐私Hop Privacy每个中间节点仅知道上一跳报文来源与下一跳报文去向看不到完整路由与最终目的地。发送方隐私Sender Privacy只有发送方Alice掌握完整路由、所有中间节点以及最终目的地。接收方隐私Receiver Privacy接收方Eve只知道紧邻的前一跳David无法确定原始发送者。洋葱加密Onion Encryption每一跳剥掉一层加密层仅暴露下一跳所需的信息。这套机制的详细规范定义于 BOLT 04Onion Routing Protocol。值得注意的是LND 中处理 HTLC 洋葱报文的入口在 htlcswitch/hop/iterator.go 的ReconstructHopIterator它对报文执行 Sphinx 解码时会把 HTLC 的支付哈希作为关联数据associated data参与 MAC 校验这正是下面要讲的重放防护的一部分。为什么需要重放防护重放攻击的原理与代价Sphinx 协议明确要求实现方抵御重放攻击。将洋葱报文**重放重新注入**进网络会破坏协议承诺的隐私保证因此每个参与节点都应当拒绝转发重放报文以守护全体网络参与者的隐私。HTLC 与 Onion Message 的本质差异相比原始的 Sphinx 协议闪电网络在转发 HTLC 时拥有更强的重放防护能力这源于 HTLC 与后来引入的 Onion Message洋葱消息的两点关键差异HTLC 将支付与特定洋葱报文绑定转发一枚 HTLC 需要锁定资金重放会带来真金白银的代价HTLC 携带绝对时间锁CLTV报文过期后节点不会再转发天然具备过期即失效的语义可以安全地被垃圾回收HTLC 的 HMAC 提交了支付哈希每一枚 HTLC 洋葱报文在其消息 HMAC确切地说是关联数据中承诺了支付哈希因此攻击者无法把旧的洋葱报文挂到新的支付哈希上。正是这些特性叠加使得重放攻击在闪电网络中代价高昂攻击者不仅要在重放时锁定资金还面临下一跳节点因为已知 HTLC 原像而直接结算该 HTLC 的风险。尽管代价不菲闪电网络实现仍应阻止重放报文在网络中传播以保障每一位参与者的隐私。重放攻击Re-injection Attack的攻击流程攻击者可以采取策略性布点的方式发起重放攻击在网络中精心部署若干连接度良好的恶意节点使其参与大量支付转发。具体步骤为收集报文恶意节点作为转发中介收集流经的洋葱报文同时持续监控网络 gossip观察成功转发当观察到某笔支付成功转发后将捕获的洋葱报文重新注入网络推断路径通过监控邻接节点的通道更新或通道关闭事件判断该通道是否属于支付路径的一部分识别最终接收者如果邻接节点因为缺乏合适的出向通道而直接结算该支付即充当最终接收者那么它大概率就是真正的收款节点。需要注意这种攻击虽然能够破坏路径隐私但其成本相当高昂因此实际执行需要攻击者具备相当的资源投入。LND 的重放防护实现Sphinx-Replay-DB 与 Decayed-Log-DB在 LND 中用于保存洋葱报文信息以防止重放的数据库有两个交替使用的名字Sphinx-Replay-DB与Decayed-Log-DB。二者指代同一套存储前者强调防重放的用途后者强调会衰减过期回收的数据特性。从源码结构看这套存储的命名空间与文件名定义在 lncfg/db.go 中数据库文件名常量DecayedLogDbName sphinxreplay.db命名空间常量NSDecayedLogDB decayedlogdbPostgres / SQLite 中的decayedlogdb_kv表正是由该命名空间生成DatabaseBackends结构体中的DecayedLogDB kvdb.Backend字段见 lncfg/db.go承载着各后端对应的底层句柄。当前 LND 仅实现了与支付绑定的洋葱消息即 HTLC正如上文所述HTLC 具有绝对时间锁过期后节点不会再转发否则将面临资金损失风险因此这些条目可以被安全地垃圾回收。不同数据库后端的存储位置Sphinx 重放防护存储在不同后端下的落盘位置如下后端存储形态说明bbolt默认sphinxreplay.db文件位于通道数据目录下Postgresdecayedlogdb_kv表由decayedlogdb命名空间创建SQLitedecayedlogdb_kv表位于channel.sqlite文件中etcd实验性decayedlogdb命名空间见 lncfg/db.go这些映射关系可以在 lncfg/db.go 的GetBackends中逐一确认bbolt 后端通过kvdb.GetBoltBackend打开sphinxreplay.dblncfg/db.goPostgres 后端以NSDecayedLogDB命名空间打开lncfg/db.goSQLite 后端则把sphinxreplay.db的 KV 表合并进channel.sqlitelncfg/db.go原因是 SQLite 同时只允许一个写者拆分数据库文件可避免钱包库与通道库写入时互相死锁。存储结构共享密钥哈希 CLTVLND 内部维护一个重放防护存储记录每个洋葱报文的共享密钥shared secret哈希与其对应的绝对时间锁CLTV。有了这份记录LND 就能高效识别并丢弃那些携带已见过共享密钥的重放报文。存储的底层实现在 htlcswitch/decayedlog.go 中顶层桶sharedHashBucket []byte(shared-hash)htlcswitch/decayedlog.go键为共享密钥的 sha256 哈希的前 20 字节HashPrefix值为 4 字节大端序的 CLTV默认数据目录为sharedhashesdefaultDbDirectoryhtlcswitch/decayedlog.go。DecayedLog对外暴露的接口包括Put(hash, cltv)写入条目。写入前先查询键是否已存在若存在则直接返回sphinx.ErrReplayedPacket表示这是一个重放包htlcswitch/decayedlog.goGet(hash)按哈希前缀读取 CLTV条目不存在时返回sphinx.ErrLogEntryNotFoundhtlcswitch/decayedlog.goDelete(hash)删除条目htlcswitch/decayedlog.goPutBatch(b)批量写入并返回ReplaySet重放序号集合用于一次处理一批 HTLC 洋葱报文htlcswitch/decayedlog.go。代码末尾的编译期断言var _ sphinx.ReplayLog (*DecayedLog)(nil)htlcswitch/decayedlog.go确保DecayedLog完整实现了 sphinx 库定义的重放日志接口。在 server.go 中可以看到 LND 的实际装配过程// Initialize the sphinx router. replayLog : htlcswitch.NewDecayedLog( dbs.DecayedLogDB, cc.ChainNotifier, ) sphinxRouter : sphinx.NewRouter(nodeKeyECDH, replayLog) // Initialize the onion message sphinx router. This router doesnt need // replay protection. sphinxOnionMsg : sphinx.NewRouter( nodeKeyECDH, sphinx.NewNoOpReplayLog(), )这段代码有两个值得注意的细节HTLC 的 sphinx 路由器挂载了带防重放能力的DecayedLog而洋葱消息Onion Message路由器使用的是NewNoOpReplayLog()空操作重放日志因为洋葱消息不锁定资金、不绑定 CLTV也不需要持久化防重放记录。垃圾回收随区块高度衰减该存储受垃圾回收机制约束不会对内存与磁盘资源造成持续负担一旦条目的 CLTV 过期即可按前述规则将其移除。垃圾回收器实现在 htlcswitch/decayedlog.goStart()启动时通过chainntnfs.ChainNotifier注册区块纪元通知RegisterBlockEpochNtfn并在 goroutine 中运行garbageCollector每收到一个新的区块纪元就调用gcExpiredHashes(height)遍历sharedHashBucket删除所有cltv height的过期条目删除操作被收集成数组后显式执行避免在ForEach回调内直接修改桶结构。对应的单元测试 htlcswitch/decayedlog_test.go 覆盖了TestDecayedLogGarbageCollector验证 CLTV 等于当前区块高度时条目仍保留超过后即被删除TestDecayedLogPersistentGarbageCollector验证 GC 重启后仍能基于持久化数据继续回收TestDecayedLogInsertionAndDeletion、TestDecayedLogStartAndStop验证写入、删除与重启后的持久性。相关配置项db.no-gc-decayed-logLND 提供了可选的衰减日志回收迁移用于节省磁盘空间。配置项定义于 lncfg/db.go; Specify whether the optional migration for garbage collecting the decayed ; sphinx logs should be applied. By default, the decayed log will be garbage ; collected. ; db.no-gc-decayed-logfalse在 sample-lnd.conf 的[db]段中默认值为false即默认执行垃圾回收若设为true则跳过回收迁移通常仅用于排查迁移错误或特殊运维场景。另外相关迁移选项通过 channeldb/options.go 的OptionWithDecayedLogDB与OptionGcDecayedLog注入到 channeldb 的可选迁移配置中。关于该机制的演进可以参见 docs/release-notes/release-notes-0.19.2.md其中提到新增的可选迁移用于垃圾回收sphinxreplay.dbdecayed log以及重放防护被优化为占用更少的磁盘空间使sphinxreplay.db或decayedlogdb_kv表的增长速度大幅放缓。遇到重放报文时会发生什么当 LND 发现一个重放的洋葱 HTLC 报文时它会拒绝该 HTLC但不会发出重放之类的特定错误——因为这类错误会向攻击者泄露该节点确实位于洋葱报文路径中这一事实。LND 选择复用 BOLT 04 中定义的invalid_onion_version错误进行响应。该行为在 htlcswitch/hop/iterator.go 的DecodeHopIterators中实现批量解码后调用tx.Commit()将本次处理得到的共享密钥写入磁盘并返回检测到的重放序号集合ReplaySet。对于命中重放集合且非启动重放reforward的报文代码注释解释得十分清楚// We set FailCode to CodeInvalidOnionVersion even // though the ephemeral key isnt the problem. We need // to set the BADONION bit since were sending back a // malformed packet, but as there isnt a specific // failure code for replays, we reuse one of the // failure codes that has BADONION. resp.FailCode lnwire.CodeInvalidOnionVersion即因为协议中没有专门的重放失败码LND 复用带BADONION位的invalid_onion_version来伪装成报文本身畸形从而隐藏节点在路由中的位置。一个例外通道重建时的 reforward需要注意的是reforward参数当节点在链路重建 / 启动恢复阶段重新处理转发包时此时报文是自身此前已确认过的合法报文而非攻击者注入的重放LND 会跳过衰减日志中的重放检查见 htlcswitch/link.go 中关于 reforwarding 跳过重放检查的注释。这正是既要防重放、又要保证故障恢复之间的平衡点。其他攻击防护HMAC 与 Tagging AttackSphinx 协议还能有效缓解标记攻击tagging attack每一枚洋葱报文都内嵌一个基于报文加密内容派生的 HMAC基于哈希的消息认证码。任何对报文数据的篡改都会使 HMAC 失效从而被诚实节点直接丢弃。这一性质在 LND 的解码链路中同样生效——ReconstructHopIterator在ProcessOnionPacket阶段校验相关 MAC校验失败即返回CodeInvalidOnionHmac见 htlcswitch/hop/iterator.go从根源上保证了报文在到达终点前不会被中间节点做标记而泄露路径信息。总结LND 的 Sphinx 重放防护是一个协议语义 持久化存储 时间衰减三者协同的设计协议层面HTLC 天然绑定支付哈希与 CLTV重放成本高昂存储层面DecayedLog以共享密钥哈希前缀 → CLTV的 KV 结构持久化已见报文bbolt 下体现为sphinxreplay.dbPostgres / SQLite 下体现为decayedlogdb_kv表回收层面借助区块纪元通知过期 CLTV 条目被持续垃圾回收避免存储无限膨胀响应层面重放报文被以invalid_onion_version名义拒绝不泄露任何路径信息。运维者可通过db.no-gc-decayed-log控制衰减日志的回收迁移并依据后端类型定位对应的库文件或表。深入阅读 htlcswitch/decayedlog.go 及其测试 htlcswitch/decayedlog_test.go可以完整还原从收到洋葱报文到写入衰减日志再到按区块高度过期回收的完整生命周期。赞分享区块链【免费下载链接】lndLightning Network Daemon ⚡️项目地址https://gitcode.com/gh_mirrors/ln/lnd点击查看免费下载相关推荐WTF Solidity 合约安全实战签名重放Signature Replay攻击原理、复现与三种防护方案WTF Solidity 合约安全实战签名重放Signature Replay攻击原理、复现与三种防护方案 智能合约的数字签名用于识别数据签名者并验证数据示例工程区块链教程大麦自动抢票脚本实战3条命令搭通Appium链路附完整避坑清单大麦自动抢票脚本实战3条命令搭通Appium链路附完整避坑清单 上个月深圳场开抢那天零点一过我按下提交页面已经变成缺货登记。连续三次卡死在同一个环GUI 自动化RPA终极指南vue-element-admin路由配置全解析——从嵌套路由到面包屑导航实现原理终极指南vue element admin路由配置全解析——从嵌套路由到面包屑导航实现原理 vue element admin是一个基于Vue和Element前端企业应用上一篇Windows系统优化终极指南三分钟让你的电脑焕然一新下一篇CefSharp NuGet包使用指南快速集成到项目创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
