Beyond Blockchain: IP-Enabled Exchange of Value and the Inter-Ledger Protocol

nicklipinski
Print Friendly
Share on LinkedIn0Tweet about this on Twitter0Share on Facebook0

SEE LAST PAGE OF THIS REPORT FOR IMPORTANT DISCLOSURES

Howard Mason

203.901.1635

hmason@ssrllc.com

May 22, 2016

Beyond Blockchain: IP-Enabled Exchange of Value and the Inter-Ledger Protocol

“The web has enabled free and open information exchange for a vast number of users around the world. However, it has so far failed to do the same for payments. Instead of finding the cheapest route for each payment from a competitive network of providers, we rely on a small number of proprietary operators with global reach[1]”. Stefan Thomas and Adrian Hope-Bailie, Ripple

  • By using cryptographic approaches to authenticate and confirm transactions on a shared ledger, the blockchain can simplify post-trade settlement and reconciliation processes inherent in double-entry bookkeeping where both counterparties to a transaction maintain their own proprietary ledgers. The current focus of large financial institutions – such as those who are members of the bank-heavy R3 CEV consortium including GS, MS, JPM, BAC, WFC, C, STT and BK – is tilted to this opportunity for back-office re-engineering rather than the threat of disintermediation from new entrants leveraging the more disruptive potential of shared or “distributed” ledger solutions.
  • Blythe Masters, CEO of Digital Asset Holdings, articulates the opportunity as follows[2]: “a block-chain is nothing much more than a fancy kind of database … this is a technology that enables institutions to do what they do already today using databases but a lot quicker, a lot cheaper, with far lower error rates, with less risk, and as a result with lower capital requirements and less vulnerability to cyber-attack.”
  • We agree on the high barriers to entry in the settlement business but believe that inter-ledger (ILP) protocols, applying the same cryptographic technology as the blockchain, will support greater routing flexibility for firms that can brand the customer payments experience and thereby tend to relegate settlement-providers to an increasingly commoditized position. Pushing value to the edge of payment networks in this way is the focus of the tech-heavy W3C working group on ILP protocols which includes FB, GOOG, AAPL, MSFT, TWTR, PYPL, EBAY and TGT, and a case-study of the competitive dynamic, albeit unrelated for now to ILP, is provided by PYPL and Target RED to the extent that they are willing and able to steer payments acquired on own-branded tender, whether wallet or card, to lower-cost settlement routes than provided by network brands such as V and MA.
  • What are inter-ledger protocols? Presently in the US, there are two approaches to by-passing legacy settlement systems for expediting P2P payments: (i) aggregating accounts on the same ledger which is the approach adopted by PayPal and Bitcoin; and (ii) connecting ledgers for interoperability which is the approach adopted by banks through, for example, CX[3] and correspondent banking. Neither approach is ultimately scale-able because of limitations on customer-reach in the case of PYPL and on establishing ad hoc ledger connections in the case of the bank solutions. Inter-ledger (ILP) protocols address the second issue by providing standards for relaying and routing transactions across IP-connected ledgers so that it is possible to send payments to someone not on the same ledger just as the transmission-control (TCP) protocol establishes standards for relaying and routing information-packets across IP-connected local-area networks so that it is possible to send messages to someone not on the same LAN.
  • However, there is an important difference between the IP-enabled exchange of information and the IP-enabled exchange of value; for one thing, information can be copied whereas money must not be. In particular, transmission failure for information can be managed with a retry while, for money, retry can lead to double-spend (i.e. the payment is duplicated). One approach to preventing double-spend on inter-ledger transactions, adopted by ILP pioneer Ripple, uses cryptographic escrow that, in turn, builds on the blockchain protocols for authenticating and confirming transactions and for conditioning payouts on confirmed transactions with “smart” contracts. This note provides a primer for investors on these technologies.

Overview

Bitcoin[4] is a secure, internet-enabled messaging protocol that unlike, say, SMTP for e-mail, can support the exchange of value rather than merely information because it supports cryptographic solutions to authenticating and confirming transactions (thereby assuring that bitcoin is spent only by a legitimate owner and only once). These cryptographic solutions obviate the need for a trusted intermediary to keep a record of confirmed transactions and to protect against dishonest transactions either through recognizing them as fraudulent and refusing to confirm them or through reversing them following successful appeal by an aggrieved counterparty in a centralized dispute-resolution process. As a result, there is no central ledger of confirmed transactions but rather a shared copy of the ledger is kept by all network participants. A key task for Bitcoin, as for all shared ledger protocols, is to forge consensus among these participants around the valid ledger in the event local copies conflict.

