A brief history of R3 – the Distributed Ledger Group

What’s in a name?

I was at an event last week and someone pulled me aside asked: why do you guys at R3 typically stress the phrase “distributed ledger” instead of “blockchain”?

The short answer is that they are not the same thing.

In simplest terms: a blockchain involves stringing together a chain of containers called blocks, which bundle transactions together like batch processing, whereas a distributed ledger, like Corda, does not and instead validates each transaction (or agreement) individually.1

The longer answer involves telling the backstory of what the R3 consortium is in order to highlight the emphasis behind the term “distributed ledger.”

Inspired by IMF report, page 8

Genesis

R3 (formerly R3 CEV) started out as a family office in 2014.2 The “3” stood for the number of co-founders: David Rutter (CEO), Todd McDonald (COO), and Jesse Edwards (CFO). The “R” is the first initial of the CEO’s last name.  Very creative!

During the first year of its existence, R3 primarily looked at early stage startups in the fintech space.  The “CEV” was an acronym: “crypto” and “consulting,” “exchanges,” and “ventures.”

Throughout 2014, the family office kept hearing about how cryptocurrency companies were going to obliterate financial institutions and enterprises.  So to better understand the ecosystem and drill into the enthusiasm around cryptocurrencies, R3 organized and held a series of round tables.

The first was held on September 23, 2014 in NYC and included talks from representatives of: DRW, Align Commerce, Perkins Coie, Boost VC, and Fintech Collective.  Also in attendance were representatives from eight different banks.

The second round table was held on December 11, 2014 in Palo Alto and included talks from representatives of: Stanford, Andreessen Horowitz, Xapo, BitGo, Chain, Ripple, Mirror, and myself.  Also in attendance were representatives from 11 different banks.

By the close of 2014, several people (including myself) had joined R3 as advisors and the family office had invested in several fintech startups including Align Commerce.

During the first quarter of 2015, David and his co-founders launched two new initiatives.  The first was LiquidityEdge, a broker-dealer based in NYC that built a new electronic trading platform for US Treasurys.3  It is doing well and is wholly unrelated to R3’s current DLT efforts.

The second initiative was the incorporation of the Distributed Ledger Group (DLG) in Delaware in February 2015.  By February, the family office had also stopped actively investing in companies in order to focus on both LiquidityEdge and DLG.

In April 2015 I published Consensus-as-a-Service (CaaS) which, at the time, was the first paper articulating the differences between what became known as “permissioned” and “permissionless” blockchains and distributed ledgers.  This paper was then circulated to various banks that the small R3 team regularly interacted with.

The following month, on May 13, 2015, a third and final round table was held in NYC and included talks from representatives of Hyperledger (the company), Blockstack, Align Commerce and the Bank of England.  Also in attendance were representatives from 15 banks as well as a market infrastructure operator and a fintech VC firm.  In addition to the CaaS paper, the specific use-case that was discussed involved FX settlement.4

The transition from a working group to a commercial entity was formalized in August and the Distributed Ledger Group officially launched on September 1, 2015 although the first press release was not until September 15.  In fact, you can still find announcements in which the DLG name was used in place of R3.

By the end of November, phase one of the DLG consortium – now known as the R3 consortium – had come to a conclusion with the admission of 42 members.  Because of how the organization was originally structured, no further admissions were made until the following spring (SBI was the first new member in Phase 2).

So what does this all have to do with “distributed ledgers” versus “blockchains”?

Well, for starters, we could have easily (re)named or (re)branded ourselves the “Blockchain Group” or “Blockchain Banking Group” as there are any number of ways to plug that seemingly undefinable noun into articles of incorporation.  In fact, DistributedLedgerGroup.com still exists and points to R3members.com.5 So why was R3 chosen?  Because it is a bit of a mouthful to say DistributedLedgerGroup!

Corda’s genesis

Upon launch, the architecture workstream lead by our team in London (which by headcount is now our largest office), formally recognized that the current hype that was trending around “blockchains” had distinct limitations.  Blockchains as a whole were designed around a specific use-case – originally enabling censorship-resistant cryptocurrencies. This particular use-case is not something that regulated financial institutions, such as our members, had a need for.

