Более безопасные альтернативы стандартной библиотеке C

Во-первых, вы говорите:

Поскольку данные отслеживаются в двух отдельных состояниях с разными участниками, это необходимо будет сделать в двух транзакциях.

Это не обязательно так. Два отдельных состояния с разными участниками могут быть частью одной транзакции. Тем не менее, давайте предположим, что у вас есть причина разделять их здесь (например, конфиденциальность).

Начиная с 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
    }
}

P.S. Один из возможных способов достижения многозаходности - использование обременений следующим образом:

• Представьте, что у нас есть две транзакции: Tx1, которая выводит S1, и Tx2, которая выводит S2
• As часть Tx1, обременяет S1, так что он может быть израсходован только в том случае, если вы знаете подпись нотариуса над Tx2, или возвращается в исходное состояние по истечении некоторого периода времени
• Как часть Tx2, обременять S2, чтобы он мог тратиться только в том случае, если вы знаете подпись нотариуса над Tx1 или возвращается в исходное состояние по истечении некоторого периода времени

Однако одна атака, которая приходит на ум, это вызывающая сторона FinalityFlow для Tx1, но не распространение подписи нотариуса по Tx1, позволяя им требовать Tx2, не отказываясь от Tx1. Это было бы решено, если бы нотариус опубликовал все свои подписи на какой-нибудь доске объявлений вместо того, чтобы полагаться на звонящего из FinalityFlow для их распространения.