Skip to main content

The continual and relentless expansion of the blockchain space over recent years shows no signs of abating despite somewhat of a slowdown in the crazy world of cryptocurrency and proprietary tokens. However, while ICO and token fever will grab all of the headlines, the story beneath the surface resembles a multitude of platforms and communities that are fighting it out to become the ‘one chain to rule them all’. In reality this is unlikely and the more probable outcome is that there will be a multitude of platforms that will co-exist and (must?) interoperate.

Public blockchains allow granular levels of interaction and involvement and most have thriving communities and projects currently underway. However, to risk averse businesses this can present as instability, perceived or real, given the somewhat shifting goalposts of things such as legislation, adoption, forks and general confidence.This instability is discouraging and offers a barrier to entry when looking to leverage the amazing technical advances of blockchain and Distributed Ledger Technology. Step forward Enterprise Blockchains.

Somewhat in contrast to the more ‘pureist’ public blockchains, those offerings aimed at Enterprise are more of a cherry-picked framework that seek to allow business’ to utilise potentially great benefits of DLT while being pragmatic about the risk averse nature of business in general. Arguably the biggest player in this domain is the Hyperledger project, which aims to unify DLT solutions aimed at solving Enterprise problems.

Under the banner of Hyperledger there are some amazing projects that are already being tested in commercial environments and delivering value. The most notable projects are Hyperledger Fabric which is backed by IBM and Hyperledger Sawtooth which is being tried by the likes of Huawei, T-Mobile and Amazon to name a few. Others outside of the group include the JP Morgan backed Quorum which is based on Ethereum. However, the framework I’d like to talk about today is called Corda from R3. R3 are an active member of the Hyperledger group and are focused on leveraging the power of DLT in the finance space.

So what’s Corda? Well, to start off, it’s not really a blockchain in the strictest sense. There is no shared chain of transactions arranged into blocks and shared by all parties that encompases the literal definition. However, it is a form of Distributed Ledger technology that allows transactions between two or more known, but not trusted, entities. One of the common principles running throughout the Corda framework is the idea that it isn’t expected to usurp well entrenched common business components such as Databases, Cloud services and proprietary systems, rather to extend them and ultimately provide interoperability not previously available. It is a pragmatic decision to adopt this stance as businesses tend to be savvy enough not to throw the proverbial baby out with the bathwater in favour of some shiny new technology. Corda is no panacea.


Corda has many different components and features. I will attempt to give a (short) overview of some of the key ones below and then give an example to show them in action.


The basis of Corda is that entities operate a Node which is joined to a semi-private network. There are various types of Nodes that can operate including Notaries and Oracles, but more on those later. Nodes are used to generate contracts, provide ledger functionality and manage data specific to the entity. Corda Nodes use the Java Virtual Machine(JVM) for contract (CorDapps) execution and AMQP for the messaging protocol used during inter-Node communication.


Part of the Node setup is what is known as the Vault. The Vault is a queryable database which contains details about the Nodes state and is used to manage much of the functionality of the Node. Ostensibly the Vault acts as the Nodes own proprietary Ledger as it is comprised of the CorDapps in which the Node is a participant. Unlike public blockchains which rely on a shared ledger containing all data, Cordas focus on privacy dictates only the information that is required is shared and there is no single central store of data. Additionally, the advantage of having the Vault is that is can be implemented using many different industry standard DB technology meaning it is easy to deploy and maintain for current infrastructure teams.


Notaries are an integral part of the Corda framework. The key thing to know about Notaries is that they are responsible for the uniqueness and validity of proposed transactions. In practice, for a transaction to be committed to the ledger, it must be signed by a Notary. The pattern enforces transaction uniqueness as Notaries will reject Transactions containing already consumed States and therefore prevents double spending.


Corda provides a semi-private network which in order to participate in Nodes must join. The Doorman service enforces certain rules that must be adhered to in order to join. For example, it might be that they have to provide certain information, a special code or some other data which the network has deemed required in order to participate. Upon submitting a valid join request the prospective Node is handed back a signed TLS certificate. The certificate is used to provide a public identity for the Node, to secure communications with other Nodes and for some other functions such as generating private identities. Upon joining the network the Network Map Service will publish the IP address on which that Node can be reached.


