Notaries in Corda 5: An Overview

By: Ramzi El-Yafi, Staff Software Engineer

Notaries are fundamental to securing the unspent transaction output (UTXO) based ledger that underpins Corda’s representation of tokens on a network. This is the first of a series of blog posts which will discuss how notaries fit into the Corda 5 architecture, and the new features that are going to be delivered as part of the Corda 5.0 release.

The changes to the notary in Corda 5 are more evolution than revolution, providing the same core set of capabilities while ensuring a better separation of responsibilities, and providing a more extensible and scalable solution. In this blog post, we take a step back and ask why we need a notary in the first place.

What is a UTXO based ledger?

An Unspent Transaction Output (UTXO) based ledger can be seen as a database containing rows (states) that can be either “current” (unspent) or “historic” (spent). A state can refer to one or more other states that it supersedes (consumes). In Corda, one or more new rows are created in the database by a transaction, with the new rows being referred to as output states. Any rows that are superseded by the new rows are referred to as input states. A trivial example of this in action would be to imagine a classical audit table in a database, which is append-only in nature, with changes to the state of an entity instance being represented by a new version of the record.

Corda’s UTXO based ledger represents such data as a chain of states. The initial version of the state is created by what is known as an issuance transaction. This is a transaction with no input states, but one or more output states. Subsequent transactions spend the previous version of the state by taking it as an input, and produce a new state as an output. One example of how this could be used in practice would be to capture property ownership:

A representation of a property title deed as a chain of states

In this example, the property must first be registered on the ledger via an issuance transaction. Only a trusted regulator, such as a government land registry department, would be able to do this. In this case, the issuance occurs when Alice buys the property when it is first built. Subsequent transactions then represent property sales to Bob, and later Charlie.

More than a versioned database table

You may rightly ask: why introduce this complexity simply to have a versioned database table? The power of this approach is that whenever a transaction consumes a state it is able to resolve the transaction that originally created the state being consumed and verify that the transaction itself was valid. This can be done recursively so that we can verify all the way back to the first version of the state, known as backchain resolution. Further, states are cryptographically secured such that changing a state in the backchain can be detected by this verification, making the data tamper-evident. This is particularly important in Corda, because unlike public blockchains data in Corda is transferred to parties on a need to know basis; a party running a Corda node may only gain visibility after it has evolved through many versions, and at this point it needs to verify the history back to the initial creation.

Going back to our property example, the initial issuance transaction could be carried out by a trusted party, such as a government land registry department. This is important, as we wouldn’t want just anyone to be able to create property title deeds! This can be checked as part of the transaction verification logic. At this point however, only Alice (and the issuer) know about the title deed for this property.

This approach shows its power when Alice then comes to sell her property to Bob. This now no longer needs the involvement of the trusted issuing party; when Bob receives the transaction proposal, he is able to retrieve the initial version of the state, which he can confirm was signed by the issuing organization. When Bob then comes to sell the property to Charlie, once again Charlie is ultimately able to walk back through the history of the states and satisfy himself that Bob does indeed own the property, and the ownership history can be traced back to the initial state which was approved by a party that Charlie trusts. Bob and Charlie have no visibility of this property’s title deed until they become involved in a transaction relating to the property, but at this point they are able to satisfy themselves that the property’s transaction history is legitimate and has not been tampered with all the way back to the issuance transaction.

This is of course a massive simplification of what Corda does, but demonstrates a relatively simple use-case that can benefit from a UTXO based ledger.

The problem of double spends

A prerequisite for a UTXO based ledger is that a state can only be consumed (be an input to) a transaction at most once; if this were not the case, then a state could split into multiple parallel evolutions, and it would be impossible to determine which of these was the correct evolution. Allowing a state to be spent more than once is known as a double-spend, and is to be avoided at all costs. Going back to our property example, consider the case where Bob decides to sell his property to Charlie and David at the same time, and generates two transaction proposals. Charlie and David both see the current history of the property, and approve the transaction as they confirm Bob is indeed the current owner and the history is valid. If both transactions were accepted, this would mean both Charlie and David would have new states claiming that they are the owners of the property, and there would be no way to identify who was the legitimate owner!

Preventing this from happening in a network of nodes that do not share the same database instance is hard, as we cannot simply rely on database locking to guarantee transaction atomicity and preventing changes to the same data by different transactions in parallel. In Corda, each node has an eventually consistent, partial copy of an overall database.

