The Corda paradigm

Corda smart contracts define what you can’t do, not what you can.

The normal programming paradigm is that in a given context you have a set of available functions that take inputs and produce outputs. Other Blockchains, for example Ethereum, use this approach: what you can do with a Solidity smart contract is defined by the methods which are made available to the user of the smart contract.

Corda smart contracts work in a different way. Corda lets the creator of the transaction do what ever they want as long as it conforms to the rules set out in the Contract class. This approach gives massive flexibilty for the CorDapp developer, but that flexibility shouldn’t necessarily be passed on to the user of the Smart Contract as it can increase the risk of misuse.

In the extreme case, if the contract class verify() function is empty the transaction can contain anything. This might be fine depending on what your CorDapp is doing, but, for example, it’s not fine if the security of the CorDapp assumes that your counterparty can’t change the price that they are agreeing to pay for the goods you are shipping them when, because of a lack of adequate constraints, they can.

So if the actions that a smart contract user can take need to be limited, which is most cases, then the smart contract designer needs to have confidence that the constraints in the smart contract adequately box in the user.

The structure provided by CDL aims to help the Smart Contract designer make sure there are no ‘Holes in the Fence’ which unwanted behaviour can slip through.