Corda, designed for business

Corda is the output of a multi-year collaborative effort of R3 with over 200 technology and industry partners to build a blockchain platform that meets the unique requirements of business applications. It is the outcome of a deep analysis of the requirements for use of blockchain in business and an evaluation of the available technologies. Corda was introduced in a white paper in April 2016 and was released as an open source project in October of 2016. It continues a rapid development cycle which you can read more about in the participate section. You can read the recently updated Corda Introduction White Paper below.

Business Requirements

As discussed in the introduction to blockchain, the first wave of blockchain, which started with Bitcoin, brought technology that allowed parties to transact directly for the first time. This was achieved with three key technologies: a globally shared ledger, a mechanism for reaching consensus on the state of the ledger and immutability of the ledger and transactions. The limited ability to represent complex agreements and assets, however, led to the second wave of blockchain platforms such as Ethereum. These platforms focused on the complex business logic and brought about ‘smart contract' technology. This technology allowed complex business logic to be represented as well as any asset type or agreement.

The second wave of blockchain still left a number of critical requirements unfilled. These flaws prevent the second wave technologies from serious applications in business transactions. Corda was driven by these requirements which form the third wave of blockchain technology. Corda focused on resolving three remaining issues with the blockchain systems:

• Privacy
• Transaction finality
• Legally identified parties
• Ability to scale
• Developer productivity and enterprise integration

Privacy.
Ethereum and other second wave blockchain platforms were designed to run with a single shared ledger among all network participants. This allows any participant to view all transactions, including those of competitors. This is a structural flaw, as the system requires the ability to have a single, shared ledger to operate. This single requirement is sufficient to prevent the broad adoption of blockchain technology as it is unacceptable for competitive, and often for regulatory, reasons.

Finality.
Finality is critical to business transactions. At the time of completion of a transaction, all parties must have an assurance that the transaction is final without ambiguity and cannot be reversed. The mining mechanisms of legacy blockchains lack finality. As a miner propagates a block containing transactions there is a chance another conflicting block has also been created and so you must wait some time to see which block the majority of other miners have chosen to build on. But there is never a point where you have 100% certainty that another chain will emerge as the winner and transactions you thought were confirmed become unconfirmed and potentially replaced with others that conflict – double-spends.

Identifiable Participants.
In business transactions, organizations must have assurance over the identity of counterparties in transactions. These entities may operate in regulated environments. The legacy platforms have no ability to provide assurance over the identity of participants of the network. Additionally, all parties to agreements or transactions must not have the ability to later claim they did not enter the agreement (non-repudiation).

Scale.
To replace existing systems any platform must eventually scale to billions of daily transactions. As an example, there are 2.5 billion transactions daily in global payments. If any blockchain platform is to replace existing business processes it must eventually scale to this level. It must do so in a system that lacks a central coordinator who can operate the system to ensure it remains performant, resilient and available.

Productivity and Integration.
Enterprise organizations have a need to use proven technologies that are supported in their organizations. Technologies such as relational databases, message queues and the Java Virtual Machine (JVM) are components that have been proven in large scale deployments. Integration to the internal systems of the organizations is critical to supporting complex business processes. Corda selected these proven technologies to drive integration, enterprise certification and developer productivity.

Below we discuss how Corda is designed to address these requirements creating the first blockchain capable of business transactions. While Corda is aimed at resolving these final requirements it retains the characteristics of prior generations of blockchain. Specifically, Corda has the main characteristics discussed in the introduction to blockchain including:

• - Assurance that parties involved in the same transaction agree on the facts
• - A mechanism for reaching consensus on the state of the ledger
• - Immutability of the ledger and transactions

The Corda Platform Architecture

Corda addresses the four remaining requirements for use in business transactions with a series of architectural elements:

1. Point-to-point architecture
2. Pluggable consensus
3. A multilateral ledger

Point-to-Point architecture

Corda’s communications are point-to-point, meaning only participants of a transaction can see it. In legacy blockchain systems transactions are propagated among all the nodes that provide assurance over uniqueness. Miners also assure participants of a transactions validity. A transaction’s uniqueness is the assurance that an input to the transaction has not previously been spent (or consumed in UTXO). A transaction’s validity is an assurance that the transaction is executing according to the rules encoded in the contract. For example, in a simple payment between two parties, the miners would provide assurance that the input to the payment was held by the payee and was not yet spent. This is the uniqueness. They would also ensure the inputs equal the outputs preventing the transacting from creating additional outputs. This is the validity.

Corda started with a realization that these are distinct actions that can be separated. The belief a transaction is valid and has unique inputs are separate actions. With all the necessary information shared between parties of a transaction, they could independently arrive at confidence in the validity of the transaction. They would achieve this by executing the contract locally, with all the inputs, and establish the outputs are as they anticipate. This furthers the trust model as the participants each will run their own copy of the commonly shared contract to achieve this. This means they have no reliance on others for assurance over the validity of a transaction.

This left the need for assurance over the inputs status of being unspent (or unconsumed in UTXO). The uniqueness solution still requires a network of distrusting entities coming into consensus over this fact. The group of distrusting entities ensures a globally consistent view of the state of the ledger. Corda calls this uniqueness service the Notary. It operates as a service within a Corda network providing assurance over uniqueness.

