Blockchains 101

I wrote this in an effort to create a primer for executives when “blockchain” started to become popular in the summer of 2015.

PART I

What are blockchains?
Blockchains are a way to implement a distributed ledger, a record of consensus with a cryptographic audit trail which is maintained and validated by several separate nodes. Blockchains sit ‘below’ a distributed ledger and act as a way to order and validate the transactions in the ledger. To that end, you can say that blockchains are a way to achieve the consensus necessary for a distributed ledger.

Though the concept of a distributed ledger has been around for a while, Satoshi Nakamoto, the creator of Bitcoin, introduced a blockchain to incarnate a decentralized ledger maintained by anonymous consensus. Bitcoin’s popularity has demonstrated the value of cryptographic ledgers and revived an interest in the technology. Today, there are many companies vying to take the concept of a blockchain and introduce it to businesses, specifically financial services.

Prima facie, blockchains bring very valuable propositions to banking. For example, the basic operations of a bank require a lot of reconciliation among the separate records of different divisions such as risk management, middle office, etc. Blockchains can simplify this process tremendously as they are a way to reduce friction, uncertainly and achieve consensus* among a multitude of actors.

At a high level, blockchains are a data structure which permits the concurrent editing of a shared state while maintaining its unicity. The way the shared state is determined is through its consensus algorithm, which can vary in its mechanics. That is, not all blockchains are created the same way even though they generally try to achieve the same outcome.

There are many permutations of blockchains which determine how they achieve consensus. Though Bitcoin is the most popular example of a ledger leveraging blockchains, there are multiple applications of blockchain powered ledgers beyond cryptocurrencies.

The adjectives and ways of describing ledgers primarily explain how they work on a technical level. Some of these descriptions are a bit confusing and counter-intuitive.

Here are the main permutations:

Decentralized means no one is given a privileged position in the algorithm a priori. Distributed means there are multiple nodes maintaining the ledger. The most popular types of blockchains are decentralized and distributed (e.g., Bitcoin).

Note that distributed is a superset and decentralized / centralized are a way to describe the rights that nodes have in operating distributed ledgers. A non-distributed and decentralized ledger cannot exist, but many non-distributed solutions for things like payment processing are necessarily centralized today.

What are Smart Contracts?
Often described in the same breath as blockchains, smart contracts are programmable contracts defined with computer code which can be executed and enforced automatically on a distributed ledger. There are smart contracts which are not on ledgers (Monetas) but, for our purposes, we’re interested in ones on distributed ledgers.

Smart contracts represent an interesting innovation in blockchain technology because they can act as a control or business rule within the protocol.

* — In this sense, consensus is really about eliminating the errors that frequently pop up and require reconciliation
** — Note: you need a blockchain to operate a decentralized system

PART II

Types of Distributed Ledgers
Distributed ledgers come in two flavors: decentralized and centralized. Decentralized systems grant equal rights (e.g., signing a ledger) within the protocol to all participants and centralized systems designate certain users with particular rights. These two different structures have very powerful implications on the way a distributed ledger is maintained.

Advantages and Challenges of a Decentralized System
Decentralized systems have some unique features which make them commercially appealing and viable alternatives to traditional distributed ledgers:

• Security: Strong cryptography provides secure authentication of the parties. Mathematical properties strongly reduce (but do not eliminate) operational risk.
• No single point of failure: If a party is compromised, the rest of the network remains secure. Every party can continuously audit the ledger.
• Price: Disintermediates the central third party.
• Transparency: Audits can be built in the protocol.
• Privacy: Privacy can be achieved using a variety of different methods.

No software is a panacea. Decentralized systems suffer from setbacks that ought to concern potential users, particularly in capital markets:

• Scalability: Blockchain tech limits the rate at which transactions can be performed and introduces delays before a transaction is finalized. (In Bitcoin, this can be in the order of minutes, making it a terrible fit for platforms requiring low latency.)
• Transparency: Sophisticated analysts could decode the transaction patterns of the players by analyzing the blockchain.
• Regulation: Current regulatory bodies assume centralized actors; there is a lack of precedent. Furthermore, the technology spans across the mandate of many agencies.

