Corda 验证公证人节点维护UTXO集以加速tx验证是否有意义？

如果我们必须运行ResolveTransactions流来验证每个事务，那么维护UTXO集似乎可以减少计算量：

---

当事务作为流的一部分呈现给节点时，可能需要对其进行检查。检查原始事务有效性是ResolveTransactions流的责任。此流在事务图上执行广度优先搜索，将任何丢失的事务下载到本地存储并验证它们。搜索在没有输入的交易中触底（例如，这些交易大多是由发行交易创建的）。如果事务的任何可传递依赖项无效，则认为该事务无效。

回答我自己，维护UTXO集将加快速度。然而，为了获得最佳性能，它还必须维护一个用过的TXO套件

我是理查德·布朗，R3的首席技术官

这是一个非常好的问题，我们在Corda的早期设计课程中讨论了很多

首先，您100%正确地认为公证人集群的工作（验证或非验证）是维护已用输出的日志。这就是它如何兑现其承诺的方式，即永远不会签署一个试图使用之前已被公证交易使用的状态对象的交易

至于缓存未使用的输出，它不会减少实际计算量——只需移动支付成本的时间，对吗？即当输出被创建而不是被消耗时。但这也会导致隐私的减少：在实际消费之前，未使用输出的存在将以公证的方式透露给公证人

注意：在一般情况下，同一公证人集群将用于系列中的大多数交易。。。所以实际上没有什么需要解决的。公证人集群将已经知道依赖关系，因为它也公证了以前的事务

---

当公证人确实改变时，则为是。。可以想象，有很多事务解析要做。但是，同样，在必须完成该工作时，预先通知新UTXO的公证人只会发生变化。我同意它可以改善某些边缘情况下的延迟，所以我不排除这一点。但是，现在，该系统的工作原理与您所描述的一样：公证人集群只在输出被消耗时才知道输出的存在。即我们尽可能优先考虑隐私

感谢Richard回答我的问题，解释设计选择并确认当前公证人根据用完的TXO套件做出决定。我想我明白你的观点，即最大限度地提高隐私，而且在相同的公证人场景中，如果它要维护一个单独的UTXO集，那么假设整个用完的TXO集可以像整个UTXO集一样缓存，那么它将不会提供性能提升。但是，由于大小的增长率不同，从长远来看（比如10年，1000 tps），我们可能希望缓存整个UTXO集比缓存整个用完的TXO集更易于管理。这是一个很好的长期折衷方案！但我认为您还必须考虑另一个场景：假设我创建了一个事务，它创建了一个新的输出。在您的模型中，它将被添加到UTXO集合中。现在一段时间后，您尝试使用输出。伟大的这将起作用，并且状态将从UTXO集中删除。但是，是什么阻止了您（或我）将原始交易重新提交给公证人，并使输出以UTXO的形式重新出现？我只能通过将UTXO记录为STXO来阻止这种情况。。我们回到了同样的存储需求，不是吗？我看到STXO的存储需求在设计上不是可选的。如果STXO变得太大，可能可以使用额外的UTXO并将其作为第一级缓存（在最快/昂贵的存储上），如果丢失，则将其作为第二级缓存（在更便宜/卷存储上）。