Introduction In many industries significant effort is needed to keep organisation specific databases in sync with each other. In the financial sector the effort of keeping different databases synchronised, reconciling them to ensure they actually are synchronised and resolving the ‘breaks’ that occur when they are not represents a significant fraction of the total work a bank actually does! Why not just use a shared relational database? This would certainly solve a lot of problems using only existing technology, but it would also raise more questions than answers: • Who would run this database? Where would we find a sufficient supply of angels to own it? • In which countries would it be hosted? What would stop that country abusing the mountain of sensitive information it would have? • What if it were hacked? • Can you actually scale a relational database to fit the entire financial system? • What happens if The Financial System™ needs to go down for maintenance? • What kind of nightmarish IT bureaucracy would guard changes to the database schemas? • How would you manage access control? We can imagine many other questions. A decentralised database attempts to answer them.
- A Corda network is made up of nodes running Corda and CorDapps
- The network is permissioned, with access controlled by a doorman
- Communication between nodes is point-to-point, instead of relying on global broadcasts
A Corda network is an authenticated peer-to-peer network of nodes, where each node is a JVM run-time environment hosting Corda services and executing applications known as CorDapps.
All communication between nodes is direct, with TLS-encrypted messages sent over AMQP/1.0. This means that data is shared only on a need-to-know basis; in Corda, there are no global broadcasts.
Each network has a network map service that publishes the IP addresses through which every node on the network can be reached, along with the identity certificates of those nodes and the services they provide.
Corda networks are semi-private. Each network has a doorman service that enforces rules regarding the information that nodes must provide and the know-your-customer processes that they must complete before being admitted to the network.
To join the network, a node must contact the doorman and provide the required information. If the doorman is satisfied, the node will receive a root-authority-signed TLS certificate from the network’s permissioning service. This certificate certifies the node’s identity when communicating with other participants on the network.
We can visualize a network as follows:
Nodes can provide several types of services:
- One or more pluggable notary services. Notaries guarantee the uniqueness, and possibility the validity, of ledger updates. Each notary service may be run on a single node, or across a cluster of nodes.
- Zero or more oracle services. An oracle is a well-known service that signs transactions if they state a fact and that fact is considered to be true.
These components are illustrated in the following diagram:
In this diagram, Corda infrastructure services are those upon which all participants depend, such as the network map and notary services. Corda services may be deployed by participants, third parties or a central network operator (such as R3). The diagram is not intended to imply that only a centralised model is supported.