Electronic coins, such as bitcoin, are the digital equivalent of cowry shells: they are valuable because they are accepted in a digital community as a store of value and medium of exchange. If Alice wants to send Bob some money, in the form of a message with a digital cowry-shell attached, there are two issues that need to be resolved: Bob needs to know first that Alice is the legitimate owner of the cowry shell (to avoid the problem of double-spend) and second that Alice duly authorized the message (to avoid the problem of fraud). Bitcoin handles these two issues through cryptographic approaches to respectively: (i) confirming a transaction by updating the ledger to reflect a transfer of ownership; and (ii) authenticating a transaction to verify that the author is the legitimate owner of the subject bitcoin. The protocol for confirming transactions is referred to as “mining”, and the protocol for authenticating transactions is referred to as “signing”.

Digital Signing and Transaction Authentication

A Bitcoin transaction is a secure, time-stamped message carrying a digital signature. The signing of transactions is accomplished through public-private key pairs sometimes referred to as “asymmetric” keys as distinct from “symmetric” keys: a box that can be locked and unlocked with the same key is an example of a symmetric key solution. The physical analog of an asymmetric key solution is a box that has three states (Exhibit 1) and two keys: a secret or “private” key that can turn through the states clockwise; and a distributed or “public” key that can turn through the states anticlockwise. In our context, the public key is a bitcoin address which is similar to an e-mail address in that it represents a participant on an IP-connected network but dissimilar in that it is typically single-use: a recipient will typically create, and broadcast to the network, a separate bitcoin address for each transaction rather than aggregating messages into an “inbox” associated with a single e-mail address.

Exhibit 1: Asymmetric Keys in Cryptography Involve a 3-State Lock

Source: SSR

How does this work in practice? To receive bitcoin, Bob distributes his public key or “bitcoin address” to the network and Alice uses it to encrypt or lock a transaction message (moving Bob’s lock from position ‘B’ to position ‘A’). If Bob wants to forward the bitcoin onto Chloe, he encrypts the transaction data using both his private key to sign the message (moving his lock from position ‘A’ to position ‘C’) and with Chloe’s bitcoin address (which is a public key used to move Chloe’s lock from position ‘B’ to position ‘A’). Anyone on the network can verify Bob as the message-sender by using Bob’s public key to move his lock from position ‘C’ to position ‘B’ (which authenticates since only Bob has the private key necessary to set the lock to position ‘C’) but only Chloe can spend the bitcoin by forwarding the message to, say, David since only Chloe has the private key necessary to provide a digital signature (i.e. to set his lock to position ‘C’).

In essence, then, a bitcoin is a chain of digital signatures with a confirmed transaction represented on the ledger by the addition of the digital signature of the prior owner. (Technically, the base unit for transactions are satoshis where 100 million satoshis equals a single bitcoin).

Mining and Transaction Confirmation

What if fraudulent Fred tries to double-spend bitcoin by attempting to forward the same signed transaction to both Harry and Hermione? This is not going to work because, before a transaction is reflected in an update to the Bitcoin ledger, it must be confirmed in the sense of being accepted as valid by the Bitcoin community with consensus-formation achieved through what amounts to a voting process. The specifics for Bitcoin are that payers broadcast candidate transactions to the network and volunteer participants, referred to as “miners”, aggregate some or all of these into a “block” and check that the transactions within a block are both internally consistent and consistent with confirmed transactions on the ledger. Having discovered a viable block, a miner can append it to the ledger along with proof of solving a cryptographic puzzle requiring a quantified amount of computational work. Fellow miners vote to accept the new block by appending their own blocks to it rather than earlier in the chain of blocks, or “block-chain”, that makes up the ledger.

A dissenting miner can choose to append a block not to the most recently-appended block in the chain but to an earlier block in which case the ledger is said to have “forked”. The different forks may well contain conflicting transactions and the community needs to arrive at consensus around which fork is to be accepted as valid. The protocol calls for accepting the fork that is longest in the sense of involving the most amount of cumulative computational work as proven and recorded in each block. This “proof-of-work” approach to consensus-formation means that participant votes are weighted by the amount of computational work they have demonstrably completed. In theory, a dissenting or dishonest miner could invalidate recent blocks in the ledger by forking at an earlier point and completing more work than all consensus-miners combined to push the resulting new branch to overtake the consensus branch. In practice, however, honest miners have an incentive to append blocks, either to confirm their own transactions and/or to receive the reward of newly-minted bitcoin that the protocol awards to successful miners, for the least amount of computational work and so will tend to work on the longest branch of a forked ledger. Regardless, by the time a transaction is several blocks deep in the block-chain it is for all practical purposes irreversible and immutable.

