你自己的 Bitcoin 节点。
你自己的 Lightning 通道。端到端免 KYC。

对一个支付路由节点和一个 BTCPay 前端来说，pruned=550（磁盘约 5 GB）完全够用——LND、CLN 和 BTCPay 只需要 UTXO 集合和最近的区块历史就能验证和路由。Pruned 模式将存储需求从约 700 GB 降到个位数 GB，把「IBD 然后保持同步」的工作负载从「数周」降到「数天」。只有当你有需要按高度访问历史区块数据的研究或区块浏览器场景时，才运行完整归档；否则在每一条运维轴上 pruned 都胜出。

LND 部署最广（占公开 Lightning Network 图谱的约 70%），拥有最大的工具生态（Thunderhub、ride-the-lightning、Balance of Satoshis），与 BTCPay 的集成也最为打磨。Core Lightning（CLN）是更保守的代码库，有最干净的插件架构，也是许多「运维者的运维者」出于路由业务原因而选择的实现。Eclair 是 Scala 实现，多见于 ACINQ 钱包背后。对于第一个节点，把 LND 跑在 Garrison 上是阻力最小的路径；如果你想推升路由性能并在意插件可扩展性，那么 CLN 是正确选择。

Tor-only（tor.active=true，不开 clearnet 监听）是隐私至上的默认配置——你的节点只能通过 .onion 访问，没有 IP 泄漏，没有端口扫描留下的痕迹。Clearnet + Tor（双监听）能带来更好的通道发现和更低的路由延迟，代价是把你的节点 IP 暴露给公开图谱。大多数运维者从 Tor-only 起步，因为开放一个 clearnet 端口的运维成本并不小（防火墙、9735 端口、仔细辨识 LN 相关日志），等到真正在意路由费用优化时再升级为双监听。

使用 Static Channel Backups（SCB）——每当通道开启或关闭时，LND 都会写入 channel.backup，这个文件足以恢复链上资金（由对手方一侧强制关闭），但不足以恢复通道本身。每次变化都把 channel.backup 传出本机（用 rclone 推到加密的 Backblaze，或写一个小脚本上传到另一台 VPS）。让人付出聪数的一条铁律：永远不要恢复旧的 channel.db。恢复过期状态会触发对手方的「正义交易」（justice transaction），让你失去通道资金。SCB 才是安全的路径。

Lightning 路由节点的钱包按定义就必然是热钱包——密钥必须实时签署 HTLC 承诺。纪律在于规模：只保留你运营的通道余额所需的部分，把路由节点钱包视为流动资金（而不是储蓄），并按固定节奏把多余的链上余额转出到冷存储。对小规模运维者来说，热钱包里 $500–$2,000 是典型值；对一个正经的路由节点而言，热钱包余额反映的是你承诺投入的通道容量。

在 Garrison 的 4 vCPU / 8 GB / 240 GB NVMe 上，一台 pruned 节点通过 1 Gbps 上行链路约 24 小时完成 IBD——这段时间的大部分是签名验证，属于 CPU 密集型。在 Ravelin（8 vCPU / 16 GB / 480 GB NVMe）上，完整归档节点约 48 小时完成。NVMe 很关键：机械硬盘会让 IBD 变成持续数日的事情，因为 Bitcoin Core 的 UTXO 写入对随机 IO 极其敏感。NordBastion 在每一档都用 NVMe。

BTCPay Server 的 docker-compose 技术栈期望同时拥有 bitcoind + 一个 LN 实现 + nbxplorer + BTCPay Web 层。在 Ravelin 上，你可以为一家小商户（每年几千笔交易）把整套技术栈装在一台机器上；在 Garrison 上，一旦 nbxplorer 索引开始翻动，压力就实实在在了，所以我们建议把 BTCPay 拆到第二台机器——Garrison 跑节点，Sentinel 跑 BTCPay 并通过 WireGuard 反向代理回节点。两条链路都端到端免 KYC。

Bitcoin 的价值主张是无许可结算。一旦你的路由基础设施运行在一家「了解客户」「做过 AML」「持卡留底」的主机上，你就在基础设施层而非协议层重新引入了一个咽喉点。为免 KYC 的支付基础设施提供免 KYC 的主机并不是绝对主义；这是在抹除「这个路由节点由谁运营」这条监管链可以被传唤的那一环。协议是无许可的；主机至少应当对无许可友好。