While I could spend pages retracing all of the thought processes and discussions surrounding the genesis of what became Corda, Richard Brown’s view (as early as September 2015) was that there were certain elements of blockchains that could be repurposed in other environments, and that simply forking or cloning an existing blockchain – designed around the needs of cryptocurrencies – was a non-starter.  At the end of that same month, I briefly wrote about this view in a post laying out the Global Fabric for Finance (G3F), an acronym that unfortunately never took off. In the post I specifically stated that, “[i]t also bears mentioning that the root layer may or may not even be a chain of hashed blocks.”

In October 2015, both James Carlyle and Mike Hearn formally joined the development team as Chief Engineer and lead platform engineer respectively.  During the fall and winter, in collaboration with our members, the architecture team was consumed in the arduous process of funneling and filtering the functional and non-functional requirements that regulated financial institutions had in relation to back office, post-trade processes.

By the end of Q1 2016, the architecture team gestated a brand new system called Corda.  On April 5, 2016, Richard published the first public explanation of what Corda was, what the design goals were and specifically pointed out that Corda was not a blockchain or a cryptocurrency.  Instead, Corda was a distributed ledger.

Prior to that date, I had personally spent dozens of hours clarifying what the difference between a blockchain and a distributed ledger was to reporters and at events, though that is a different story.  Unfortunately even after all these explanations, and even after Richard’s post, the Corda platform was still inappropriately lumped into the “blockchain” universe.

Following the open sourcing of Corda in November 2016, we formally cut the “CEV” initials entirely from the company name and are now known simply as R3.  Next year we plan to make things even shorter by removing either the R or 3, so watch out domain squatters!

Today

As of February 2017, the R3 consortium is formally split into two groups that share knowledge and resources: one group is focused on building out the Corda platform and the other, the Lab and Research Center, is focused on providing a suite of services to our consortium members.  I work on the services side, and as described in a previous post, my small team spends part of its time filtering vendors and projects for the Lab team which manages several dozen projects at any given time for our consortium members.

The Lab team has completed more than 20 projects in addition to 40 or so ongoing projects.  Altogether these involved (and in some cases still involve) working with a diverse set of platforms including Ethereum, Ripple, Fabric, Axoni, Symbiont and several others including Corda.  Since we are member driven and our members are interested in working and collaborating on a variety of different use-cases, it is likely that the services side will continue to experiment with a range of different technologies in the future.

Thus, while it is accurate to call R3 a technology company focused on building a distributed ledger platform and collaborating with enterprises to solve problems with technology, it is not accurate to pigeonhole it as a “blockchain company.”  Though that probably won’t stop the conflation from continuing to take place.

If you are interested in understanding the nuances between what a blockchain, a database, and a distributed ledger are, I highly recommend reading the multitude of posts penned by my colleagues Antony Lewis and Richard Brown.

  1. Blockchains inspired by cryptocurrencies such as Bitcoin used blocks because Satoshi wanted identity-free consensus (e.g., pseudonymity).  That implies miners can come and go at will, without any kind of registration, which eliminated the choice of using any existing consensus algorithm.

    As a result, Satoshi’s solution was proof-of-work (PoW).  However, PoW is susceptible to collisions (e.g., orphan blocks).  When a collision occurs you have to wait longer to obtain the same level of work done on a transaction. Thus you want to minimize them, which resulted in finding a PoW on average every ten minutes.  This means that in a network with one minute propagation delays, not unlikely in a very large network (BGP sees such propagation times) then you waste ~10% of total work done, which was considered an acceptable loss rate in 2008 when Satoshi was designing and tweaking the parameters of the system.

    Distributed ledgers such as Corda, use a different design because it is an identified network, where members cannot just come and go at will, and do have to register. With Corda, the team also assumes relatively low propagation times between members of a notary cluster.  One of the key differences between mere PoW (i.e. hashcash) and a blockchain is that in the latter, each block references the prior – thus PoWs aggregate.  It can be tough to do that unless all transactions are visible to everyone and there is a single agreed upon blockchain but if you do not, you will not get enough PoW to yield any meaningful security. []

  2. The R3CEV.com domain was created on August 13, 2014. []
  3. It may look like an odd spelling, but Treasurys is the correct spelling. []
  4. At the time, I was an advisor to Hyperledger which was acquired by Digital Asset the following month. []
  5. The DistributedLedgerGroup.com domain was created on December 23, 2014 and R3members.com was created on March 15, 2016. []