Block-chain as a Database

The initial cryptocurrency application of the block-chain for bitcoin has been challenged by government regulation since the anonymity of the approach, with participants represented only on the network by a bitcoin address that is not bound to personally-identifying information (such as legal name), conflicts with official concern around know-your-customer (kyc) and anti-money-laundering (aml) rules. The current commercial focus has therefore shifted to the use of the blockchain as a database with Blythe Masters, CEO of Digital Asset Holdings, articulating the point of view as follows[5]: “I never became particularly enamored with cryptocurrency … a blockchain is nothing much more than a fancy kind of database … this is a technology that enables institutions to do what they do already today using databases but a lot quicker, a lot cheaper, with far lower error rates, with less risk, and as a result with lower capital requirements and less vulnerability to cyber-attack.”

The ability of the block-chain to act as a general-purpose database, rather than simply a ledger for bitcoin transactions, arises because supplementary information can be encoded into private keys[6] or incorporated into the meta-data for a transaction which is supported for each input and output to a Bitcoin transaction. These meta-data are encoded as a “script” which, at the very least for an output, will encumber future spending by requiring that a spender provide a bitcoin address (i.e. public key) corresponding to that specified as the destination in the last transaction and a signature as evidence of access to the private key corresponding to this address. However, the script can also encode evidence of a claim on a real-world asset, such as a stock certificate or land-title, turning the bitcoin into a token for that claim and allowing the claim to be transferred along with the bitcoin.

In a pure database use-case, a block-chain is private in the sense that access is permissioned with the identity of participants known to an administering authority that is trusted, for example, to sanction participants attempting to encode bogus claims on real-world assets into bitcoin scripts. This a far cry from the original intent of the bitcoin protocol which was to substitute cryptographic proof for trust completely but nonetheless has more immediate potential: the use of a shared database, which establishes consensus around confirmed transactions in near real-time, obviates the need for post-trade settlement and for reconciliation between the separate ledgers that are currently maintained by counterparties in a standard double-entry book-keeping model. Again, Blythe Masters makes the business case: “if you or I could agree, instead of keeping our separate records, to share the same record from inception where when executed the point at which that transaction is readied for commission to settlement … we are sharing one jointly agreed signed and authorized by both of us transaction we are eradicating that need for post-trade reconciliation and settlement process that is lengthy time-consuming and expensive”.

This view of private block-chains as an opportunity to simplify, if not eradicate, post-trade settlement and reconciliation processes by using cryptographic authentication to initiate transactions and distributed consensus algorithms to confirm them to a shared ledger is endorsed by industry with Biff Bowman, CFO of NTRS, commenting last week that “there are two views on what block-chains impact will be … one of which his that it can be a dis-intermediator and that is a threat … but I think we view it more as an opportunity to lower our costs to clear … to make our process more efficient … to clear trades and get information to our clients in a more expeditious manner”. Indeed, having conducted tests on commercial paper transactions last February, the R3 CEV block-chain consortium of 40+ financial institutions including GS, MS, JPM, BAC, WFC, C, STT, BK along with DB and HSBC, is moving in collaboration with government regulators towards test for integrating block-chains into legacy transaction systems[7].

Smart Contracts

The scripting language in the Bitcoin protocol allows bitcoin not only to represent real-world assets but also to be smart in the sense of supporting deferred or conditional payouts for confirmed transactions. For example, if I wish to make an irrevocable gift of a bitcoin to my daughter on her 25th birthday, I can include in the script a specification that payout is held until that date. I can then provide her with the transaction message so that she can broadcast it to the network nearer the time or, alternatively, she or I can broadcast it immediately but there will be no payout until the specified date even once the transaction is confirmed.

Alternatively, I may want the transaction to payout on her wedding date and can then include in the script a specification that payout is held until the transaction is also signed by a third-party who is trusted to honestly report if and when a wedding takes place. This has not eliminated trust entirely but has reduced it in the sense that I cannot revoke my promise to pay other than by attempting to lean on the third-party to fail to report honestly; in other words, contingent bitcoin transactions remove the risk of default by the payer but rely on the ability of the transaction to accept additional input, in the form of an additional signature based on real-world events, to trigger payment.

