R3 Corda中节点故障下的反向链验证

我是科达的新手。我的问题不是关于任何特定的实现，而是一个架构问题

如果涉及的其中一个节点永久性死亡且无法响应，则在后向链验证期间会发生什么情况？如何验证该事务

我已经看到，只讨论了如何降低交易量会减慢验证速度。如果其中一个节点永久失败，验证是否会停止

根据，在视频开始5分钟的示例中，后链是Charlie->Dan->Alice->Bob。在这种情况下，如果Charlie或Dan不可用，则无法验证提议的交易。同一网络研讨会进一步表示，这在以太坊等其他区块链中不是问题

正如Adel Rustum所建议的那样，能够预见对高可用记录保管器需求的应用程序肯定能够在设计阶段适应这样的节点

---

然而，由于广域网的变幻莫测，一个不愿意泄露全球部署的信息的有隐私意识的应用程序可能会遭受许多事务验证失败。想法？

反向链验证不依赖于过去参与事务的节点。只有那些属于当前正在进行的事务的节点才能验证后向链。在验证后向链时，不需要联系（或保持在线）作为涉及问题状态演变的过去事务一部分的其他节点

反向链验证只涉及检查过去在当前事务中用作输入的特定状态上发生的所有事务是否有效。通过再次运行之前交易的合同来检查有效性。没有实际需要与先前交易的各方取得联系

但是，您需要确保当前交易中涉及的各方都处于在线状态并做出响应，因为您需要他们的签名才能成功完成交易

简而言之，事务验证将失败（如果该节点是拥有该事务的唯一节点）；这就是使用DLT（或区块链）的意义所在。如果在genesis之前无法追溯某个数据块的历史，则无法验证该数据块及其祖先是如何创建的

关于你在问题中提到的问题；Corda Enterprise 4.4引入了一种新功能，称为大容量反向链获取，该功能允许修改验证特定事务所需的事务获取方式。以前是深度优先，现在您可以将其更改为广度优先，并指定希望在一次调用中获取多少事务。更多详情请参阅

---

Ashutosh，当事务经过验证且有输入时；生成这些输入（当时作为输出）的事务也需要以递归的方式进行验证，直到我们得到一个完全验证的图（因此称为反向链验证），如果当前节点没有这些事务，它将从参与这些事务的节点请求它们。所以，RT的问题是：如果拥有一个事务（这是后链验证所必需的）的节点之一关闭或删除，会发生什么。我认为你的答案不对。啊！我误解了这个问题。谢谢你纠正我的错误。：）@AdelRustum-节点（B）是否与新节点（C）共享事务，而新节点（C）是否已经拥有整个反向链？（作为解决该交易的一部分）。为什么C必须联系事务中较早涉及的节点（a）。B将拥有完整的链，它可以与C共享。为什么会依赖a？@AmolPednekar好问题，老实说，我不知道交易解决方案的全部细节；当它解析一个事务时，可能会请求以前的事务，但不存储它们；这就是为什么在您的示例中它必须联系节点A。再说一次，你得研究一下。如果您找到了答案，请告诉我：-）那么，在一个长链a->B->C->D中，单点故障的数量与可能会停止验证的祖先数量一样多，这是否合理？根据Corda隐私模型，与其他DLT不同的是，在这种情况下，只有两个节点会意识到任何一个链接，并且任何一个节点的故障都可能有问题，对吗？更正您的陈述：不是“只有两个节点”；这完全取决于谁是您所在州的参与者，可以是任意数量的参与者（这是您在设计阶段决定的）。所有参与者在其事务存储中注册事务，并在其vault中注册生成的状态。所以链条并不总是线性的，它更像一棵树；如果一个事务有3个参与者，那么a可以在它下面有3个分支（a->B1、a->B2、a->B3），这样它就可以从这3个参与者中的任何一个请求该事务。Corda Enterprise还提供了高可用性节点，每个节点都可以在其中进行复制，您可以进行热/冷交换，此外，您还需要定期备份节点的数据库；因此，失败的可能性很小。