在 Corda 中验证流答案

【问题标题】：Verifying flows in Corda在 Corda 中验证流
【发布时间】：2020-06-08 01:26:10
【问题描述】：

公证人/节点在收到交易时如何验证特定流程是否已被调用？

这是否意味着 Corda 可以保证流程没有根据相应 Cordapp 中的说明进行修改？

【问题讨论】：

标签： corda flow

【解决方案1】：

详细说明：

这是一种 DLT（分布式账本技术）；所以从某种意义上说，你不能真正相信任何人。
公证人不接收流量，它接收交易并确保没有双花（即，已消费的输入不再被消费）。
即使你给了一个节点你的 CorDapp，它也可以覆盖响应者流。请参阅下面的链接。
关于响应者流的错误假设：https://www.corda.net/blog/corda-flow-responder-wrong-assumptions/
配置响应程序流：https://docs.corda.net/flow-overriding.html
覆盖来自外部 CorDapps 的流：https://dzone.com/articles/extending-and-overriding-flows-from-external-corda
当您在发起者与其响应者之间发送和接收数据时；接收到的数据（两端）被认为是不可信的；你必须打开它并验证它：https://docs.corda.net/api-flows.html#receive

简而言之：

您的发起者必须验证从响应者收到的所有数据。
您的响应者必须验证从发起者那里收到的任何数据；另外，如果您希望发起者是某个实体，则必须验证对方（向您发送流会话）是您期望的人（例如 flowSession.counterParty == "O=Good Org, L=伦敦，C=UK")。

【讨论】：

【解决方案2】：

Adel 的回答涵盖了从应用程序流级别不信任您的交易对手的正确方法，但也有可以使用的操作保护。强合约可以帮助防止格式错误的交易，因为 Corda 不允许在设置良好的网络中使用未知合约。

网络参数定义了可以接受哪些智能合约 cordapp jar 进行验证。最常见的合约约束形式是签名约束，这意味着可以接受由相同开发人员密钥签名的任何合约 jar。这可以防止恶意交易对手强迫您运行弱验证：https://docs.corda.net/api-contract-constraints.html#signature-constraints

从 Corda 4 开始，除非节点操作员明确告诉 Corda 信任该 jar，否则任何无法识别的合约 cordapp jar 都不会被信任。 https://docs.corda.net/cordapp-build-systems.html#cordapp-contract-attachments 一旦签名被信任，那么任何未来由该签名签名的 jar 都将被隐式信任。

【讨论】：