我们真的需要一个公证人来验证吗？答案

【问题标题】：Do we really need a notary that validates?我们真的需要一个公证人来验证吗？
【发布时间】：2017-11-17 07:27:48
【问题描述】：

冒着听起来幼稚的风险，我问自己“是否需要验证公证人？”，考虑到它的所有问题 - 交易和依赖关系泄漏，状态模型的暴露等等。我听到的答案与不诚实节点试图窃取他人资产的潜在攻击有关。例如，在合法交易中，甲方根据移动合同向乙方出售了一些资产 S。紧接着，甲方创建了一个自签名交易，将 S 转回给他自己，受制于虚假流中的虚拟合约，甚至不运行账本交易 verify()。但是当他调用 FinaltyFlow 来满足简单的公证人在账本上提交交易时，verifyContracts() 将失败，因为 S 指定了 Move 合约，这应该说所有者方 B 必须签署虚假交易。所以这并不能说服我需要一个验证公证人。显然，我一定错过了什么。有人可以启发我吗？

谢谢。

\肖恩

【问题讨论】：

我投票结束这个问题，因为它与计算机、编程、软件或任何与计算相关的技术领域没有任何关系。这个问题更多地与财产的法律手续有关。
嗨 Chetan - 澄清一下……公证人是 Corda 网络中技术组件的名称。这个问题是关于那个，而不是关于公证人的法律概念。

标签： corda

【解决方案1】：

正如您所说，验证公证人的优势在于它可以防止恶意方“楔入”一个状态 - 即创建一个无效交易，消耗他们知道的未消费状态。尽管交易无效，但未验证的公证人不会意识到这一点，并将状态标记为已花费。

您说得对，这个无效事务会使FinalityFlow 对verifyContracts() 的调用失败。但是，我们不能强制恶意节点使用FinalityFlow 向公证人发送内容。例如，如果恶意节点有足够的动机，他们可以手动构建无效的交易哈希并将其直接发送给公证人。

但是，请注意，在非验证公证的情况下，仍然存在多层防止楔入的保护：

恶意方必须知道他们想要楔入的状态。由于 Corda 中的信息仅在需要知道的基础上分发，因此节点只会知道一小部分未消费状态
如果状态被意外楔入，节点可以向公证人显示无效交易。公证人看到交易无效后，将重新标记状态为未消费
由于 Corda 是一个许可网络，公证人可以记录提交交易的每个人的合法身份。如果恶意节点提交无效交易以消耗状态，他们的身份将被知晓，并且可以根据管理参与网络的协议在平台外解决争议

另一方面，新交所解决了与验证公证人相关的数据泄露问题。如果交易验证发生在新交所飞地内，则验证公证人不会获得有关他们正在验证的交易内容的信息。

最终，验证和非验证公证人之间的选择归结为与给定部署相关的威胁模型。如果您在确定参与者不会故意更改其节点代码或恶意行为的环境中使用 Corda，则不需要验证公证人。

但是，如果您认为有人会试图作弊并且愿意编写自己的代码来这样做，那么验证公证人会提供额外的保护。

所以 Corda 提供了选择：

如果您对参与者的信任度相对较低，请选择向公证集群披露更多信息...
如果您认为向公证员透露过多信息的风险是更大的问题，请选择减少向公证员集群透露的风险

（如果您对每个人都偏执，请使用新交所！）

【讨论】：

谢谢，乔尔。我希望在这里发布我的 cmets 作为答案而不是评论，以便您收到通知。 AFAIK，验证公证人需要在公证人节点内安装包含 CorDapp 状态模型的 jar。对于网络中运行的每个自定义 CorDapp，这将如何实现？即使可行，那也是潜在的泄漏吗？我不确定新交所会处理这个问题。
至于允许流直接调用 NotaryFlow 而不是 FinalityFlow，首先，在我的示例中，partyA 将无法拥有 S，因为在账本上没有提交虚假交易——造成的所有损害都是“愚弄”简单的公证人认为 S 已被消费，因此没有人（甚至合法所有者方 B）可以再次消费它。
公证人的重新标记（如您所建议的）会将所有权归还给甲方。那么甲方这样做的动机是什么？只是为了给他带来一些不便，而以降低他的声誉为代价？
其次，允许自定义 CorDapp 绕过 FinalityFlow 调用 NotaryFlow 的用例是什么？如果该平台可以阻止该漏洞，我们是否都会变得更好，这是否会使验证公证人的需求无效？我不反对公证人验证。只是为了实现它，Corda 必须经过所有这些环节：SGX、Raft 和 BFTMaRt 集群中的依赖项复制等。如果一个更简单的解决方案可以提供相同的威胁模型，我们为什么不跳上它呢？再说一次，我可能错过了一些大事。请赐教。
请将这些问题作为单独的问题发布，但我将在这里简要回答。验证公证人需要安装定义状态的 CorDapp。但这不会泄露任何信息。它说明了状态类是如何定义的，但没有说明哪些状态被实例化。如果甲方发现其状态已被无效消费，甲方不会启动取消绑定，乙方会。例如，尽管我们可以将NotaryFlow 设为私有，但无法阻止有动机的攻击者手工向公证人发送消息以消耗给定的状态。我们无法控制他们的消息队列。