Corda’s transaction model implements this point-to-point design at the transaction level. The participants of a smart contract will add inputs to the contract and all necessary information passing this information only between named parties of the transaction. We discuss in the multilateral ledger section how Corda is able to ensure that not only the current transaction is valid but historical ones it depends on are also while retaining privacy.

While Corda limits the transaction to the parties who are participants, there is still the issue of submitting the transaction to a cluster, or pool, of entities operating the uniqueness service, or Notary. This is a potential privacy leak as these entities would have access to the transaction’s private details or even simply the list of participants. Corda resolves this by separating out the data the notary is required to see in order to satisfy the uniqueness aspect of the inputs to the transaction. With the UTXO model used by Corda, all inputs to the transaction are outputs of prior transactions.

Corda builds on the UTXO technology used by Bitcoin but allows it to work with any complex asset type. Each input, which represents an asset or agreement, is uniquely identified by the transaction id from the transaction it is the output of along with the index of the element it represents in the output of the transaction. This information contains no information about the transaction itself yet can uniquely represent the element. When the transaction is submitted to the notary only a set of hashes representing the transaction, including the input identifiers, are passed in. The notary then only needs to ensure that it has not previously seen any of the inputs in prior transactions to ensure the inputs have not yet been spent. This ensures the transaction details remain private from the notary pool operators.

With this design, Corda has no need for routing to intermediaries or global broadcast. Information remains private to the parties to the transactions yet has the same assurance over uniqueness other blockchain systems provide. This represents the most substantial step to a fully private transaction in Corda.

Pluggable Consensus

With the separation of uniqueness into a service, a Corda network gains a number of possibilities. The first is that more than one Notary Pool can operate within a network. With multiple uniqueness services in a single network:

• The network can scale as notary events are partitioned across the network
• Multiple algorithms can be utilized within the same network
• Transactions can be final at a specific point in time without a probability of reversal

The ability to add notary services provides an ability to scale the performance of one of the key system constraints. In legacy blockchain systems the network’s ability to scale is limited to the network’s ability to process each transaction and reach consensus on the state of the shared ledger. This means the network performance continues to degrade as more participants are added. Additionally, other systems limit the entire network to one consensus service which acts as a major constraint. Corda’s decoupling of the consensus from the ledger to the transaction unlocks the potential for a scale that will eventually allow it to perform at levels consistent with today’s business networks.

Separate notary pools also enable many algorithms to be run within a single network. This allows the parties to a transaction to determine the best algorithm for their needs. Many transactions do not require the consensus of a full distrusting set of entities. Such transactions could gain in performance. The ability for Byzantine Fault Tolerant algorithms to operate, however, is still anticipated to be the primary algorithm for uniqueness assurance and is fully supported by Corda.

One of the challenges of the original blockchain platform, Bitcoin, was its lack of atomic transactions. The promise of transaction finality is probabilistic, not absolute. A transaction wasn’t considered final until a certain number of blocks were appended to the history of the block the transaction resided within. This failed to support a key requirement of many business transactions – the need for certainty of the finality of a transaction at the time the parties commit. Corda transactions are final at the moment of consensus by the notary pool.

By removing the need for mining Corda has no cryptocurrency built into the platform and does not require mining-style consensus, which imposes great cost with little business benefit.

Multilateral Ledger

In earlier blockchain platforms all participants had a copy of the full ledger. With Corda's point-to-point architecture participants only have copies of the transactions they are participants to or observers of. This means that every node in a Corda network is likely to have a unique ledger. We call this a multilateral ledger.

In any transaction, however, a recipient of an input must assure itself that the input itself is valid. Like any blockchain system that input has likely been through prior transactions. The receiver must assure themselves no prior transaction has manipulated the states that are inputted to the proposed transaction. Corda achieves this by verifying the full transaction history for every input along when validating an input itself. This allows each party to verify the full transaction history back to the issuance to guarantee validity but without revealing any other unnecessary data. Importantly, Corda only fetches this history data (from a peer node) when required and not before which proves key to Corda’s ability to support multiple applications on the same network and even to merge networks in certain circumstances in the future.

While Corda has constrained the privacy down to the transaction history this history still retains information related to all the prior transactions. This information is necessary to verify the prior contracts conformed to the business logic of the contract. Corda resolves this final layer of privacy with a few further privacy layers. The first is confidential identities ensuring transactions that follow are unable to establish the identity of the parties of prior transactions. Parties to a transaction can use this capability using key randomization with automatic identity management to de/anonymize transactions.

The second method is through full encryption of the prior transaction history. Corda uses Intel Software Guard Extensions (SGX) technology to allow records that can be verified while remaining encrypted to all parties ensuring privacy. Intel SGX is a technology that places an encrypted tamper-resistant memory space into a CPU. This enclave allows trusted execution of code that is unobservable even within the computer’s own execution environment. Transaction history is encrypted in a manner that can only be decrypted and verified in a secure enclave. Even the Corda instance itself or the holder of the transactions history is unable to decrypt the contents. This ensures privacy over all transactions yet allows for full confidence in the validity of an input to a transaction. See this article for more details on how SGX will enable the final element of privacy.

A Complete Business Platform

The unique architecture of Corda captures the key characteristics of the first two waves of blockchain platforms while resolving the remaining requirements that prevent those systems from being used in serious business deployments. Corda uniquely resolves the critical issues of privacy, finality, identifiable participants and scale. It is available for free to download and use today. Get Corda and see for yourself at the link below.

Get Corda