States are immutable documents that are sent around the Corda network and form the basis of what is actually stored on the ledger. As states are immutable they can only have two values: created (unspent) or consumed(spent). The pattern follows the UTXO model found on other blockchains such as Bitcoin. In effect, States represent on-ledger facts known by one or more Nodes at a specific point in time and can be used to represent any arbitrary data.


Contracts are deterministic pieces of code that ascertain whether or not a given transaction, is valid and permitted. They will take a Transaction as an input and check against pre-agreed rules defining validity. As they are deterministic, Contracts do not have any access to outside data, all data required to do their job is contained within the submitted Transaction. In addition to this, Contracts contain legal prose allowing for the ratification of actions taken during execution of Commands, as legality can be proven. Corda Contracts are written in a JVM language although Corda itself favours Kotlin.


As we highlighted before, States are immutable. However, in the real world, things change and facts become deprecated and need to be updated. In Corda, this is achieved with Transactions. Simply put, a Transaction is a request to generate a new State or States (remember, we can’t change existing ones) or consume an existing State given zero or more inputs. A Transaction is made up of zero or more input and output States but can also include Commands, Attachments and Timestamps. Transactions are built by the proposing Node usually in response to an event and are only executed when they have been classed as valid and signed by the specified Notary. The result of Transactions are zero or more new States; zero in the case of the item being moved “off-ledger” such as a cash settlement paid or one or more new States such as a new debt issuance.


The role of an Oracle is to assert that certain facts outside the network realm are true. If proposing a Transaction that requires such proof, the creator of the Transaction will submit the proposal to the Oracle which will return a signed version of the Transaction containing the resulting fact. Transactions containing Commands requiring Oracle signoff will be rejected if it’s signature is not present when submitting to the Notary.


The Contracts in Corda contain Commands which are used to encapsulate specific functionality. Examples might be things like issuing debt or purchasing a bond. Each Command requires specific signatures when being called in a Transaction. For example, say a borrower makes the final due payment on a loan and submits a Transaction containing a Command to mark the debt as paid; the lending company would be required to sign this Command otherwise the borrower could call this at any time.


Attachments are pieces of referenceable data that can be used by the Contract to assist in the determination of the validity of the proposed transaction. They are effectively zip files that are submitted within the Transaction proposal.


An analogous way to think of Flows is kind of like running threads. Flows effectively automate the process of agreeing Ledger updates. Common Flow tasks such as gaining signatures for a Transaction are already built into Corda and allows for a good level of abstraction over the network I/O and concurrency. In effect, Flows do all of the heavy lifting when looking to keep all Ledgers in sync.


If you put together all of the parts we’ve talked about above, you effectively have what is known as a CorDapp (Corda Distributed Application). CorDapps are basically distributed applications that run on the Corda platform. The objective of a CorDapp is to allow Nodes to reach an agreement on updates to the Ledger. In order to execute a CorDapp, Node owners can make RPC calls to initiate the process or call other functions of the CorDapp.


To show some of the components in action, let’s walk through an example involving some entities:

  • Government House Building Department (GHB) — responsible for building new houses and tendering for a new estate
  • McHouseBuilders Ltd (MB) — a house building company who won the tender to build the estate for GHB
  • Notary — in this example we will assume that the Notary is a reputable entity trusted by both parties. In reality, the Notary would likely be a cluster of Nodes and utilise BFT or another consensus mechanism.
  • Oracle — an independent housing assessment company that is auditable and trusted.

In this scenario, MB are going to enact a contract from GHB to build a new housing estate. We will step through what happens at each stage of our CorDapp to implement this.

1 - Join Network

GHB, MB, Notary and Oracle all join the Corda network by providing the relevant data to the Doorman service. The service issues them all with a signing certificate and they are added to the Nodes list by the Network Map Service.

2  -  Create the contract

GHB creates a CorDapp which sets out the terms of building a new estate. They specify the parameters of the estate such as number of houses, street lighting etc. including the details about the project that require verification in order to class the work as complete.