Advantages and Challenges of a Centralized System
When discussing distributed ledgers as they apply to financial services, some of the usual criticisms of centralized systems don’t apply. Most enthusiasts about cryptocurrencies critique centralized distributed ledgers on the basis that they can be manipulated or attacked. In a closed system with trusted, registered participants, this issue is moot.

That said, one major critique still holds: Hard coding a particular role for specific participants isn’t future proof. Institutions evolve, alliances shift and a fixed set of institutions is a sitting duck for infiltration and subversion. To that end, a decentralized system might be more politically agreeable.

Food for Thought
Tezos uses decentralized protocols in which holders of tokens can dynamically delegate power towards parties they deem reliable.

PART III

Use Cases
Blockchains have been proposed as solutions to replace markets, hold warranties on dishwashers and act as a backend for web forums. It is my opinion that the potential use cases have been overblown. That said, there are four important situations in which a blockchain might become materially valuable:

1. There is no well-established authority in place. If there is an established authority in place, either the blockchain would agree with the authority (which is uninteresting) or it does not (and is not valuable).
2. There are finite or countable resources transacted upon. Distributed databases have no concept of count, but a blockchain does. When dealing with assets you need a distributed ledger, not a database.
3. Non-IP related values are being transacted upon. Blockchains are not a preventative measure from recording patented records, for example.
4. A cryptographic audit trail is materially necessary. This is particularly relevant for accounting and business records. Blockchains are good for keeping track of things, including very complex things. In banks, this is usually the job of back office. A swap with multiple parties that’s been sold and resold and moved between custodians could be a nightmare for a back office, but it would be a walk in the park for a distributed ledger maintained between the different players. Though this could be achieved with properly designed databases, by being distributed the ledger offers a crucial advantage: no political battle over who controls what.

Though this list might sound obvious, it makes a lot of projects in the space moot.

Example Uses
1. Assets with complex clauses like OTC derivatives* would benefit from blockchain-based, smart contract enabled protocols in three ways:

a. Tracking the settlements that happen during the life of the product via the cryptographic ledger.

b. Expressing contracts as code, not potentially ambiguous legal documents which may be poorly suited for the task. The clients and the sellers would know exactly the product they’re facing.

c. Auditable contracts so that, if there is any discrepancy, it can be rooted out immediately. Banks can know not only what contracts they are a party to, but *how* it came to be.

2. Assets where the blockchain operator is going to be the sole custodian, or part of a tight knit network of custodians (e.g., fractional ownership of gold in a vault). In this instance, blockchains would be resolving a political issue.

3. Asset classes which do not have good existing authoritative ledgers. Potential candidates under this umbrella include private investment markets, the art market, and fishing rights. In this instance, blockchains would exist as authoritative sources and would introduce coherency into a fragmented market.

4. Some digital assets (like bitcoins) but also alternative domain names.

In principal, it makes sense to track ownership of equities and debts on a blockchain, though they are of little use if they conflict with another existing system. If a blockchain is supposed to represent ownership of an asset and it disagrees with a more authoritative source, it isn’t doing much good by creating more churn. If it agrees with the authoritative source, it isn’t saying anything interesting.

Smart Contracts and Capital Markets
Much of the enthusiasm over blockchains in the capital markets space has converged on use cases leveraging smart contracts, the coded contracts we discussed earlier. This is because smart contracts can expedite the reconciliation process and automate some of the legal complexity in the marketplace.

To that end, there is a bit of confusion about the role smart contracts can play:

1. Clearing and settlement. Some of the solutions proposed for using blockchains is to have Bitcoin-like tokens and treat them like dollars with automated clearing and settlement. It’s important to note that if you don’t have convertibility for these tokens, you don’t have a peg. The Fed is the ultimate authority over what is a dollar and, unless the Fed runs a Fedcoin, there is no way to exchange dollars on a chain. The best a protocol can achieve is representing an IOU.

2. Liquidity and markets. A key question among clients contemplating the use of smart contracts for trading solutions is how they will deal with liquidity. Many of the traditional problems with liquidity in the marketplace are not solved or complicated by the introduction of smart contracts.

It’s possible for the ledger to act as a market place with people directly offering to trade a certain price. However, this is not necessarily a good idea because, when you’re offering liquidity, you want to be able to change your quotes very fast — you can’t wait for one block. It makes more sense to conclude trades outside of the ledger, then report them to the ledger, in the same way that OTC trades are brought to a centralized clearing house.

