R3 CEV Unveils a Distributed Ledger with Pluggable Consensus

by Carlo GutierrezJanuary 30, 2017

Outsourced back in November of last year, R3 CEV looks to push its 'no blockchain' distributed ledger platform into production before the year ends.

Table of Contents

What is Corda?

At a recent Hyperledger meetup, R3 CEV’s Chief Engineer James Carlyle and Lead Platform Engineer Mike Hearn talked about their organizations initiatives specifically Corda, its distributed ledger platform.

James gave a brief intro of R3, summarizing how the company was founded and how it enables collaboration between competitors.

“Collaboration enables competition at higher levels.”
—James Carlyle, R3 CEV

Mike lead the technical rundown of Corda explaining how it is distributed ledger technology with some distinct properties:

There are no blockchains and no mining.
It is designed for permissioned networks.
It is primarily a JVM-based platform implemented in the Kotlin language.
It uses a derivative of the JVM as its smart contract sandbox.
It is open source.

For a more detailed explanation of Corda, please refer to this technical white paper.

What is Corda’s data model?

Corda makes use of bitcoin-inpsired UTXO model where the database does not track accounts or balances.

According to the white paper, the Corda ledger is defined as a set of immutable states, which are created and destroyed by digitally signed transactions. Each transaction points to a set of states that it will consume/destroy, these are called inputs, and contains a set of new states that it will create, these are called outputs.

Although the ledger is shared, it is not always the case that transactions and ledger entries are globally visible. In cases where a set of transactions stays within a small subgroup of users it is possible to keep the relevant data purely within that group. To ensure consistency, Corda relies heavily on secure hashes like SHA-256 to identify things.

Additional features include:

There is no global broadcast at any point.
States can include arbitrary typed data.
Transactions invoke not only input contracts but also the contracts of the outputs.
Contracts refer to a bundle of business logic that may handle various different tasks, beyond transaction verification.
Contracts are Turing-complete and can be written in any ordinary programming language that targets the JVM.
Arbitrarily-precise time-bounds may be specified in transactions (which must be attested to by a notary)
Primary consensus implementations use block-free conflict resolution algorithms.
Transactions are not ordered using a blockchain and by implication Corda does not use miners or proof-of-work. Instead each state points to a notary, which is a service that guarantees it will sign a transaction only if all the input states are un-consumed.

“Transcations in Corda can do lots of different things and not just move money around.” —Mike Hearn, R3 CEV

Corda provides three main tools to achieve global distributed consensus:

Smart contract logic to ensure state transitions are valid according to the pre-agreed rules.
Uniqueness and timestamping services to order transactions temporally and eliminate conflicts.
An orchestration framework which simplifies the process of writing complex multi-step protocols between multiple different parties.

Pluggable consensus algorithms

Corda does not use blockchain but instead makes use of pluggable notaries which are services that provide transaction ordering and timestamping. Notaries are composed of multiple mutually distrusting parties who use a standard consensus algorithm. A notary is responsible for validating transactions. Every state has an appointed notary.

“Computer sciences keep coming up with very nice consensus algorithms with better and better trade offs. We didn’t one to tie the system with a single one.” —Mike Hearn, R3 CEV

Consensus can be divided into two parts:

Consensus over state validity. Parties can reach certainty that a transaction is accepted by the contracts pointed to by the input and output states, and has all the required signatures. This is achieved by parties independently running the same contract code and validation logic.
Consensus over state uniqueness. Parties can reach certainty the output states created in a transaction are the unique successors to the input states consumed by that transaction.

A network can have more than a single notary. Having multiples notaries add the following:

Custom behaviour. A network can have both validating and privacy preserving Notaries. Parties can make a choice based on their specific requirements.
Load balancing. Spreading the transaction load over multiple notaries will allow higher transaction throughput in the platform overall.
Low latency. Latency could be minimized by choosing a notary physically closer the transacting parties.

What’s next?

For the most part, Mike pointed out that last year was dedicated to experimentation and design of Corda. This year, they are looking to towards production so improved security, serialization, scalability, and completed features are big milestones.

Here are a some of the features the Corda team are looking into now:

Using random keys once identity certificate management is complete.
Implementing vault soft-locks.
Starting load testing and eliminating bugs.

Ultimately, the Corda team’s goal for this year is to have API and protocol stability by the end of the third quarter.

Want details? Watch the video!

Table of contents

How is R3 enabling collaboration? (8’30”)
What are the basics of Corda? (12’25”)
What is the transaction structure for Corda? (16’45”)
What is Corda designed for? (19’30”)
How are transactions resolved in Corda? (22’05”)
What is Corda’s network structure? (24’10”)
How does consensus work in Corda? (30’50”)
How are contracts defined in Corda? (32’15”)
What’s the future for Corda? (37’20”)

About the speaker

James Carlyle is Chief Engineer, MD at R3 CEV. James has a detailed knowledge of financial services, gained through the implementation of architecture and design of large and complex projects. His focus has been on application architectures associated with core banking, operations, servicing, channels and integration domains. James has 25 years of in-depth IT experience as a software engineer, data architect, entrepreneur, innovator, and designer.

Mike Hearn is Lead Platform Engineer at R3 CEV. Prior to R3 CEV, Mike was a Senior Software Engineer at Google where he worked for over seven years on Google Maps, Google Earth, and Gmail.