GHB specifies in the CorDapp the Notary that is required to sign Transaction request and the Oracle that is required to sign the assertion of facts in Transactions requiring them. In addition to this, GHB sets up the Commands within the Contract (Create contract, Build finished, Account paid, Cancel Contract) and which signatures are required in order to execute each Command. For example, to cancel the Contract, signatures from both GHB and MB would be required. The final stage is for GHB to deploy the CorDapp to their Node.

3 - Contract submitted for agreement

When GHB are ready to proceed with the contract, they signal the CorDapp on their Node to begin (by calling the “Create” Command) and a Flow starts.

The begin Command for the CorDapp is a ‘Create-and-ratify’ function and requires both parties to sign so the Transaction is created and sent to MB.

MB’s Node receives the Create Contract Transaction, inspects the terms and then ratifies it by signing it themselves and sending it back to GHB.

Upon receiving the signed Contract proposal, GHB’s Node sends the Transaction, now signed by both parties, to the specified Notary to validate and sign.

The Notary then inspects the Transaction to see that both parties have signed (as per the Command requirements), signs the Transaction and sends the result back to both GHB and MB.

The output State, which has been created from executing the Transaction is then stored on the Ledgers of both GHB and MB.

MB then starts building the estate.

4 -  MB finishes building the houses

Once MB has finished the work specified and agreed to in the Contract it creates a ‘Build Finished’ Transaction.

The Transaction contains the evidence that was required in the original contract. Once the Transaction is created it is then submitted to the Oracle to sign, as per the agreed terms of the Contract.

5 — Oracle verification of facts

The Oracle receives the Transaction from MB containing the Command that the Build work is finished along with the attached evidence. In this scenario, the Oracle is provided by a company that will send someone to the estate to check it over and produce a report on the facts. As this can take hours, days or even weeks, Corda Flow takes care of allowing long running ‘threads’ to take place.

Finally, the investigator for the Oracle reports back to report its findings. These are attached to the Transaction, signed and send back to MB.

6  -  MB Replaces State

Upon receiving the signed Transaction back from the Oracle, MB sends this Build finished Transaction to the Notary complete with signature from the Oracle. As the contract specifies that in order for this Transaction to be valid the signatures of MB, the Oracle and Notary are required only (GHB signature not required for this command) the Notary will sign the Transaction and send the results to all participants, GHB and MB in this case.

In Contract code, when the “Build finished” Command is run, the original State of the contract is consumed and replaced with a new State which is a IOU State showing that GHB owes MB the amount agreed in the Contract. Each of GHB and MBs Ledger will now contain this new State.

Note: now the original State has been consumed to produce a new State, the original can not be used in any subsequent Transactions.

7  -  GHB pays MB

GHB pays MB the amount specified in the Contract into their bank account. They then create a Transaction providing Attachment evidence showing the proof of the money transfer (like a statement) that was agreed in the contract and call the “Account paid” Command.

GHB sign and submit the Transaction to MB to sign accepting that they have received the money transferred. MB sign the transaction and send it back to GHB.

GHB then submits the Transaction containing the Account paid Command with the required signatures and evidence as attachment to the Notary. The Notary validates and signs the Transaction and sends the updates to GHB and MB who in turn update their Ledgers to reflect the change which is to either remove it or replace the State with one showing the Contract is Complete and has consumed the IOU State.

The above scenario is obviously the ‘Happy-Path’ for this situation. Many issues might arise during the life of this CorDapp and Corda has many different tools to help deal with them..

tl;dr — The take-home message from this introduction to Corda is that R3 have developed a blockchain platform that has been built to solve the very real world business issues of record keeping and interoperability with other untrusted parties. By combining legal prose with smart contracts and running it on established enterprise and industry recognised technology they have created a formidable platform for delivering cost saving value to many business’ around the world.

Want to join our team?

Copyright © City Web Consultants Ltd. 2017. All Rights Reserved
Company number: 27234161

Want to start something?

Fantastic! We'd love to hear from you, whethere it's a pitch, an idea or just saying hello!

Feel free to get in touch.


Drop us an email?


Or give us a call?

+44 (0) 191 691 1296


Playing hard to get? We'll contact you