在AWS实例上使用删减的比特币和c-lightning设置BTCPayServer。我从Bitrefill设置了一个入站通道，一切正常，但我对性能感到失望。
使用凤凰钱包它始终需要16秒的付款得到确认，而另一个BTCPayServer的朋友配置和运行在家里对他的RPi，我没有一个直接的渠道，也不需要8秒。
交易细节说明了一个稍微不同的故事。根据这些，支付我的服务器需要11，4，4和4s，而支付其他服务器需要5s。我认为这是衡量时间后，一些昂贵的握手和路由，但打“支付”和网站和我的手机同时显示“成功”之间的时间要长得多。我能减少时间吗？我是否需要更多的入站频道，以便我的手机找到更快的频道？有什么办法可以加快速度吗？双核是问题所在吗。。。
雷电网
c-闪电
btcpay公司
分享
改进这个问题
跟随
9小时前问的
吉斯莫
26011银牌1111铜牌
添加评论
1个答案
1
lightning所需的计算资源非常少，所以使用的硬件肯定不是问题所在，影响也非常小。
所描述的发送和接收节点之间的时间差是正常的、可预期的并且不能改变。原因是，支付/路由过程通过选择一条路径来工作，在该路径上，htlc被尝试设置为收件人。一旦从接收者的角度建立了所有htlc，钱就到了。然而，从发件人的角度来看，所有HTLC都需要结算。建立一个htlc并在一个通道中解决它需要大约相同的时间。因此，在使用具有足够流动性的路径的情况下，接收者的时间应该是接收者的两倍。
建立和解决htlc主要受加密握手的约束，该握手需要在两个对等方之间通过有线发送5条消息。因此，如果支付路径包含较少的渠道，并且每个希望中的同行在地理位置上都很接近，那么在具有足够流动性的路径上进行支付的锁墙时间将更快。这可能会产生优化的潜力。根据经验法则，您可以假设单个消息为100毫秒，并且由于往返需要10条消息，因此从发送者的角度来看，您可以用每个包含通道的1秒来计算。
上述情况呈现出一条流动性充足的路径。但正如本文所述https://arxiv.org/abs/2103.08576 平衡值是未知的，因此我们有一个随机过程，当前节点试图找到最便宜的路径。本文建议，通过尝试最可能的路径（大致上是那些较短且容量较大的路径），可以显著减少攻击的数量。
总的来说，是的，你在网络中的拓扑位置和选择路径的方法会有所不同，可能会用于性能测试。由于节点尚未实现概率寻径，因此这需要自定义代码。问题甚至可能是在允许重定向的尝试次数和使用地理位置较短的链接之间进行权衡，尽管我会重点选择尽量减少预期尝试次数的路径。