Layer 2 and settlement

Nary a week goes by without having to hear a startup claim their service will have the ability to “settle” a cryptocurrency or virtual asset or something “smart,” on to Layer 2.

In this instance, Layer 2 refers to a separate network that plugs into a cryptocurrency via off-chain channels.1

This often comes up in conjunction with conversations surrounding the Bitcoin block size debate: specifically around (hypothetically) scaling to enable Visa-like transaction throughput vis-a-vis projects like the Thunder and Lightning network proposals which are often characterized as Layer 2 solutions.2

As Wolfgang Pauli might say, this is not even wrong.

Why?  For starters, the comparisons are not the same.


Apples-to-oranges

Visa is a credit clearing and authentication network, not a settlement network; in contrast no cryptocurrency has credit lines baked-in.  In addition – as I penned a year ago – in practice “settlement” is a legal concept and typically requires ties into the existing legal infrastructure such as courts and legally approved custodians. 3

Two simplified examples:

  1.  If Bob wanted to settle cash electronically and he lived in just about any country on the globe, the only venue that this electronic cash ultimately settles in right now is a central bank usually via its real-time gross settlement (RTGS) network
  2.  If Bob owned the title to a (dematerialized) security and he is trying to transfer ownership of it to someone else, the security ultimately settles in a central securities depository (CSD) such as the DTCC or Euroclear

What does this have to do with the world of blockchains and DLT?

As of this writing, no central bank-backed digital currency (CBDC) exists.4 As a consequence, there is no real digital cash settlement taking place on any ledger outside of a banks’ own ledger (yet).

One of the key goals for DLT platforms is to eventually get “cash on-ledger” issued by one or more central bank.  For instance, at R3 we are currently working on a couple of CBDC-related projects including with the Bank of Canada and Monetary Authority of Singapore.  And other organizations are engaged in similar efforts.

Why?

In short, one of the potential advantages of using a CBDC issued onto a distributed ledger is the enabling of network participants (such as financial institutions) to settle dematerialized (digitized) asset transfers without relying on outside reconciliation processes. Delivery versus Payment (DvP), the simultaneous exchange of an asset and its payment, could actually take place on-chain.5

However, today if participants on a distributed ledger wanted to settle a trade in cash on a distributed ledger, they could not. They would still need to settle via external processes and mechanisms, which according to an estimate from Autonomous research, collectively costs the industry $54 billion a year.  As a result, the industry as a whole is attempting to reduce and – if possible – remove frictions such as these post-trade processes.6

And according to a recent paper from the Bank of England as well as a new paper from the Federal Reserve, CBDCs are one invention that potentially could reduce some of these associated frictions and processes.

How it theoretically works

So how does that tie back in to a hypothetical Layer 2 or 3, 4, 5, connected to a cryptocurrency network?

Assuming one or more of the Lightning implementations is built, deployed, and goes “into production,” the only object that is being tracked and confirmed is a cryptocurrency.7

Cryptocurrencies, as I have written before, are anarchic: purposefully divorced from legal infrastructure and regulatory compliance.

As a result, it cannot be said that “Layer 2” will act as a settlement layer to anything beyond the cryptocurrency itself, especially since the network it attaches to can at most by design only guarantee probabilistic finality.8

In fact, the most accurate description of these add-on networks is that each Lightning implementation requires building completely separate networks run and secured by different third parties: pseudonymous node operators acting as payment processors.  What are the service-level agreements applied to these operators?  What happens if it is no longer profitable or sustainable to operate these nodes?  Who are you going to call when something – like routing – doesn’t work as it is supposed to?

And like most cryptocurrencies, Lightning (the generic Lightning) is developed as a public good, which – as a recent paper explored – may have hurdles from a fiduciary, governance, and accountability perspective.

