摘要：在本文中，100x 集团受资助人 Gleb Naumenko 和 Antoine Riard 探讨了一种不同的缓解通道拥塞的方法。他们建议使用 UTXO 所有权证明（也称为权益证明）来解决通道拥塞问题。此前，这些证明仅在闪电网络通道宣布时使用，以防止恶意行为者宣布非他们控制的频道。可以将其视为作为发送 HTLC 所需的一项 “忠诚保证保险”（作为一种稀缺资源）。他们首先概述了其他解决方案的问题，然后提出了一个简单的，破坏隐私的权益证明。然后，他们研究设计一个保护隐私的版本。最后，他们讨论了复杂的设计决策和悬而未决问题。
其他提案的问题
我们感到不满意的是，预付机制是以新费用（向前和/或向后）计价的，从而提高了任何支付的支付成本。将来预付的基本费用甚至可能会使 “小额支付 ” 因超过其转移的价值而在经济上不可行。因此，一个好的解决方案不应增加支付成本，同时还需要 “燃烧” 稀缺资源（这样一来发动攻击就不是免费的了）。预付的另一个问题是循环信任依赖。理想情况下，我们不应引入任何信任最小化程度不及比闪电网络本身更少的东西。
预付机制不是那样的，因为其在某种程度上依赖于路径参与者的诚实行为。我们相信我们即将介绍的权益证明在这两个方面都是令人满意的：它们不会增加诚实用户的支付成本，也不需要信任。权益证明的主要缺点似乎是需要新颖的加密技术。更多详细信息请参见 “评估” 部分。
通道所有权证明作为路由信用余额
假设 Alice 想通过 Bob 将 HTLC 中继给 Carol。根据权益证明机制，她必须在将 HTLC 发送给 Bob 的同时，通过在洋葱封包中嵌入所有权证明来承诺特定的通道 UTXO。
接着 Bob 解开洋葱封包并验证：
1）通道标识符明确指向链上 UTXO；
2）所有权证明（例如签名）对先前公开的 UTXO 见证脚本有效。
如果所有这些检查都成功，Bob 应该查看 Alice 是否未超过她的信用余额。如果没有，Bob 必须 “减少 Alice 的信用余额”，并将 HTLC 中继给 Carol。
无条件地减少成功或失败数据包的信用余额，约束了恶意 HTLC 发送者的流动性滥用。由于最初没有分配任何信用，因此 “减少信用余额” 意味着仅需记住 “Alice 花掉了她收到的权益证明 Y 个信用中的 X 个”。不幸的是，这种简单的协议是隐私的噩梦，因为路由节点现在可以轻易地将他们转发的每个 HTLC 分配给发送者的 UTXO。
我们先将这里的术语再定义一次，然后再来介绍非简单的，隐私的权益证明。
– 权益证明。要么是指我们提出的解决方案，要么是指它所基于的原始方法，即 UTXO 所有权的证明。正如我们将在后面讨论的那样，使用闪电网络通道 UTXO 所有权证明而不是任何其他资金所有权实际上是有意义的。
– 权益证明值。对应的 UTXO 的数量或该数量可证明属于的大约值。
– 信用余额。当 Alice 向路由节点 Bob 提供权益证明时，Bob 应增加 Alice 的路由信用余额。Alice 的支付就会受到该余额的限制，此规则由路由节点执行，以防止网络中免费的通道拥塞。需要注意的是，理想情况下 “Alice 的信用余额” 应该是虚拟的，且只有 Alice 知道，而路由节点应该只观察每个 UTXO 的信用余额。目前，我们假设每个路由节点都分别跟踪每个 UTXO 信用余额，更多详细信息，请参见 “设计决策”。
– Stake-to-credit 函数定义了给定值的每个权益证明的信用余额是多少。这个函数是路由节点的策略，应予以宣布。
– Credit-to-value-transferred 函数定义了发送方在考虑到可能要求的信用额度下，能够沿着给定的通道转移多少值。该函数还可以考虑不同的因素 (例如，正在使用的通道的可用容量)，以提供额外的稳健性。
隐私保护权益证明
如果该机制依靠 UTXO 所有权的零知识证明，而避免指向特定的 UTXO，就可以保护隐私。
更具体而言，验证者应该能够检查到：
(a) 质押的 UTXO 是当前 UTXO 集的一个元素。
- b) 证明者知道 UTXO 见证程序提交的见证脚本
- c) 证明者知道证人脚本的有效证人
d）质押的 UTXO 未用于生成当前也在使用的其他权益证明。
验证者也应该有方法以查看权益证明值，以正确计算信用。这可以通过将被证明的 UTXO 集限制在仅具有特定范围值的 UTXO 来实现：“我将证明我在 0.5 BTC 和 1 BTC 之间的所有 UTXO 中拥有一个 UTXO”。
遗憾的是，步骤（b）和（c）需要零知识协议的通用语句，这比我们在比特币协议中的大多数东西更具实验性，尽管我们认为考虑其作为非共识内容是可行的。
评估
可以沿着以下维度对权益证明、预付方案和其他潜在的解决方案（给定的特定配置）进行比较。
1）经济可行性
1a) 攻击者突破保护的代价是什么？可能是一个非线性函数：sats_spent =f(channels_to_jam, […])
1b) 这个解决方案如何限制诚实用户？
2）在整合和做好用户体验方面，这个解决方案有多复杂？
3）这个解决方案在协议设计/实施方面有多复杂？
当涉及（1a）时，权益证明和预付款可能是相当的，在某种程度上，它们只是尽力增加攻击成本的想法。遗憾的是，我们目前还不知道如何设计与比特币 PoW 一样经济性强大的东西 [3]。这方面可以通过模拟将这些想法应用于不同假设类型的闪电网络，并考虑不同的攻击策略，观察（1a）与（1b）之间的权衡关系，从而进行正确评估。
在本文的前几节中，我们已经论证过，权益证明可能会以（3）的成本提供更好的（1b），因为它依赖零知识。当涉及（2）时，权益证明的设计可能会因用户体验负担而异，从完全自动到需要用户使用私钥进行自定义操作。下一节将讨论其中的一些权衡以及其他有趣的问题。
设计决策和问题
应该将信用支出分散到整个网络中，还是只让参与支付的路由节点知道？
经济上而言，这两种方法可能是等效的，而只是权益与信用比率的问题。但是，向网络公布信用支出会导致隐私泄漏。它还会为路由节点增加带宽和 CPU 开销。
权益证明应使用哪种零知识系统？
选择零知识系统，归根结底是要在证明和验证时间以及假设方面进行合适的权衡。如前所述，我们会需要证明一般性陈述。同时，我们在证明和验证方面都需要一些便宜的东西，因为闪电网络应该要是很快速的。同时，设置可能无关紧要，因为证明应该只由一个参与者来验证，也就是该证明为此生成的路由节点。也许我们还可以选择任何我们想要的加密假设，因为这个东西不是关键任务，如果有人破坏了加密假设并且我们观察到了攻击，可以很容易地对其进行更新。
我们是否应该允许持有*任意*比特币（而不仅仅是闪电网络通道）作为权益证明？
如果我们担心某些闪电网络用户可能想要发送超出其信用额度承受能力的款项，则此想法可能有意义。但是，我们认为，允许任意 UTXO 会使攻击者有更多机会使用其冷资金进行攻击，甚至出现让持有者出售其证明的二级市场（他们没有什么可损失的）。相反地，我们应该 a）设计更好的 credit-to-stake-functions ； b）鼓励用户跨不同的路由节点发送款项（因为信用不是在全球范围内被追踪）[4]。
最好的 credit-to-value-transferred 函数是什么？
我们认为，此函数不应只是线性的，以提供最大程度的安全性来防止恶意通道拥塞。例如，我们可以对*通道用于路由*的最后 20% 的容量收取更多的信用。另外，在这种情况下，我们也可以通过收取更多信用来阻止在短时间内从同一个 UTXO 进行过多的支付。
那么权益证明的交互性和有效期为何？
交互式证明是指其是根据路由节点的需求构建的，非交互式方法是由付款发送者提前构建的。交互性和有效期都与产生证明和访问密钥的难易程度有关。我们将忽略我们考虑的权衡细节，但这仍然是一个悬而未决的问题。
如果权益证明在生成证明后对 N 个区块有效，是否意味着如果在这 N 个区块内 UTXO 被消费了，则可以用同样的币生成新的证明，而不会使旧证明失效？
没错，但是攻击者首先必须为此支付一笔链上费用。如果我们仍然担心此问题，也有一些变通的方法。例如，我们可以有 100 个区块的 epoch（每个 epoch 都从＃XYZXYZ00 区块开始）。如果在某个 epoch 开始时，某个通道不在UTXO集合中，那么它提供的信用就非常少。或者，我们可以扩展零知识部分以证明币尚未被花费。
花费 UTXO 是否应该透露所有由其产生的权益证明？
这也将解决上一个问题，但是同时意味着追溯性隐私泄漏。为了避免隐私泄漏，我们应该防止这种情况。如果恶意的 Sybil *路由* 节点支付失败导致其他诚实路由节点减少诚实支付发送者的信用怎么办？
权益证明和预付机制都会受到恶意路由节点支付失败并“浪费”发送者的信用或费用的影响。在考虑支付失败率时，这个问题甚至适用于通道拥塞以外的情况。这个问题可以通过减少付款发送方节点上故障链接和路由节点的信誉来解决。当支付路由成为一种营利性活动时，这将鼓励路由节点清理其链接。通过使用[2]中介绍的“可证明的归责”，缓解的力度可以更大。
结论
我们提出了权益证明，一种解决通道拥塞的新方法。也许，由于其复杂性，它可能不是最佳的近期解决方案，但是对于诚实支付而言，零聪开销是未来改用它的一个吸引人的理由。
该提案还说明了基于权益的协议如何解决比特币生态系统中的 Sybil 挑战。由于这在其他情况下可能有用（多种抗 Sybil 所有权证明），因此讨论权益证明更有实益。
下一步是对权益证明的讨论。如果社群觉得它很有趣，那么我们应该讨论上述设计问题，并选择一种加密系统。
Gleb Naumenko 和 Antoine Riard
参考和脚注：
- https://github.com/t-bast/lightning-docs/blob/master/spam-prevention.md
- https://lists.linuxfoundation.org/pipermail/lightning-dev/2015-August/000135.html
- 我们实际上不建议使用 PoW 解决这些问题，因为a）诚实用户成本和攻击者成本之间的权衡是由于专用硬件而导致的，并且b）智能手机如果必须计算 PoW 将会坏得太快；PoW 只是一个基于博弈论一致性，无法企及的系统稳健性的例子。
- 即使我们将可接受的证明限制在闪电网络通道，二级市场仍然是可能的，但供应量会小得多，市场对攻击者的作用也会大打折扣。