Even this external awareness can be codified if the counterparties can agree on how to unambiguously test whether a condition related to external state is satisfied using digitally available data. The concept is that these data are made available to an “oracle” which evaluates the payout condition and, once it is satisfied, acts in the role of a third-party agent to sign the transaction and trigger payout. Today, it is easier to see an oracle reliably testing for a payout conditioned on, say, the Lightning winning the Stanley Cup than for the occurrence of a wedding but that will change as, among others, Google realizes its mission of organizing the world’s information and making it universally accessible and useful.

Cryptographic Escrow and Inter-Ledger Protocols

An immediate application for smart contracts is the use of cryptographic escrow accounts for inter-ledger protocols (ILP) which will be as transformative to the exchange of value as the transmission control protocols (TCP) were for the exchange of information. Indeed, the two protocols address the same problem in different contexts: the TCP protocol provides rules for relaying and routing information-packets across different communication networks so that you can send and receive messages to and from another person who is not on the same local network; and the ILP protocol will provide rules for relaying and routing transactions across different ledgers so that you can send and receive value to and from another person who is not on the same local ledger.

There is already precedent for connectivity across ledgers. Partly in response to the threat from PYPL, which enables real-time P2P payments by signing up customers to its own ledger and effecting transactions through book-entry to this proprietary ledger, the large US depositary institutions (JPM, BAC, WFC, COF, PNC, and BBT) have formed clearXchange (CX) which acts, in effect, as a connector between their proprietary ledgers and, of course, correspondent banking involves relaying funds from an initial source bank to a final, typically international destination bank through the ledgers of a chain of intermediary banks. However, there is no standard protocol for connecting ledgers – no minimial protocol to which a proprietary ledger can conform to connect to other proprietary ledgers. Among others, a pioneer in distributed ledger technology, Ripple, is looking to establish this protocol using smart transactions with escrow payments conditioned on receipts.

The specifics are straightforward in concept and use elementary smart contracts. If Alice on ledger A wants to pay Bob on ledger B, she needs to find a connector, Chloe, that is represented on both ledgers. Alice then sends a smart transaction to Chloe on ledger A with payout conditioned on evidence of a cryptographic receipt from Bob. Once this transaction is confirmed on ledger A, Chloe sends a matching smart transaction to Bob on ledger B conditioned in an identical way. With this preparedness phase complete, Bob can gain access to funds by providing a cryptographic receipt on ledger B to satisfy the payout condition of the transaction from Chloe; Chloe then forwards this receipt to Alice on ledger A to satisfy the payout condition of the transaction from her and thereby gain access to funds. The use of confirmed transactions means that neither Chloe nor Bob bear default risk from Alice or Chloe respectively; if they provide the necessary cryptographic receipt, payment is assured. On the other hand, the use of Chloe as an intermediating escrow agent via a smart transaction with a conditional payout assures Alice that should the transaction fail on ledger B, so that Bob does not provide a cryptographic receipt, she can recover funds. Any ledger can integrate ILP simply by enabling escrowed transfers and this capability is already built-in to most shared ledgers as it is, through script meta-data, into Bitcoin.

©2016, SSR LLC, 1055 Washington Blvd, Stamford, CT 06901. All rights reserved. The information contained in this report has been obtained from sources believed to be reliable, and its accuracy and completeness is not guaranteed. No representation or warranty, express or implied, is made as to the fairness, accuracy, completeness or correctness of the information and opinions contained herein.  The views and other information provided are subject to change without notice.  This report is issued without regard to the specific investment objectives, financial situation or particular needs of any specific recipient and is not construed as a solicitation or an offer to buy or sell any securities or related financial instruments. Past performance is not necessarily a guide to future results. The analyst principally responsible for the preparation of this research or a member of the analyst’s household holds a long equity position in the following stocks: JPM, BAC, C, WFC, and GS.

  1. http://www2016.net/proceedings/companion/p281.pdf
  2. http://www.bloomberg.com/news/articles/2015-10-06/blythe-masters-says-forget-bitcoin-embrace-the-blockchain
  3. clearXchange
  4. We follow convention in using Bitcoin, with an upper case ‘B’, to represent the protocol and bitcoin, with a lower case ‘b’, to represent the currency.
  5. http://www.bloomberg.com/news/articles/2015-10-06/blythe-masters-says-forget-bitcoin-embrace-the-blockchain
  6. The Economist provides an illustration of how the use of a deterministic (as opposed to random) private key created by hashing the protocol for a clinical trial can help protect against negative outcome switching where post-hoc adjustment of the focus of a clinical trial to fit experimental results undermines the scientific method.
  7. http://blogs.wsj.com/cio/2016/03/02/key-blockchain-vendors-cloud-providers-square-off-in-major-test/
Print Friendly