Assuming the dev teams working on the various implementations solve for decentralized routing and other challenges, at most Lightning will be a clearing network for a cryptocurrency, not electronic cash or securities.  Therefore proponents of existing Layer 2 network proposals might want to drop the “settlement” marketing language because settlement probably isn’t actually occurring.  Trade confirmations are.

But what about colored coins?  Can’t central banks just use the Bitcoin network itself and “peg” bitcoins directly to cash or set-up a Bitcoin-like system that is backed by the central bank itself?

These are tangential to “Layer 2” discussion but sure, they could in theory.  In fact, the latter is an idea explored by JP Koning in a recent paper on “Fedcoin.”  In practice this is probably not ideal for a variety of reasons including: privacy, confidentiality, recourse, security, scalability, public goods problems, and the fact that pseudonymous miners operating outside the purview of national regulatory bodies would be in charge of monetary policy (among many other regulatory compliance issues).

Why not just use an existing database to handle these regulated financial instruments then?  This is a topic that has and will fill academic journals in the years to come (e.g., RSCoin).  But for starters I recommend looking at a previous post from Richard Brown and two newer posts from Antony Lewis.

Conclusion

There are real, non-aesthetic reasons why aviation designers and manufacturers stopped building planes with more than two or three wings, namely aerodynamics.  Creative ideas like Lightning may ultimately be built and deployed by cryptocurrency-related companies and organizations, but it is unclear how or why any regulated enterprise would use the existing proposals since these networks are not being architected around requirements surrounding settlement processes.

Perhaps that will change in time, but laws covering custody, settlement, and payment processing will continue to exist and won’t disappear because of anarchic “Layer 2” proposals.  Maybe it is possible to borrow and clone some of the concepts, reusing them for alternative environments, just like some of the “blockchain”-inspired platforms have reused some of the ideas underlying cryptocurrencies to design new financial market infrastructure.  Either way, both worlds will continue to co-exist and potentially learn from one another.

Endnotes

  1. From a word choice, it is arguably a misnomer to call Lightning a “layer” at all because relatively little is being built on top of Bitcoin itself.  These new networks are not powered by mining validators whereas colored coin schemes are. []
  2. While he doesn’t delve too much into any of these specific projects, Vitalik Buterin’s new paper on interoperability does briefly mention a couple of them.  Also note that the Teechan proposal is different than Lightning in that the former scales via trusted hardware, specifically Intel’s SGX tech, and sidesteps some of the hurdles facing current Lightning proposals. []
  3. This topic is a ripe area for legal research as words need to be precisely defined and used.  For instance, if bitcoins do not currently “settle” (in the sense that miners and users do not tie on-chain identities into court recognized identity, contract, and ledger systems thereby enabling traditional ownership transfer), does this impact government auctions of seized cryptocurrencies?  What was the specific settlement process involved in the auction process and are encumbrances also transferred?  It appears in practice, that in these auctions bitcoins do transfer in the sense that new entities take control of the private key(s), is this settlement? []
  4. An argument can be made that there are at least 3 publicly known exceptions to this, though it depends on the definition of an in-production CBDC.  This includes vendors working with: Senegal, Tunisia, and Barbados. []
  5. In blockchain parlance this is called an “atomic transfer.” []
  6. It is not just reconciliation processes, it is the actual DvP itself (plus the subsequent “did you get it yet” reconciliation processes). []
  7. As an aside, what are the requirements for “being in production?”  In the enterprise world, there is a difference between being in a sandbox and being in production.  Which blockchain(s) have been vetted for and secured against real production level situations and fulfilled functional requirements such as scaling and preserving confidentiality? []
  8. See Settlement Risks Involving Public Blockchains []

Chainwashing

I was recently talking with a friend who spent the past decade in an operations role at a large enterprise in the telecommunication sector.  He has a matter-of-fact personality that likes to cut through the smoke and mirrors to find the fire.

I explained to him my role of having to filter through the dozens of entities that my market research team at R3 speaks with each month. And the formal process that our small team uses to look and find organizations that would be a good fit for R3’s Lab project pipeline.

