corda - Corda-设计安全契约(Contract)

Question

最近，我一直在研究Corda中合同命令的安全性和漏洞方面。对于某些合同命令约束是否应该严格或者是否应该放宽以允许不同输入，输出和命令的事务组合引起了争论。

问题是，尽管我看到了允许进行交易组合的好处，但我觉得宽松的合同命令约束实际上构成了安全漏洞，我认为，最好在合同级别上防止这些漏洞，签署该命令的参与者可以通过整体上的合同验证达成共识，而不是依赖于流程级别检查，开发人员可能会忽略这些流程，或者恶意节点可能会绕过它。

示例-破产声明

此示例允许网络上的节点声明破产。在这种情况下，假定破产宣告状态仅仅是宣告破产的节点的身份和原因。

@BelongsToContract(BankruptcyDeclarationContract::class)
data class BankruptcyDeclarationState(
    override val owner: AbstractParty,
    val reason: String    
) : OwnableState { ... }

严格验证

严格的验证要求在发行时...

必须使用零个输入状态。

必须创建一个输出状态。

只有所有者必须签名。

fun verifyIssue(tx: LedgerTransaction, signers: Set<PublicKey>) = requireThat {
    "Zero input states must be consumed." using (tx.inputs.isEmpty())
    "One output state must be created." using (tx.outputs.size == 1)

    val state = tx.outputsOfType<BankruptcyDeclarationState>().single()
    "Only the owner must sign." using (state.owner.owningKey == signers.single())
}

轻松验证

宽松的验证要求在发行时...

必须使用BankruptcyDeclarationState类型的零输入状态。

必须创建BankruptcyDeclarationState类型的一种输出状态。

只有所有者必须签名。

fun verifyIssue(tx: LedgerTransaction, signers: Set<PublicKey>) = requireThat {
    val inputs = tx.inputsOfType<BankruptcyDeclarationState>()
    val outputs = tx.outputsOfType<BankruptcyDeclarationState>()

    "Zero input states of type BankruptcyDeclarationState must be consumed." using 
        (inputs.isEmpty())
    "One output state of type BankruptcyDeclarationState must be created." using 
        (outputs.size == 1)
    "Only the owner must sign." using (outputs.single().owner.owningKey == signers.single())
}

观察

严格的验证可确保全局检查输入和输出，而不是检查特定的输入和输出类型，但是，这样做的缺点是不可能进行输入和输出的事务构成。

宽松的验证确保仅检查所需状态类型的输入和输出，这将允许不同输入和输出类型的事务组合。

这里的关键是只有声明破产的节点才能签名，这意味着BankruptcyDeclarationState的发行只能从该节点进行。 不应允许任何人代表网络上的另一个节点声明破产。

识别漏洞

假设我们选择对合同命令约束进行建模以放宽模型，以便我们进行交易。另外，假设我们有一个用于某些 ObligationState的合同命令，该命令在发出时要求:

必须使用ObligationState类型的零输入状态。

必须创建ObligationState类型的一种输出状态。

债务人和债权人必须签名。

现在我们有了两种状态类型和两种合同命令，我们可以组成一个使用这两种状态的事务，并确定漏洞。此处假设 bob 正在发起此事务。

val transaction = with(TransactionBuilder(notary)) {

    addOutputState(ObligationState(alice, bob), ObligationContract.ID)
    addCommand(ObligationContract.Issue(), aliceKey, bobKey)

    addOutputState(BankruptcyDeclarationState(alice, "..."), BankruptcyDeclarationContract.ID)
    addCommand(BankruptcyDeclarationContract.Issue(), aliceKey)
}

请记住，只有 BankruptcyDeclarationState的所有者必须签名，但是 ObligationState的债务人和债权人必须签名，因此，此启动流程将从所需的对手方收集签名。此处的漏洞是 bob 发起此事务，但包括 alice 拥有的 BankruptcyDeclarationState类型的输出。不应允许他这样做，因为只允许所有者发布 BankruptcyDeclarationState，但在这种情况下，由于需要签署 ObligationState，因此 alice 会不经意间进行签名。

这里有一个论点是，可以以这样的方式来编写流: alice 将在签名之前检查事务，以确保不包括某些状态，但是我觉得这还不够。这要求开发人员和节点管理员对流进行尽职调查以确保其安全性。

相比之下，严格的合同命令约束将以我认为更为安全的方式来防止这些漏洞-因此，仅在合同级别才需要进行尽职调查，而不是每个消耗合同的开发人员都要进行尽职调查。

在这方面，我正在寻找一些确定性的指南，以指导合同命令约束是否应严格，放宽，或者是否有我遗漏的其他注意事项。谢谢。

Answer 1

正如您正确指出的那样，相同的合同代码在所有交易方之间共享。那是他们之间唯一的协议(protocol)。
但是，各方都应通过发展自己的安全流来对其行动(签名)负责。书面流程的基础是在签署之前根据合同代码验证交易。谁会以数字方式或以其他方式签署任何东西而无需阅读/检查合同？
我有想念吗？