1
votes

My understanding of Smart Contracts in Corda is that they apply a block of decentralized business logic, that may result in a shared fact in interested parties shared ledgers. However, the Corda examples that I have seen, are setup so that they still allow any of the interested parties (or required transaction signers) to overrule the smart contract logic by applying logic outside of the smart contract (but within the responder flow), before deciding whether to sign a transaction and therefore they can block the transaction result from becoming a shared fact.

This is in contrast to Ethereum smart contracts where a transaction proposer can be sure that if the transaction meets the rules of the smart contract, then the result becomes ‘fact’ in the entire network’s shared ledger.

I’m aware of the privacy trade-off that the Ethereum solution brings, but I think it does provide a more appealing incentive to the transaction proposer, if they know they can rely on the smart contract rules not being overruled.

I’m fairly sure this can achieved in Corda but I haven’t seen any examples of such a scenario. I was thinking this could be achieved simply by proposing a transaction, but do not include any required signers. Simply let a validating notary verify the transaction and let the notary signature be considered sufficient. I’m not sure if the provided CollectSignaturesFlow or FinalityFlow could be used though.

Any thoughts or examples of how to do this would be appreciated.

1

1 Answers

0
votes

That's exactly right. The way to enforce this in Corda is to have your states governed by a contract that doesn't impose any requirements on who signs.

The transaction proposer can then unilaterally update the ledger, provided that their transaction satisfies the contract constraints.