For instance, because we typically act as the first part of the funnel for our organization, we end up listening to a great deal of startup pitches. And we are continually bombarded by endless “blockchain” and DLT noise.  The first year alone we looked at and spoke to more than 300 entities, a number that has now reached about 400.

This is not to say that there are only 400 companies/vendors/organizations/projects billing themselves as “blockchain” related entities… unfortunately that nebulous term has ballooned to encompass everything from cryptocurrencies to big data to IoT and now probably numbers in the thousands.

If you’re working in capital markets, how to tell the pretenders from the real deal?

Should you seek advice from people who never interface with enterprises or institutions and get all their wisdom from social media?  Or listen to columnists whose only interaction with banks is the ATM or a cryptocurrency meetup?  Or to media outlets that do not disclose their (coin) holdings?  Before answering these, let’s look at a new phrase below.

Thirteen months ago I gave a short presentation talking about the “blockchain” hype cycle.

The month before that – in December 2015 – I mentioned how much of the enthusiasm surrounding “blockchains” seemed a bit similar to the exuberance around “gluten free” food: how most people at fintech conferences talking about “blockchains” really couldn’t explain why blockchains were great in much the same way that many people asking for “gluten-free” food couldn’t tell you why gluten is or is not good for you.

I explained this to my friend and he said that the euphoria surrounding blockchains – and its vertical rise on the Gartner hype cycle – is similar to what he observed and experienced in “the cloud” space earlier this decade.  And more specifically, to the phenomenon called “cloudwashing”:

Cloud washing (also spelled cloudwashing) is the purposeful and sometimes deceptive attempt by a vendor to rebrand an old product or service by associating the buzzword “cloud” with it. (Source)

So with that, I’d like to coin a new phrase: “chainwashing.”

I have personally seen dozens of decks from vendors along the entire spectrum of sizes during the current hype cycle.  And watched the evolution of “blockchain creep” — how over time the word “blockchain” would appear more frequently not just on each slide, but in scope and vertical.

For instance, there are couple dozen different startups that claim to have somehow built an enterprise-grade blockchain system without having to go through the arduous process of gathering the functional and non-functional requirements from the enterprises they intended to integrate with.  Magic!

While startup founders should shoulder the blame for these marketing gimmicks – as should the reporters that often own but do not disclose their (coin) holdings – investors are also to blame for not just talking their book, but also obfuscating their portfolio companies by pressuring them to rebrand retail-focused cryptocurrency products as bonafide “enterprise blockchain” platforms.  They are not the same thing.

So what are some evaluation criteria to help identity the signal from the noise?

If your job is to help filter vendors for financial institutions, governments, investment funds, or other large enterprises, then some of these questions may be helpful in determining whether or not your firm should engage with the vendor:

  • Why is the vendor using a blockchain?
  • What is the vendor’s definition of a blockchain?
  • Who has a problem that needs a blockchain in order to solve it: the vendor or the vendor’s customer?
  • What is it about a blockchain that solves a problem that couldn’t be solved with existing technoloogy?
  • If a blockchain-related infrastructure provides a solution to for the vendor, can it use any other existing technology to solve its needs?
  • Do the founders and management team have experience managing, building, and/or deploying enterprise-grade systems or critical infrastructure?
  • Does the vendor as a whole have the appropriate contacts and connections with institutions and regulators?
  • Does the vendor have enough run way to build through a long sales cycle?

By asking these types of questions our team has helped filter the 400 or so companies/projects into a much more manageable dozen.

We think the number of companies with legs will continue to increase over time but chainwashing will continue to be a noise pollution problem for the next few years in the enterprise world even after production systems have been integrated into institutions.

As a consequence, it is probably safe to assume vendors are trying to pull a fast one on you, especially if it involves needing your company to acquire a cryptocurrency or “permissioning off” an existing cryptocurrency.

Remember: cryptocurrencies in the vein of Bitcoin were intentionally not designed to integrate with and fulfill the requirements of regulated institutions (like settlement finality) any more than a helicopter was designed to handle long distance cargo hauling.  Chainwashing is the opposite of being fit-for-purpose and we see it with marketing gimmicks like “Layer 2,” the topic of the next post.

Update: see also Evolving Language: Decentralized Financial Market Infrastructure