如今，许多人终于开始意识到仅限两个参与者（即闪电网络）的链下通道的缺点和局限性，以及开始探索具有两个以上参与者的通道设计的必要性，以便在这一方向上成功扩展。在长期。 这就需要接受新的权衡，即通过将两个以上的人纳入 UTXO 的共享控制安排来解决闪电网络现有的一些问题，其代价是产生一类全新的问题。
从两方转向多方的最大问题是交互性要求。 如果单个通道中有 10 个人共享一个 UTXO 的控制权，则需要所有 10 方同时在线才能更新该基本通道的状态。 与当前闪电通道的实施相比，这带来了更严重的协调问题，目前闪电通道只需要两个人在线即可使用该通道。
目前，关于这个问题的最佳想法就是通过实质上的联盟来引入信任。 闪电网络（以及未来的多方通道系统）作为一个自我托管系统，因为链上持有资金的多重签名是n-of-n，需要100%的参与者签字才能改变链下资金的状态。 如果您自己作为此类协议的成员拒绝签署新的更新，那么您的资金就不可能以任何方式重新分配。 忽略保持在线并观看区块链以处理旧状态的要求，这种安全模型相当于主链上的单独托管。 如果不改变现状，资金的控制就无法改变。 你的 签名。
将密钥阈值从 n-of-n 降低到 m-of-n 完全破坏了与链上单独托管的安全等效性。 它是有效的托管，因为您不再绝对且不可转让地需要您的密钥来转移您的资金控制权。 ZmnSCPxj（不是 Zman！） 提出了一个有趣的解决方案 到交互问题。
OP_CHECKSEPARATESIG
该提案需要两个软分叉：SIGHASH_ANYPREVOUT 和 OP_CHECKSEPARATESIG。 OP_CHECKSEPARATESIG 的范围是如此之小，如果有任何严重的争议，我会感到惊讶，而且 APO 在生态系统中作为一个理想的改变有相对较大的共识。
OP_CHECKSIG 和 OP_CHECKSIGVERIFY 是目前比特币脚本中验证签名的两种主要方式。 签名有两个部分，S值和r值。 OP_CHECKSIG(VERIFY) 将签名的 r 和 S 作为一个整体参数，将用于验证签名的公钥作为另一个参数，总共两个参数，然后检查签名是否有效。 OP_CHECKSEPARATESIG 将公钥、r 值和 S 值全部作为单独的参数（总共三个），并验证签名。
是的，这就是提案的全部内容。 一个比 CHECKTEMPLATEVERIFY (CTV) 更简单、更简单的软分叉。 为什么需要这个？ 好吧，你现在就会看到这里。
无需所有人在线即可进行状态更新
这就是一个非常基本的多方通道的起始状态。 预签名交易需要 Alice、Bob 和 Charlie 签署 UTXO，他们共享控制权，并为每个成员提供输出。 如果 Alice 想在 Charlie 离线时向 Bob 付款，她唯一的选择就是从通道状态中的输出创建一个预签名交易，将这些资金在她自己和向 Bob 的付款之间分配，如下所示：
这种安排的问题在于，Alice 可以简单地签署一项冲突交易，随时将付款收回给 Bob，并在 Charlie 上线且每个人更新通道之前使用它，并且因为只需要她的密钥来执行此操作，Bob 无能为力阻止她。 我们需要某种仲裁员来确保 Alice 在以这种方式付款时不会因为 Charlie 没有反应而双花 Bob。
您可以添加一个条件，要求精算师 (M) 也是每个人输出的密钥持有者，这意味着他们必须签署以批准从通道状态花费 Alice、Bob 或 Charlie 输出的任何交易。 问题是，现在鲍勃必须信任精算师而不是爱丽丝。 如果精算师与Alice合作，Bob仍然可以被双花。
这就是 OP_CHECKSEPARATESIG 发挥作用的地方。 方法如下：签名中的 r 值源自用于签名的随机数。 随机数处理的主要风险之一是密钥泄露的风险，对于不同的交易重复使用相同的随机数两次将泄露足够的信息，使拥有这两个交易的人能够重新生成所使用的私钥。 这可以用来取代上面的精算师角色并消除对他们的信任。 无论精算师使用什么密钥来担任此角色，他们都可以加载可被没收的保证金。 从这一点开始，我们将他们的密钥添加到每个人的输出中，如上所述，除了在每个脚本中准确指定必须在 M 的签名中提前使用的 r 值。 我们还有一个 CSV 时间锁定路径，只需要所有者的密钥； 这样，如果通道在时间锁定后在链上关闭，用户可以随时按照自己的意愿花费资金。
现在，当爱丽丝去向鲍勃付款而查理离线时，使用预先签名的交易在通道中花费她的输出，她会去找精算师签字。 签名完成并且鲍勃拥有交易副本后，他就可以更加有力地保证这些资金不会被重复使用。 如果精算师与 Alice 合作双花 Bob，他的密钥就会泄露，他投入债券的资金可能会被没收。 如果在这种状态下通道在链上关闭，鲍勃将能够在爱丽丝可以双花他之前确认精算师共同签署的交易，因为爱丽丝必须等待时间锁到期才能双花，鲍勃不会，因为爱丽丝和精算师的支出路径没有时间锁。 如果您还在顶部嵌套较小的通道，则可以将其作为子句添加到多方通道的每个级别。
这为 Alice 和 Bob 提供了一个安全模型，可以在 Charlie 不在线的情况下更新多方通道，虽然严格来说这并不是不可信的，但在不满足该标准的情况下，这已经是最接近的了。 Bob 可以有一个强有力的保证，他不会被双重花费，只要精算师使用的债券价值大于付款价值，这几乎是 100%，而 Alice 甚至可以在对 Bob 足够好的保证下进行这笔付款尽管查理离线。 这可以用于可能非常频繁的情况，即并非每个人都可以继续处理更新，并且每当每个人都在线时就可以干净地切入以更新通道的基本级别并使用此方案删除额外的交易。
OP_CHECKSEPARATESIG 及其在多方渠道中启用的精算师角色解决了一个巨大的问题，实际上使两个以上的人共享一个渠道的概念在规模上可行。 我确信除了多方渠道之外还有很多其他情况，其中强制执行某些方只签署某物的一个版本的保证。 这应该是比特币爱好者非常认真考虑的事情，它通过稍微改变签名验证方式的一个小方面，为已知问题提供了一个不复杂的大解决方案。