When you’re dealing with liabilities on the chain (because unless you have a Fedcoin, that’s all you’re going to get) there is a need for liquidity which is a bit different. The best way to represent these liabilities is as demand deposits. In this instance, you can call the bank or go to their website and get money credited to your account in exchange for sending them back their liability on the ledger.

If different liabilities trade at a discount — if there’s any imbalance — arbitrageurs will buy up the cheap ones and convert them into dollars. Part of this can be automated with a smart contract.

You can design a smart contract and assign it a lot of liabilities from different bank and offer to send such IOUs in exchange for an IOU of the bank of your choice, for a given fee. Until the Fed decides to release a Fedcoin, smart contracts will be a useful tool but not a silver bullet.

It’s my opinion that smart contracts will come to their greatest use — not by reorienting the way trades are conducted — but by creating cost cutting controls and ensuring regulatory compliance in real time through the use of clear business rules in a protocol. Currently, this enforcement is fragmented across compliance, trading platforms, and risk management in a bank.

*- These are not technically assets, they’re derivatives.

PART IV

Profiles of Protocols
The last eighteen months have seen a Cambrian explosion of blockchain / distributed ledger companies making their foray into financial services. With our basic grounding in what a blockchain is, the different consensus mechanisms it can employ, and the types of things they are good for, we will explore four companies with a critical lens.

Hyperledger
Hyperledger is built upon an algorithm known as Practical Byzantine Fault Tolerance (PBFT) developed in 1999, thus predating blockchains. It is a centralized algorithm relying on a set of trusted third parties, and has been the standard academic approach to developing distributed ledgers.

Participants using Hyperledger consent to allowing a fixed set of known participants be responsible for the ledger. Hyperledger also has a few “meta features”, like allowing the participants to vote in new participants and vote out old ones — but it’s unclear at what stage they are in for development.

There is no blockchain on Hyperledger; participants submit transactions to the network, and they get incorporated into the ledger. There is still a wait for consensus to emerge before the transaction is considered accepted, but the time should be in seconds, as opposed to Bitcoin’s 60 minute confirmation.

Ledgers maintained using Hyperledger are still auditable by individual participants. They may ask from one, or several, of the validating nodes to provide them with a historical list of all transactions, and use them to assess the validity of the ledger. While this is an expensive operation, it is no different than what validating a blockchain requires (with the minor exception that the Bitcoin blockchain has a pruning mechanism to make this audit faster).

Entries in Hyperledger represent basic operations such as creating an account, deleting an account, transferring amounts from one account to another, etc. Smart contracts are offloaded to third parties; basically they would have participants trust an arbiter to manually execute the contract and handle the result, thus contracts remain private.

Their target market is the settlement process, which they hope to make a “real time” operation in order to mitigate risk. Currently, they are working “with financial institutions, consortia of banks and start-ups to deliver solutions to mitigate settlement risk, reduce costs and delays across multiple financial instruments; from FX, Interest Rate Swaps, Securities, to correspondent banking.”
Source: “Consensus-as-a-service” by Tim Swanson. April 6, 2015.

Eris
Eris is a fork of the Ethereum protocol. Their most salient commercial goal is to facilitate companies to run their own blockchains as internal distributed databases. They were released in December 2014 and launched ahead of many other solutions in the space.

Their blockchain “stack” comes in a variety of flavors, centralized and decentralized, and boasts a high degree of customizability within Ethereum’s framework. Eris advertises their smart contract functionality, but also the ability to reconfigure their blockchain to serve as a central third party.

“Eris [likens] blockchains as database software — it will do what operators tell them. Eris views blockchain databases as rulebooks for data-driven interactions” — as we know, this is not the case. To characterize blockchains as merely a database software is to miss the point of the technology. Distributed Hash Tables, for example, have existed since 2001; they are databases, they are distributed. According to Eris, they should be the same as a blockchain, but they aren’t. Blockchains are necessary whenever the consensus cannot be formed individually by each participant. This is typically the case when a set, finite number of tokens, or assets need to be tracked.

Furthermore, Eris’s proposals for technical applications of blockchains have earned harsh criticism from CS experts like Nick Szabo and Emin Gun Sirer.
Source: “Consensus-as-a-service” by Tim Swanson. April 6, 2015.

