Corda 有很多内建的 flows，他们包含了很多核心功能。
FinalityFlow
FinalityFlow 验证给定的 transactions，然后将他们发送给指定的 notary。
如果 notary 同意这个 transaction 是可以接受的话，那么它就会被提交到 ledger 上，并且被写入到钱包中。并且他们还会被分发给在 states 的 participants 中包括的相关节点。
Transactions 在被提交前会被排序，以确保被依赖的内容会先被提交，所以你不需要手动去负责这部分的工作。
这里我们假设 transactions 的一些以来已经被解决了：如果他们的依赖还没有在本地的 storage 中解决的话，验证就会失败。他们必须已经获得了所有需要提供签名的节点的签名，而不是 notary 的签名。
如果指定了的话，额外的接收方也会收到给定的 transactions。
这个 flow 会返回具有同样顺序的相同的 transactions，但是会有额外的签名。
CollectSignaturesFlow
CollectSignaturesFlow 被用来针对一个 transaction 自动地向其他参与者搜集签名。
使用 CollectSignaturesFlow 的时候需要传给它一个 SignedTransaction，它至少要被你自己签过名。这个 flow 会处理对方的身份信息并且会向相关的节点索要签名。
最终，这个 flow 会验证所有的签名并且返回一个包含了所有搜集到的签名的 SignedTransaction。
当使用这个 flow 的时候，在对方的节点中，你需要创建一个 AbstractCollectSignaturesFlowResponder 的子类，并且提供一个你自己的关于 checkTransaction 方法的实现。这个实在提供反馈的节点中添加的额外的校验。你需要检查的方面包括：
- 确保你收到的 transaction 是你所期望收到的 transaction。比如它包含了期望类型的 inputs 和 outputs
- 检查 outputs 的属性是你所期望的
- 检查 transaction 没有不正确地（或者恶意地）消费你的 asset states，因为 transaction 的创造者很有可能访问过你的一些 state reference
通常地，当调用完 CollectSignatureFlow 之后，你会调用 FinalityFlow。
SendTransactionFlow/ReceiveTransactionFlow
SendTransactionFlow 和 ReceiveTransactionFlow 被用来自动地通过验证所有依赖的正确性来验证这个 transaction。当一个 transaction 被收到并验证后，它会被存入到 local storage 所以它就不会被再次验证。
SendTransactionFlow 将 transaction 发送给对方并且在对方验证这个 transaction 的时候监听这个数据请求，通过重载在 SendTransactionFlow 中 verifyDataRequest 方法，可以实现一些额外的校验来限制数据的访问。
ReceiveTransactionFlow 返回一个被校验过的 SignedTransaction。
网友评论