链上动态也将 HTLC 的价值考虑在内。如果一个 HTLC 只转发 10 个比特币，但添加 HTLC 输出将花费 100 个比特币的链上费用，如果有必要，你真的能在链上强制执行吗？答案是否定的。因为在链上执行它实际上会损失你的钱，没有经济动机去执行它，而且在高收费的环境中，确实没有一个合理的点来首先创建 HTLC。从长期来看，费用很可能会持续上涨，因此这将影响 HTLC 通过闪电网络合理路由的价值。

这个问题确实存在一个解决方案，但它有自己的权衡和缺点：即打包支付。这个想法不是一次性使用一连串 HTLC 路由支付，而是将其分解为多个不使用 HTLC 的单独支付。这使你可以一遍又一遍地将一小部分付款推送给预期的接收者，直到完成为止。但是因为没有 HTLC，你的任何小额付款数据包都可能被完全扯掉。如果有任何一条支付失败，你可以停止使用当前的路线并寻找另一条路。问题是，如果部分支付失败，你不知道路由链上应该找谁负责。因此，你必须从头开始重建一条新路线，不要信任先前路线中的任何人。

支付延迟

每次闪电支付通过网络传输时，所有涉及的节点都必须签署从路由开始到结束的其通道的更新两次。一旦使用 HTLC 设置支付，并再次当 HTLC 被清除和结算。这就引入了一种「最弱环节」的动态，即支付实际清除的速度。如果你是闪电的频繁用户，你可能会注意到这一点；有时钱包需要几秒钟（或者差的情况下需要几秒钟）才能真正通过并更新余额。我唯一熟悉的高清钱包（light wallet）是 Breez，根据我的经验，它可能需要 5-20 秒的时间，在点击发送后才能真正完成。

目前，这只不过是一个轻微的用户体验小问题，与不得不尴尬地站在收银机前等待信用卡购买获得授权没有什么不同。但是回想一下上面提到的分组支付的建议，以解决金额太小而无法使用 HTLC 的问题。作为一个非常小的、不断增长的网络，使用 HTLC 推动非小额支付金额，这种延迟是一个明显的问题。现在想象一下，如果不是单个 HTLC 的两轮签名，而是有数百轮签名来将相同的支付分成单个微支付大小的金额。

就用户体验而言，这是一个更大的问题，同时也是路由节点的扩展瓶颈。加密签名操作非常快速和便宜，但在一个同时构建闪电以促进各种小额支付和流支付用例以及更传统的大额支付的世界中，也必须分解成小额支付大小的比特币，这也成为路由节点的一大瓶颈。从长远来看，这种动态很可能会扼杀在廉价硬件（例如 Raspberry Pi 或其它单板计算机）上运行有利可图（甚至足够可靠以被广泛使用）的路由节点的想法。

通道数量的可行性

HTLC 并不是闪电网络中受到链上费用的波动或稳定上升的严重影响的唯一东西。闪电通道本身也成为了这种动态的受害者。假设你想打开一个容量为 10 美元的 BTC 的闪电通道，但这笔交易的连锁费用将为 1 美元。该通道一开始就要收取 10% 的费用。然而，如果你资助一个通道为 100 美元，你的实际收费只有 1%。这为试图直接与闪电网络互动的人们创造了一个非常真实的市场层。如果开通一个通道的有效收费过高，他们就不会开通该通道了。 (责任编辑：admin)