LND 每次帮你付款，都要先在脑子里给全网通道打一遍”通过率”分数——这套内部评估机制叫 MissionControl（任务控制）。付款失败一次，相关节点的分数就掉；隔一段时间不失败，分数又慢慢回升。它决定了寻路器优先试哪条路线。普通用户其实不需要理解它，但两种人必须理解：自己跑路由节点的收入经营者，以及付款反复失败想找原因的排障者。
一、失败如何折进概率
源码里的默认参数把机制写得比文档还清楚。惩罚半衰期默认一小时：一个节点或通道因为失败被扣分后，一小时自动”恢复”到一半的可信度，两小时后回到四分之三——历史不会永久记仇。失败后的”二次机会”窗口默认一分钟：如果失败原因是通道策略类错误（例如公告里的费用、限额与实际情况不符），系统先倾向再给它一次机会而不是直接扣分，因为这个信息可能只是图谱数据滞后；但两次二次机会之间至少要隔一分钟，防止某个节点靠连续发新公告把你困在反复试探里。上一跳刚刚成功转发过的节点对，会被赋予约 0.95 的假定成功概率——短程记忆。失败记录最多保留 1000 条，先入先出。还有一个”先验权重”默认 0.5：完全没试过的新节点，评估结果是”通道本身容量模型”与”中性假设”各占一半，避免冷启动时对陌生节点全信或全疑。
把这些数字放在一起，能读出设计哲学：短期惩罚要疼（快速避开坏路），长期惩罚要淡（网络状态永远在变），对新数据保持饥渴（先验权重默认 0.5，一半权重给容量模型）。官方示例配置还提供了概率估计器选项：默认 routerrpc.estimator=apriori，可切到 bimodal——后者把”通道此刻有多少流动性”建成概率分布而不只是成败记录，但配置文件明确标注该估计器仍属实验性质，切换前先确认自己的版本支持并做好回退。
二、运营者与付款方各看什么
付款方看到”路由尝试多次都失败”时，可以先用 QueryMissionControl 把当前这份成对节点概率表导出来看：如果嫌疑节点对的概率被压得很低，而链上又显示其通道明明在线，那多半是惩罚还压在头上——此时可以执行 ResetMissionControl 把评估清零重来，观察下一轮是否成功。这是一把双刃剑：清零意味着同时忘掉所有”确实会失败”的教训，短时间内可能重复撞墙，适合作为排障手段而不是日常操作。
路由经营者则要反过来想：你的节点每一次拒绝转发（容量不足、费用设置不符、频道更新过期）都在别人的 MissionControl 里留下污点，按一小时半衰期消退。频繁触发超时或策略拒绝的节点，会被寻路器长期绕行，收入下滑是滞后指标。对应的防御是保持在线、把 channel_update 的限额和费率与实际容量对齐、避免让 HTLC 槽位耗尽——这些都在其他专题里细讲，这里只需要建立一条因果链：你在别人的概率表里的分数，就是你的未来流水。
三、一个常见误区
MissionControl 只影响”先试哪条路”，不影响资金安全规则：它不会替你选择信任谁，惩罚再高的节点如果真在通道另一侧等着你的 HTLC，超时机制照样执行。把付款失败全归因于”概率被压太低”也不公平——费率设置低于对手的最低要求、发票金额超出通道在途上限这些确定性问题，重置概率表一次都救不回来。先分清”确定性失败”与”概率性绕行”，再决定要不要动这份记忆。
三、冷启动与导入的边界
XImportMissionControl 允许把外部算好的节点对概率导入本地，用途主要是测试与多节点实验环境同步，而不是日常运维——导入覆盖的是本地短期记忆，若来源数据过时，等于用别人的旧地图指挥自己的寻路器。对普通用户更实用的心智模型是：付款失败先换一条路或稍后重试，让半衰期自然工作；连续多天对同一收款方失败再考虑查询概率表。概率表本身是本地数据，不会同步到对端，你的惩罚不影响别人的评估，反之亦然，这层隔离也让整个网络对单点误判更健壮。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。