在同一个 Corda 流中创建多个事务有什么风险？

Question

在 Cordapp 中，我想更新第二条链作为正常交易的一部分。由于数据在具有不同参与者的两个独立状态中被跟踪，这将需要在两个事务中完成。

出于讨论的目的，我们有两方 A 和 B。A 与 B 启动交易 1。收到交易 1 后，B 方启动交易 2 以更新另一个状态。我们如何确保两个事务都成功完成？

有两种方法可以解决这个问题：

1. 为事务 2 启动 subFlow 内联流响应器。
2. 使用vaultTrack 响应提交的事务1 并为事务2 启动subFlow。

这是选项 1 的一些示例代码：

class CustomerIssueFlowResponder(val otherPartyFlow: FlowSession) : FlowLogic<SignedTransaction>() {
    @Suspendable
    override fun call(): SignedTransaction {
        val signTransactionFlow = object : SignTransactionFlow(otherPartyFlow) {
            override fun checkTransaction(stx: SignedTransaction) = requireThat {
                val output = stx.tx.outputs.single().data
                "This must be an CustomerState." using (output is CustomerState)
            }
        }
        // signing transaction 1
        val stx = subFlow(signTransactionFlow)
        val customerState = stx.tx.outputs.single().data as CustomerState
        // initiating transaction 2
        subFlow(CustomerIssueOrUpdateFlow(customerState))

        return stx
    }
}

每种方法的优缺点是什么？

我对选项 1 的担忧是单个流中的两个事务不是原子的。两个事务中的一个可能失败而另一个成功，这将使数据处于不一致的状态。例如：上面响应者中的subFlow 可能会成功处理事务 2，但事务 1 可能会因双花问题公证而失败。在这种情况下，第二个链将被不正确地更新。

使用vaultTrack 会更安全，因为事务 1 会成功，但无法保证事务 2 最终会完成。

Answer 1

首先，你说：

由于数据是在两个不同的状态下跟踪的 参与者这需要在两个事务中完成。

这不一定是真的。具有不同参与者的两个独立状态可以是同一事务的一部分。但是，我们假设您有理由将它们分开（例如隐私）。

从 Corda 4 开始，该平台不提供多事务原子性保证。没有内置方法可以确保仅在提交另一个事务时才提交给定事务（但请参阅下面的 P.S.）。

所以你的选择都不能保证多事务的原子性。我仍然相信选项 1 会更可取，因为您得到了流程框架的保证，即事务将被调用。您担心的是，即使第一个事务失败，响应者也会调用创建第二个事务的流程。可以使用waitForLedgerCommit 来避免这种情况，以确保在启动流程以创建第二个事务之前提交事务 1：

class CustomerIssueFlowResponder(val otherPartyFlow: FlowSession) : FlowLogic<SignedTransaction>() {
    @Suspendable
    override fun call(): SignedTransaction {
        val signTransactionFlow = object : SignTransactionFlow(otherPartyFlow) {
            override fun checkTransaction(stx: SignedTransaction) = requireThat {
                val output = stx.tx.outputs.single().data
                "This must be an CustomerState." using (output is CustomerState)
            }
        }
        // signing transaction 1
        val stx = subFlow(signTransactionFlow)
        val customerState = stx.tx.outputs.single().data as CustomerState
        // initiating transaction 2 once transaction 1 is committed
        waitForLedgerCommit(stx.id)
        subFlow(CustomerIssueOrUpdateFlow(customerState))

        return stx
    }
}

附：实现多事务原子性的一种可能方法是使用保留，如下所示：

• 假设我们有两个事务：输出 S1 的 Tx1 和输出 S2 的 Tx2
• 作为 Tx1 的一部分，保留 S1，以便只有在您知道公证人在 Tx2 上的签名时才能使用它，或者在经过一段时间后恢复到其原始状态
• 作为 Tx2 的一部分，保留 S2 以便仅当您知道公证人在 Tx1 上的签名时才能使用它，或者在经过一段时间后恢复到其原始状态

然而，想到的一种攻击是FinalityFlow 的 Tx1 调用者没有在 Tx1 上分发公证人的签名，从而允许他们在不放弃 Tx1 的情况下声明 Tx2。如果公证人将其所有签名发布到某个公告板上，而不是依靠FinalityFlow 的调用者来分发它们，这将得到解决。