In my previous blog post, I wrote a bit about the importance of ledger interoperability and the concept of multi-phased commit in distributed ledger transactions. The long and short of that post is this: We will have assets on different ledger instances and implementations, and we need to be able to coordinate Ledger vs Ledger atomic swaps vis a vis Interledger Protocol or similar.

You might be asking — why would we have a need to have multiple ledgers or distributed data stores in the first place? Why would there need to be multiple platforms? It all boils down to determining the runtime characteristics required of the asset class modeled on-ledger against the capabilities that each ledger platform has.

Let’s take a very common asset class and see what its runtime characteristics are: Cash. Cash is also the primary asset class being modeled on the first Blockchain implementation out in the wild: Bitcoin, so it serves as a good first example.

So, what do I mean by “runtime characteristics of an asset class?” Each asset class we may model on a distributed ledger will have different usage scenarios, legacy systems touch points, primary usage actors, and double-spend risk factors (one of the primary problems solved using Blockchain-inspired distributed ledgers). Let’s see how Cash fits into each of these categories.

Cash is King

Let’s make some assumptions, first. Anyone involved in banking today knows that the answer to the question “what is cash?” is not completely obvious. Assuming we’re talking about fiat-currency issued by a sovereign central bank (such as the Federal Reserve System for the USD, Central Bank of Canada for CAD, European Central Bank for the EUR, and so-on), then one form of “cash” is the issuance of a Central Bank Note of appropriate denomination in exchange for extremely liquid sovereign debt instruments (such as the USA T-Bonds or the Eurozone Short-Term Repo Contract). This issuance of currency can also be called “Central Bank Money,” or “M0” money, as it is directly issued by the Central Bank and constitutes the base monetary supply in the form of an electronic book entry held in the central bank, or the physical paper bills printed and issued by the appropriate authority. Other forms of cash, commonly referred to as “Commercial Bank Money,” is created by Commercial Banks vis a vis the loan origination process. In fractional-reserve banking, Commercial Banks are licensed to “create money” by originating loans, creating an asset (the loan itself) and it’s corresponding liability entry representing the money created by that loan. Banks can create this money up to a certain limit — details of this process can be found on the internet in a gazillion places. (tip: steer clear of the conspiracy nuts). M2/M3 make up the aggregation of M0 + commercial bank money supply in demand deposit accounts.

For this example, let’s keep this simple — let’s assume the money on-ledger should represent Central Bank Money (M0).

Who holds Central Bank Money today? Well, we all do. Generally speaking the bills you hold in your wallet or hand is central bank money. We all use it today. And we need to use those bills to easily exchange with anyone.

We have a functional decision to make here — should we create a global, anyone-can-use distributed ledger, representing how much M0 and/or M2/3 cash any individual is holding? A ledger that records EVERYONE’s cash activity? Or do we want to restrict central bank money trading to the Commercial Banks? The ramifications of this decision are high:

Option 1: Global Cash Ledger for All

If we decided that we wanted to represent the whole of M2/3 on-ledger, and the ledger tracks who is holding a certain amount of money, then we would need to keep the following under consideration:

Potential for billions of nodes, all of which could be a source of value transfer

The asset class (Cash) can be represented purely as a numeric value

The ledger tracks how much each “address” or “entity” on the network holds in cash

Transfers of value can be high- or low-valued

Network must support billion or trillions of value-transfer transactions per week

For scalability reasons, it’s assumed that nodes cannot rely on a central notary service, given the immense volume of transactions expected for a basic, fundamental asset class

Given these runtime characteristics, a public cash ledger system would be appropriately modeled similarly to Bitcoin:

A Proof of Work or Proof of Stake consensus algorithm would probably be appropriate, since other consensus algorithms such as Raft still rely on a “leader” to be a source of truth on consensus — a “leader” node in a network of billions of nodes would simply be overwhelming. PoW and PoS algorithms allow each node to come to consensus on their own, with the first node to solve a problem the one to also advertise the transaction order and ledger state. Ethereum and Bitcoin are 2 good examples of appropriate platforms. Consensus can come about in 75 seconds (on ethereum assuming 6 blocks to confirm) to around 10 minutes on Bitcoin.

Each node must be able to verify that an actor is not trying to transfer funds twice (the “Double Spend Problem”). Some of the best state-machine approaches is the unspent-transaction-output design, commonly referred to as UTXO. Roughly, it means that each immutable state is independent of any other state, and each state is consumed entirely during a state transition (a “transaction”) and brand new states are output as a result of that transaction. For example, in Bitcoin you must consume 1 transactions’ entire output (say, an output of 5 BTC assigned to you) in order to spend part of that output, and the output is a brand new state with the previous state considered “spent” (say, and output of 1 BTC assigned to the payee, and 4 BTC assigned back to you as “change”)

Due to the sheer number of nodes on the network, authenticating individual nodes will be impossible. Again, this is a good reason to choose a POW or POS consensus algorithm.

Example ledger platforms appropriate for this asset class could be Bitcoin itself, Ethereum, Stellar, or other proof-of-work implementations.

Let’s contrast that with a different approach to Cash.

Scenario 2: M0 — The Banking Token of Choice

If we decided instead to focus on Central Bank Money (M0), and use that as the mechanism for Bank-to-Bank transactions, how would the runtime characteristics change?

Let’s think about the customer experience of sending money for a moment. It roughly works like this:

Bank A has a Client 1, who needs to pay a bill to Client 2 who banks at Bank B.

