Bitcoin_Optech_170中的多个拟议的LN改进
翻译：DeepL，Google Translate，校对：李林
多个拟议的LN改进：
Anthony Towns 在Lightning-Dev邮件列表中发布了一个详细的建议，并附有一些示例代码，描述了如何减少支付延迟，提高备份弹性，并允许在签名密钥离线时接收LN付款。该提案提供了一些与eltoo相同的好处，除了将在区块高度709,632激活的taproot软分叉，不需要SIGHASH_ANYPREVOUT软分叉或任何其他共识变化。因此，它可以在LN开发人员实施和测试后立即部署。看一下主要的特性。
-
减少支付延迟：处理支付所需的一些细节，但不是具体的支付细节，可以由渠道伙伴提前交换，允许节点只需向渠道伙伴发送支付和支付的签名，就可以启动或路由支付。在关键路径上不需要往返通信，允许付款以接近LN节点之间基础链接的速度在网络上传播。在发生故障的情况下，退还付款的速度会比较慢，但不会比这个变化之前慢。这个功能是开发者ZmnSCPxj之前提出的想法的延伸（见Newsletter #152），他在本周也写了一篇相关的文章，基于他与Towns的一些带外的讨论。
-
改进的备份弹性：目前LN要求信道各方和他们使用的任何瞭望台存储关于信道的每一个先前状态的信息，以防止企图偷窃的发生。Towns的提议对大多数关于通道状态的信息使用确定性推导，并在每个交易中编码一个状态号码，以允许恢复必要的信息（在某些情况下需要一些少量的暴力破解）。这允许一个节点在创建通道时备份所有与密钥有关的信息。任何其他所需的信息应该可以从区块链（在企图盗窃的情况下）或从通道伙伴（在节点丢失自己的数据的情况下）获得。改进的备份弹性：目前LN要求通道双方和他们使用的任何瞭望台存储关于通道的每个先前状态的信息，以防企图盗窃的情况。Towns的提议对大多数关于通道状态的信息使用确定性推导，并在每个交易中编码一个状态号码，以允许恢复必要的信息（在某些情况下需要一些少量的蛮力研磨）。这允许一个节点在创建通道时备份所有与密钥有关的信息。任何其他所需的信息应该可以从区块链（在企图盗窃的情况下）或渠道伙伴（在一个节点丢失自己的数据的情况下）获得。
-
用离线密钥接收付款：在线（热）密钥是LN中发送或路由付款的基本要求，但目前的协议也需要一个在线密钥来接收付款。基于Lloyd Fournier对ZmnSCPxj之前提到的想法的改编（在Newsletter #152中也有涉及），接收节点有可能只需要将其密钥在线，以便打开一个通道，关闭一个通道，或重新平衡其通道。这可以提高商家节点的安全性。
该提案还将提供更知名的隐私和效率的优势，将LN升级为使用taproot和PTLCs。这个想法在邮件列表中得到了很好的讨论，在写这篇文章的时候，讨论还在进行。