Post the Argent Summit (the week of 8th - 12th Aug 2016) it was agreed that we needed a means to communicate between parties privately, to support the sending / receiving of payment ISO-20022 XML messages and also to support FX quoting without the quotes being seen by all parties on the system. Based on these requirements below is a description of how we will evolve the Emerald Distributed Ledger to satisfy them. This new version of the Emerald DL will be v2.
An operation is a method invocation on the system. Associated operations are grouped in to a service.
Services are implemented in one of two ways; they are either a point to point service or a distributed ledger service.
Operations on a distributed ledger service are executed by invoking operations on smart contracts installed in Ethereum.
Operations on a point to point service are executed by invoking JSON-RPC calls over HTTPS to end points hosted by a given party.
Parties register their point to point service endpoints on a Point To Point Service Registry distributed ledger service.
Another party can look up a point to point service endpoint by invoking an operation of the Point To Point Service Registry.
Below we have more detailed descriptions of a number of use cases and diagrams to support the sequence of events that occur.
An instance of Emerald is considered to be the set of smart contracts deployed to Ethereum shared by a set of nodes. Theoretically you could deploy two sets of smart contracts on the same underlying Ethereum network and these can operate independently. We don't expect this to be a normal operational state, however during a system upgrade for example this might be a beneficial situation.
Primary / Secondary nodes
A node runs in one of two modes, either a Primary or a Secondary. There should be only one Primary node for any instance of Emerald. The Primary is responsible for installing all of the contracts if they are not present (i.e. the first time the system is run) and then making the location of them known to any Secondary nodes that connect. A Secondary node is given the location of a ConfigurationService to connect to that provides it an Ethereum enode to connect to and the location of the ContractRegistrar (from which it can bootstrap all other contract addresses and point-to-point service endpoints).
Once a system is up and running a Primary need not necessarily be running as any Secondary node can bootstrap itself off another Secondary node. The only time a Primary needs to be running is when there are no live nodes on a network.
Each bank will have a single Ethereum public / private key pair and associated address. Most operations in the system should be done using a banks address. Bank addresses can be looked up in the BICRegistrar contract, using either a 4-character BIC institution code (what is now known as the Party Prefix in the 2014 version of the spec) or a full 8-character BIC (what is known as a business party identifier in the 2014 version of the spec).
To avoid any issues with fixed / floating point representation and rounding we will use integers to represent all currency amounts - this applies both across distributed ledger services built on Ethereum as well as point to point services. This requires us to have an agreed indivisible amount for any currency we want to represent:
Retrieve an enode, used to connect to the another node on the Ethereum network and the contractRegistrar, used to bootstrap the location of all the other contracts / point-to-point services used by the system.
Set the address for the given contractName. This can only be called from the address that originally installed this contract (All contracts should be installed on startup of a primary node and are then immutable for the lifetime of that instance of Emerald)
getContractAddress(string contractName) : string
Get the address associated with the given contractName. This will return the stored contract address or 0x0, the zero address, if no contract exists for the given name.
Set the endpoints for the given bankAddress and serviceName. For example we might store the endpoints for the FXQuoteService for RBS (where 0x0123456789012345678901234567890123456789 is RBSs bankAddress):
The bankAddress can be looked up in the BICRegistrar contract. The serviceName is a well known service name as documented in this specification. Having multiple endpoints allows for resiliency - the client can expect to connect to any of the endpoints listed and receive the same response back - if an endpoint is unavailable then clients should try others in the list before waiting some period of time and trying again.
Get the endpoints associated with the given bankAddress and serviceName. This will return the stored endpoints as strings or an empty array if no endpoints are stored for the given bank address and contract name.
Create an instance of Emerald (i.e. run a Primary node)
Connect to an existing instance of Emerald (i.e. run a Secondary node)