Client 1 logs into their Bank A website, sets up a transfer to Client 2 at Bank B

Bank A and Bank B exchange a bunch of messages with each other over a financial intermediary such as ACH, Fedwire, SWIFT, TARGET2, or CHIPS letting the institutions know that Bank A wants to send Bank B money on behalf of Bank B’s client 2.

Bank B credits Client 2’s account. BEFORE BANK B GETS THE MONEY. Bank A now “owes” Bank B money.

The two institutions send separate messages to their Central Bank asking for a book entry transferring money held on reserve by Bank A to Bank B — or, if Bank A does not have enough reserves, Bank A “borrows” from the interbank money market.

Both institutions spend a lot of time reconciling their internal ledgers with the messages sent to/from the intermediaries.

A distributed ledger can have an immediate, positive impact on the efficiency of this system by removing the need for long-response asynchronous messaging as part of transfer operations and instead allow banks to participate on a “Central Bank” distributed ledger. In a bank-only network, the considerations for the Cash asset class change:

Potential for thousands of nodes, most of which would be a source of value transfer

The asset class (Central Bank Cash) is still represented as a purely numeric value

The ledger tracks how much each “address” or “bank” on the network holds in central bank cash

Transfers of value can be high- or low-valued

Network must support billion of value-transfer transactions per week

There is implied trust between banking institutions — trust that banks themselves would not try to game or cheat a global central bank cash system. Therefore, it could be acceptable that the nodes may rely on a central notary (a Central Bank, perhaps?) service in order to accept a transaction as valid on the network

Given this very different set of runtime characteristics, we have very different needs from our ledger platform:

The consensus algorithm must be able to authenticate transactions from institutions transferring value between each other, and enforce a no double-spend requirement and possibly other KYC and AML-style operations. Raft or similar “leader” protocols could be appropriate as it scales well and can allow for confirmation/consensus in a matter of seconds. This is only possible because the only nodes on the network will be “Bank Nodes” measured in the thousands, and not millions/billions.

The leader node, or notary, validates and confirms transactions do not inappropriate modify the ledger (i.e. double-spend, or try to spend something you cannot prove you own).

Authentication of nodes on the network would probably be mandatory or optional, depending on the data hiding requirements and the implementation of data-hiding in the ledger platforms. It might be acceptable to allow “observer nodes” that are not authenticated to the network and therefore cannot issue transactions, but can see the flow of transaction on the network. This could be useful for regulators.

Example ledger platforms appropriate to these characteristics could be Private/Enterprise Ethereum, Hyperledger Fabric, and R3 Corda

This is what I mean by accounting for the “runtime characteristics” of an asset class on-ledger. It generally depends on how it will be used and how important it is for the nodes to come to consensus quickly.

So- why multiple ledgers?

You generally use cash to buy something — you swap cash in exchange for some other asset. For this example, let’s say it’s another financial instrument — a corporate bond.

The corporate bond’s runtime characteristics are a bit different:

Potential for hundreds (or possibly thousands) of nodes, representing Brokers or major dealers of bonds.

The asset class (Corporate Bond) is represented by a unique alphanumeric identifier (the CUSIP — a combination of issuer identification and individual bond identification), a coupon payment rate, term of bond/maturity date, and other data.

The ledger tracks the ownership of the bond as well as the data representing the terms of the bond (Note: sidechains off Bitcoin are possible — so-called “colored coins” — but my strong personal opinion is that a colored-coins approach is a hack, at best, of the pure-numeric blockchain nature of Bitcoin and not something I would take very seriously as an acceptable solution).

The ledger will also need to act as an orchestration engine of sorts to deal with corporate actions, such as bond payments and other servicing needs

Relative to cash, the bond market arguable has far less volume of transactions (in terms of raw # of transactions)

Like central-bank cash, nodes on the network are trading partners, and there exists an implied trust between them.

So similar to central bank cash as described above:

The consensus algorithm must be able to authenticate transactions from institutions transferring bond ownership between each other. Raft or similar “leader” protocols could be appropriate as described above.

The leader node, or notary, validates and confirms transactions do not inappropriate modify the ledger (i.e. r try to reassign ownership of a bond you cannot prove you own).

Authentication of nodes on the network would probably be mandatory or optional, depending on the data hiding requirements and the implementation of data-hiding in the ledger platforms.

However, it has some other unique characteristics:

The ledger must be able to store state that represent numeric, alpha numeric, and other values

Each entity on the ledger may have multiple data attributes which describe that asset, and must be stored on-ledger

There needs to be defined flows for various actions on this asset — servicing activities (disbursing payments to investors), prepayments, redemption, etc. These are generally more complex than a simple swap of assets, and the ledger system should be able to support complex workflows.

Example ledger platforms appropriate to these characteristics could be R3 Corda, as workflows and financial agreements are a core piece of the ledger platform itself.

This is why Interledger is so important — with the thousands of possible asset classes, and what is becoming a TON of available ledger platforms to choose from, you must think about each asset class, it’s runtime characteristics, and choose the platform best suited for those characteristics. Then, choose appropriate “Connectors” to orchestrate multi-ledger transactions.

Full Disclosure: I work for R3, an innovation firm focused on building and empowering the next generation of global financial services technology. R3 built Corda, sourcing requirements from the member financial institutions in order to build a distributed ledger platform that solves practical issues. The adoption of Corda would contribute to R3’s success — however, I am completely neutral on this issue and only recommend platforms appropriate to the right asset class.