Bitcoin, which also uses the UTXO model, solves this by using an algorithm called Proof of Work (PoW). Proof of Work however expends large amounts of energy and is unsustainable for the environment as a result. While there are other algorithms out there, they all have their own tradeoffs, and many are untested.

Enter the notary

Corda solves this problem with the concept of a notary. It acts as a single source of truth for which states have been spent, and by which transactions, otherwise known as uniqueness consensus. It can be thought of as a form of Oracle, albeit one with somewhat unusual behavior, in that instead of a client being able to ask “has this state already been spent?”, a client can ask the notary to “please mark this state as spent, if it has not been already”. The implication of this is that any transaction which wishes to spend a state, must make a request to the notary to spend the state before the transaction can be finalized.

Whilst theoretically it may be possible to have a distributed notary service using an algorithm such as Byzantine Fault Tolerance (BFT), providing a highly performant, robust solution whilst also being distributed is hard. And that is to say nothing of the philosophical and legal complexities that may be involved were a distributed notary service run by multiple legal entities to fail. As a result, Corda currently implements a centralized, single party notary solution.

You may ask “doesn’t having an effectively centralized source of truth undermine the entire point of a distributed ledger?”, and this is a perfectly reasonable question.

Corda has a distributed ledger, but is not (fully) decentralized

It is a common misconception that a distributed system must be fully decentralized. Whilst Corda’s ledger is distributed by virtue of the fact that it is distributed across a number of nodes, and no one node necessarily has the full view of all data in the ledger, this does not automatically imply that it is decentralized. Public, permission-less blockchains are often both distributed and decentralized, because by definition, they don’t really care who the participants on the network are, and treat all participants equally. There can often be a philosophical aversion to the idea of centralized parties being able to control or restrict access to the blockchain.

By contrast, Corda is not a solution to this problem; it is a private, permissioned solution which primarily targets highly regulated markets. The parties on the network are well known and verified in advance. Regulated markets will typically have a regulator or other party that has elevated permissions and will need to be consulted when performing some actions on the network. In Corda 5, there’s also a good chance that a network will have a single regulating entity, given that Corda 5 implements application networks instead of a single global network as originally envisaged in Corda 4.

Consider a country wanting to implement a Central Bank Digital Currency (CBDC). It is highly likely that in this use case, the central bank will need to be involved in the issuing of any currency. Therefore, it may be that the central bank would be running the notary service on such a network, since they are in effect the guarantor of the network and have an overwhelming interest in preventing double-spends. The central bank, as the name implies, is effectively a centralized party. That is not to say the central bank must run the notary; it may be that the central bank delegates this technical role to other parties, such as commercial banks. Nevertheless, having a notary run by a single party means that there is a degree of centralization required.

The benefits of a distributed ledger

Another question that may follow from this, is why would we use a distributed ledger at all if we require a centralized notary? Why wouldn’t we just run a classic client / server application with the party that would provide the notary service instead running the server application? The answer is that centralization, or decentralization, is not a binary choice. The client / server model forces you to interact with a centralized party and provide all of your data, all of the time. Corda means that you only need to reveal some of your data, some of the time. Corda is not about providing an ideologically pure solution to abolish centralized institutions; it is focused on providing incremental, and eventually transformative, improvements to the efficiency, scalability, and data privacy of business workflows. Assets may well begin their life with a centralized party, and be delegated out to other parties for some of their lifecycle, potentially returning to source periodically.

In terms of how this applies to the notary, the notary generally runs what we call the non-validating notary protocol. This protocol does not verify the contents of the states themselves, which is considered the responsibility of the participants of a transaction. Instead its role is purely limited to providing uniqueness consensus, i.e. preventing the double-spend scenario we discussed earlier, along with a couple of other checks such as time window validity. This protocol by design reveals very little information about the states of a transaction, and is relatively lightweight in its processing.

What this means is that despite acting as a centralized party, many of the privacy and scaling benefits of a distributed network are retained, because only a small amount of data needs to be transmitted to the notary for each transaction, and it is only involved for a short period of the overall lifetime of the transaction.

In conclusion

Hopefully, this blog post has made it clear why the notary is an essential component in Corda’s UTXO based ledger model. In the next blog post, we will delve into the details of the new notary architecture in Corda 5, and how it provides a more extensible and scalable solution.