Tezos
Disclosure: My husband and I developed Tezos in early 2014.
Tezos was developed in 2014 by financial professionals and a group of researchers affiliated with INRIA, the French Institute for Research in Computer Science and Automation. The company was created after their founder observed a misalignment of incentives and governance in most other blockchain solutions. By abstracting the concept of a blockchain and incorporating it into the protocol itself, Tezos proposes a unique, dynamic governance model which allows:

• Stakeholders full choice over the technological enhancements to the network.
• Solving important collective action problems like agreeing upon trading centers.
• The integration of new features into the protocol as first class citizens, which preserves scalability and composability. Tezos considers that this is a major advantage over solutions which implement new features within smart contracts, and not at the protocol level.
• Network participants can agree to use any form of consensus mechanism, be they decentralized, like Proof of Work or Proof of Stake, or centralized, like PBFT.

Another key difference between Tezos and many other blockchain solutions is their approach to contract security; most other ledgers require contract terms to be public by design. Thus, Tezos provides what they call “trustless off-chain contract arbitration,” which protects the privacy of the parties to the contracts (while retaining auditability for regulators) and greatly improves scalability.

A critical feature of Tezos’s smart contract capability is their unique smart contract language, which has full formal specification. This makes Tezos contracts very good candidate for formal verification, a process which mathematically guarantees the correctness of the code. Such a step is critical given the large amounts at stakes in derivative contracts.

One drawback of Tezos is that the network governance scheme works best in a consortium model of ownership among multiple different actors and, as it was introduced, does not work as well for private, internal use cases. Their target market is the OTC Derivatives space, which is highly fragmented.

Ripple
Ripple is a centralized, distributed ledger which can track debts and credits across a network of different nodes through their consensus protocol. They do not use a blockchain but rather leverage their open source protocol to maintain their distributed ledger.

Ripple creates a network of people with lines of credit. This means that everyone participating in the network is implicitly acting as a market maker. For example:

I gave a line of credit of $100 to Jack, and Zack gave me a $100 line of credit. Zack sends $50 to Jack, but they aren’t directly connected. So now, Zack owes me $50 and I owe Jack $50.

One way to see this is that I traded a $50 IOU from Jack for a $50 IOU to Zack.

Ripple tacitly logs these dynamics to create a network database. Banking operations often call this process ‘netting.’

A central feature of Ripple’s appeal and dynamism is its compatibility with any currency. To quote their website, “[a Ripple] user can hold balances in one currency, and send payments in another.” Ripple also has its own currency, XRP, which exists within the Ripple protocol. The currency is intended to act as a “bridge currency” in an IOU network. (The idea behind this is that, if every currency is liquid to the XRP, then the XRP is liquid to every other currency — creating a bridge between all sets.)

One potential vulnerability of Ripple’s objectives as a financial services company is its authority. Though Ripple aspires to simplify the settlement process, they aren’t a central authority like the Federal Reserve and can only represent lines of credits. Though their technology simplifies the netting process on a global scale, it’s not yet authoritative. (Note that this critique is valid across every solution which aspires to supplant the settlement process.)

(For curious minds, a good, brief overview of the differences between Ripple and Hyperledger can be found here: http://www.quora.com/How-is-Hyperledger-different-than-Ripple )

Part V

Drawbacks of Blockchains
In a commercial environment, blockchains can impose risks and costs. Some of these risks can be mitigated through design choices when choosing a protocol system, which is where our knowledge from the last four parts will come in handy!

Reorganization

• Blockchains can be subject to reorganizations. A reorganization, effectively, wipes out the record of transactions, and could replace it with another version. If goods and services are rendered based on a deleted history, there would be chaos in the marketplace. (This risk can be made very small, but it is present.)

Maintenance Costs

• Proof-of-Work blockchains, a popular type of consensus in cryptocurrencies, can be extremely costly to maintain.
• Blockchains can require a lot of disk space from the participating nodes — though not necessarily from the end consumers.

Latency

• Blockchains typically do not scale very well in terms of processing speed.
• Transactions can take a long time to be confirmed by a blockchain. Bitcoin exchanges typically require one hour, for instance.