What is the precise problem that smart contract engines in Blockchain platforms like Corda solve? Automated execution, right? With smart contracts your vault stays in sync when other participants in a business arrangement update their records — without you having to check for yourself. If you don’t need to be involved, a smart contract can act as your eyes and ears… it checks everything is OK so you don’t have to. It’s an amazing super-power!

Unfortunately, it doesn’t come for free. Notaries, backchains, transactions, contract code…. There’s a lot of machinery there. And it’s the same for Fabric and all the others. So what if there was a way to avoid all that complexity in situations where you don’t need it? If there are situations where you DO need to check updates for yourself, do you really need to do all this extra work as well? That was the question I’ve been researching recently.

Corda empowers general-purpose workflows through its robust machinery. In the CorDapps built by customers and in-house during the past years, there are certain recurring patterns.

At one end of the spectrum, CorDapps implement workflows that require secure communication over the Flow Framework with or without database persistence. In these scenarios, the developers can define their own schemas but Corda’s Transaction Model is not used at all.

At the other end of the spectrum, Corda can be used to implement Bearer Tokens, which are fungible assets where the issuer and the holder can differ, or Linear States which share a common identifier (linearId) and evolve by superseding themselves. Linear States and Bearer Tokens leverage the full capabilities of the programming model: the Flow Framework, Corda’s Transaction Model and Notaries.

Somewhere in the middle, there is another common type of workflow that deserves further investigation. Many times in Corda, two or more parties wish to participate in the evolution of an agreement and remain in consensus about it. Each and every transaction of this evolution is signed by all interested parties. Let’s see two examples:

The first example shows a ledger of agreements between two banks where Bank1 transfers money to Bank2. The second example shows a food delivery service where customers and restaurants have accounts on Corda nodes. Each transaction corresponds to a customer order.

The immediate observations are that: (1) Past events do not affect the validity (or in Corda terms the verification) process of present events, and (2) The state participants are signing each transaction. So far transactions with these characteristics have been modelled with the Linear States, which employ the full power of Corda’s Programming Model. However, the full power of the Corda’s Programming Model is not needed under all circumstances.

Hypothesis: For workflows modelled with Linear States which require all stakeholders of a state to be transaction signers, the following three actions are not needed:

Backchain Resolution

Contract Code Verification

Transaction Notarisation

States that do not require these actions constitute a new dimension in Corda’s Programming Model referred to as Consensual States hereafter.

Earlier this year following my research on recurring patterns around the use of Linear States, I put together a proposal for the Consensual States — As the Consensual States open up new possibilities, they are on the roadmap for Corda 5.

In a Nutshell…

Contract Code Verification allows parties to consume a state if they can successfully run the verify function of the state’s contract and the verify function of all predecessor states (see BackChain Resolution below). This way the platform allows update powers over a state to be outsourced to parties other than the parties who created the state initially, with the contract code defining the constraints over those powers.

BackChain Resolution performs tracking of provenance. The verify function of all predecessor states must run successfully before consuming a state. The BackChain links a state back to their issuance transaction through the transactions graph. The issuance transaction is an input-less transaction signed off by the initial state participants.

Transaction Notarisation ensures that a state has not been previously consumed. In doing so notaries keep history for input states and prevent the following two situations: Race conditions between legitimate state participants attempting to spent their states, and malicious double-spending of a state.

The picture below shows the evolution of a Linear State in Corda with TX1 being the Issuance Transaction for this state, and TX3 being the most recent transaction.

Simplifying things when state participants are also transaction signers…

Revisiting Contract Code Verification. There is no need to outsource spending powers to other parties. When the state participants do sign off all transactions, these states do not need to have business logic in the form of a Contract associated with them, since the signatures of all affected parties signify their assent to the latest update and, in effect, render anything that has gone before irrelevant.

Revisiting BackChain Resolution. There is no need to track provenance. Having the state participants signing every transaction also obviates the need for BackChain resolution, as the latter links a state (through the transactions graph) back to their issuance and guarantees legitimacy from the current point back to the beginning of the chain, which is an input-less transaction that was signed off by the initial state participants.

Revisiting Transaction Notarisation. Malicious double-spending is not possible, as all state participants are required to sign when a state is spent. Race conditions still need to be dealt with but the notary is not needed for this purpose.

With the Consensual States, there is no need for resolution of long BackChains and no need to deal with the intricacies of Contract Code JARs, while at the same time the load of the notary is reduced along with the inflight transactions at Corda nodes. The Consensual States simplify the design and improve the performance of real-world CorDapps while improving resource utilisation and reducing time to transaction completion.

The Prototype

In the course of this research work, I have put together a prototype with an implementation for the Consensual States.

Here are some highlights: There is an identifier associated with each Consensual States evolution similar to the linear identifiers of Linear States. The business logic which resides in the verify function of the Contract Code for the Linear States is moved to the Responder Flow for transactions with the Consensual States, and checked once and for all when a transaction is signed.

I found it useful to keep a link to the previous state so as to check that the ledger is kept in sync when a new transaction is built. Please note that this link is not used for transaction verification by the Corda machinery, as it happens with the BackChain in the Linear States. Finally, to handle potential race conditions I used soft-locking.

Towards the Future: Interoperability

Communication between nodes that belong to different Corda Networks is a form of interoperability that Richard G. Brown referred to as IntraChain in his article The Five Ingredients of BlockChain Interoperability.

IntraChain communication requires an object that has no attachments to one Corda Network and as a result, it can move to another. The Consensual States are chain-less and notary- free objects which in turn means that they have the potential to flow between otherwise incompatible Corda Zones — something that existing Corda states could not. Thus, the programming model for the Consensual States could provide a powerful framework for interoperable applications.

Take Away Message

Consensual States are light-weight and practical

Consensual States enable scenarios that were not possible before

Consensual States were announced at CordaCon2020

Consensual State are on the roadmap for Corda 5

Sotiria Fytraki is a Software Engineer at R3, an enterprise blockchain software firm working with a global ecosystem of more than 350 participants across multiple industries from both the private and public sectors to develop on Corda — its open-source blockchain platform, and Corda Enterprise — a commercial version of Corda for enterprise usage.

Follow us on Twitter here.