Capitalist blocks — the economics of Bitcoin and blockchains, pt. 2

Second, the Micro perspective: blockchains, contracting and trust

In the first part of the story I focused mostly on some macro topics surrounding the use of Bitcoin (or any other cryptocurrency) as a means of payment. This second part I will dig deeper into the micromechanics of transacting with cryptocurrency and blockchains. I will try to keep this readable but some of the things I have to deal with are bit more technical.

Currency and trust

In the macro part I introduced the three standard functions of money: medium of exchange, store of value, and unit of account. Anyone who is considering using a certain currency — crypto or old-world — to conduct their business with has to put a modicum of trust into that particular currency. For our three basic functions, this trust comes in different shapes and intensities. In turn:

Medium of exchange: In order to be willing to accept bitcoins in return for a anything I sell, I have to trust that someone will take those bitcoins of my hands whenever I am out buying, hopefully very soon, and I have to trust that the bitcoins don’t lose value in between.

Store of value: To use bitcoins solely as medium of exchange, we assume that I quickly find someone who takes them off my hands. But it could also be that I want — or have to — hold those bitcoins for a longer time. For this to work I have to trust that someone will eventually, in the future, take the bitcoins off my hands. And I also have to trust that they didn’t only hold but actually increased in value — at least as much as I expect that my non-crypto money increases in value if I put them into a savings account.

Unit of account: Beyond using bitcoins (or any other crypto– or non-cryptocurrency) to trade or save, I might also want to record (and report) all my transactions in that particular currency. This activity is usually summarized in the much maligned word bookkeeping. Bookkeeping is a very staid and steady, forensic and meticulous profession, so a decision to keep ones books in bitcoin is a massive and momentous decision which requires the highest level of trust in the long-term stability of the currency. As of now I am not aware of any significant company that keeps its books in Bitcoin or any other cryptocurrency. A big reason for this is the very questionable legal status of Bitcoin, but the inherent volatility and uncertain future prospects don’t help either.

To create this rather forbidding amount of trust in the currency is a major obstacle to the mainstream adoption for Bitcoin, Ether, Dogecoin, or any other cryptocurrency — especially after the disastrous collapses of the Mt. Gox exchange (for Bitcoin) and The DAO venture fund (for Ethereum) — so there is a noticeable trend towards decoupling the underlying distributed cryptographic database — the blockchain — from Bitcoin and use it for other purposes.

Meet on the ledger

If in computer science terms the blockchain is a cryptographically secured, distributed database for recording cryptocurrency transactions, in economic (and also in bookkeeping) terms it is a ledger.

A ledger in the old-economy world is a big book, often expensively bound in leather. In old trading kontors it was often in a prominent position within the office to instill trust in the trader. The ledger is the book that records all transactions of a commercial entity, recording in chronological order. It is the main book (“das Hauptbuch”) that has to be handed over to the auditor, and if some crooked actor were to decide to cook their books, this would be the book to cook. So making clear that everything within the ledger is above board is of utmost importance to any honest merchant. Having an immaculate track record of past transactions is the way a merchant instills trust, and the ledger is the manifestation, and the outward sign, of this trustworthiness.

But there is an inherent conflict in this goal: while merchants have an incentive to make the ledger public, they also have an interest to keep the individual transactions private. In olden times merchants solved that problem by placing the bookkeeper prominently in the middle of the room, often on a pedestal, and by not letting anyone get to close to him.

The blockchain is the equivalent of the ledger in the cryptocurrency world: it tries to solve the trust–vs–privacy paradox by making the transaction amounts public but by hiding the transacting parties behind pseudonymous addresses, which can be frequently changed.

But the blockchain is also a distributed ledger, in the full sense of the term: just like anyone can read all transactions, anyone can — at least in principle — write into the blocks. This opens the door to all kinds of nefarious intents, and it is of utmost importance to slam that door tightly shut.

For that reason the blockchain is an encrypted distributed ledger: the complex usage of encryption does not only keep the transacting parties anonymous, it also underpins the integrity of the whole system in a zero-trust environment — or at least it tries to. The “block” in blockchain refers to a set of transactions that are encrypted together — think of it as the pages of a ledger book — and each block contains a reference to the previous block before it is encrypted. This way the auditors can make sure it’s turtles all the way down: a single block cannot be replaced later on without unraveling the whole chain. (This involves some serious encryption technology, most of which I’m skipping here to focus on the economics.) The blockchain as ledger becomes more and more immutable as it grows: like a lodger book would need to be rewritten as a whole if a past transaction is tampered with, the whole blockchain would have to be re-encrypted, which is increasingly impossible to do as the length of the blockchain grows.

Closing in — the micro perspective. Photo by Daria Tumanova on Unsplash.

Transactions and (not so smart) contracts

Let’s move away from the implementation of the ledger as a blockchain for a minute and focus on the building blocks for the blockchain, or for commerce in general: transactions and contracts.

Transactions are, most simply expressed, voluntary exchanges of items of value. To make this even simpler, normally we think of transactions as exchanges between two parties and involving the exchange of a tangible item — a product or service (combined in econspeak: “a good”) — for a payment. The part of the transaction entered into the ledger is usually only the payment.

Contracts then are voluntary exchanges of promises, or to stick with econspeak: of commitments. Simple transactions can of course be written into a full formal written legal contract, but such effort really only makes sense when there is a component of the future in the transfers, so I will use contracts only for that more complex scenario.

While Bitcoin in its inception is designed to capture the financial half of a transaction, in theory all kinds of things could be written into the blockchain, and many more recent cryptocurrencies and have captured this element, most prominently Ethereum with the concept of smart contracts.

The first thing one needs to understand about smart contracts is that they are neither. Maybe a better word for what they do is recipes, the word uses. Or “IFTTT” itself — If this then that — is a helpful description: simple algorithms that are self-executing after a predefined state has been reached.

The connection “smart contracts” to real contracts might not be self-explanatory, so let’s have a closer look at what defines a contract: for one the transaction itself (the transfer of promises or the signing of the contract) is only step 2 of contracting. Step 1 (“ex ante”) captures the search for a contract partner, the negotiation of the contract terms and the safeguards. Step 3 (”ex post”) captures everything that happens after the contract has been signed, including the fulfillment of the mutual promises, the monitoring of this fulfillment and, potentially, the renegotiation of terms.

The building blocks of trust relationships

Coming back to our original topic, the key thing that separates transactions from contracts is trust. Contracts are transactions involving promises, and in order to exchange promises we must either trust our contracting partner that they deliver on their promises, trust a higher authority (read: the government) to enforce the contract, or we must anticipate every single potential future scenario that might affect promise fulfillment and write it into the contract in perfectly unambiguous language. The effort spent on these things is what we call contracting costs (or more generally, transaction costs).

Writing very elaborate contracts in unambiguous language is highly cost-intensive, and anticipating every potential future scenario and contingency is nigh impossible. But relying on the government to enforce ambiguous contracts is almost always more expensive, since it involves legal threats, legal maneuverings, or in the worst case, lawsuits. So the ability to avoid both of these costs, the ex-ante costs of setting up complex contracts and the potential ex-post costs of resolving conflicts inamicably, is a massive advantage to any contracting partners. This ability is the result of a trust relationship: the ability of two or more partners to enter contracts without either of these efforts. And the central tenet of transaction cost economics is that those contractual standards will prevail that minimize transaction (or contracting) costs.

But Bitcoin was invented to work in a zero trust environment, so it is worthwhile to look at how exactly Bitcoin, Ethereum, and the blockchain create trust relationships out of a vacuum.

First, as mentioned before there are the safeguards against double-spending by capturing every transaction the semi-public, immutable blockchain. Second, there is the much less effective safeguard against inflation. These are just simple safeguards on the transaction level, so let’s look at the potential of smart contracts: One of the safeguards in old-school contracts is to write scenarios and contingencies into the written (verbal) contract and include language to the effect that if such a scenario happens, one or both contracting partners agree to take a predetermined action. Or in short: if this then that. Smart contracts — IFTTT recipes — attempt to make these ambiguous verbal safeguards watertight — by capturing them in computer code — and immutable by committing them to the blockchain. Their potential is then to drastically reduce contracting costs by offering a simple way to remove the ambiguity around contract writing and execution.

At this point, where we discuss verbal vs. computer-coded contracts, it might be useful to provide some historical context. The question of whether it is possible to establish unambiguous contracts or if they will always be ambiguous, no matter how they are encoded is at the core of two schools of thought within institutional economics, headed by two Nobel Laureates named Oliver. The first, UC Berkeley’s Oliver Williamson (NL 2009) is credited with establishing the field of transaction cost economics. The other, Harvard’s Oliver Hart (NL 2016), is a leading figure in contracting theory. Combined their work underpins much of this story. Their subject matters overlaps, as this story hopefully established, but their approaches are very different: Williamson’s is a purely verbal theory based on legal theories of contract. Hart sticks closer to the microeconomic orthodoxy of mathematical theory-building, which allows for tighter arguments, but it also simply assumes away the ambiguity of writing verbal contracts — or of the even more implicit unwritten social contracts. The partners are confronted with the true (mathematical) state of the world after the contract has been signed, and work backwards from there to find the optimal contract.

Ethereum and the “The DAO” breach

The cryptocurrency Ethereum, which explicitly facilitates writing smart contracts, became a field experiment for the two theories earlier this year. A special case of a smart contract is a distributed autonomous organization, or DAO for short. DAOs contain the code that allows, according to the intent of their founders, all the information needed to run a business, without incorporation or the administrative overhead that comes with incorporation. The organization runs itself.

By far the most successful DAO (in terms of money raised) was a venture fund simply called The DAO. The fund raised more than 150 million dollars in ether (the cryptocurrency unit of Ethereum) to allocate them to ideas — ideally DAOs themselves — that the investors voted on. In theory a very neat and unambiguous setup, but in practice more than a bit convoluted. Even before launch cryptography specialized warned of vulnerabilities within the code. And lo and behold just a few days after launch, an anonymous investor managed to exploit such a vulnerability to divert over $50 million worth of ether into an escrow position earmarked to be paid out to them a month later. This happened throughout the night and the investor community could do nothing but watch and despair.

Since the cryptocoins were held in escrow for thirty days, the Ethereum and The DAO core members had to make a quick decision. Either let the individual get away with it and risk that The DAO collapses due to lack of trust, or do a “hard reset” of the Ethereum blockchain — reach a consensus among miners to go back to the state of the blockchain ex ante and eliminate all transaction benefitting the exploiter. (Note the term “hacker” doesn’t apply here since no code was altered and no security factor was breached). The decision most miners agreed on — a consensus does not have to be unanimous — was to do the hard reset, and to let the founders of The DAO unravel the entity and reimburse all investors in full. This decision was made in full knowledge that the incorporating language of The DAO unambiguously stated that the programming code in itself was the only relevant document governing the allocation of investment funds — in any real world court the exploiter would have a strong case to receive the diverted funds.

No actual person has stepped forward since and posted any legal challenge to this consensus decision, so we don’t know how actual courts would handle it — indeed it wouldn’t be easy to decide on a jurisdiction or name defendants, even though interfacing organizations have been incorporated in Switzerland. So the final resolution is still up in the air, but even in the minds of those who have previously agreed — in general and in the specific case of The DAO — that code overrides verbal agreements, unwritten side agreements or even “common understandings” what an legitimate or illegitimate use of The DAO funds would entail, the near-unanimous consensus was that such an understanding exists and it overrides the actual code and the written language that the code is the governing document.

In contracting this is called reneging — short of renegotiating, which requires both parties (the exploiter and the community) to agree on a change in contract terms — and at this point the reneging was the agreement that verbal overrides algorithmic. A crushing defeat for Oliver Hart, a few months before he was awarded the 2016 Economics Nobel.

Where do we go from here?

Bitcoin has ostensibly survived the Mt. Gox failure, and it stands to argue that Ethereum will survive the The DAO collapse. Both have steadily (slowly but exponentially) increasing streams of daily transactions added to their blockchains, but they are for the foreseeable future fringe players. It is hard to give a ballpark number of total daily transactions conducted in global commerce, but as an estimate Bitcoin captures less than 1/2,000,000th of them. And while some mainstream corporations have announced to accept bitcoins, ether, or some other cryptocurrency, there is no known major player that does a significant fraction of their transactions in crypto.

Many big players in IT, banking and commerce are now looking into blockchains as a potentially useful database format but the major drawbacks of Bitcoin, including the low throughput, the volatility of the exchange rate with major non-crypto currencies, and the disastrous energy balance of Bitcoin mining, make most of them look at non-currency blockchain solutions, or “blockchain-related program activities”. This is a pity, as this two-part series tried to explain.

The blockchain is not a particularly good database structure, and its key inherent asset is the ability to bridge the gap between privacy: the individual incentive to not disclose particular things — and trust: the community’s interest in easily accessing particular things. If these things are not the same things but are commonly stored together (transaction partners — undisclosed — and transaction amount — disclosed), the blockchain is a strong vehicle for reducing contracting costs. Giving up on the cryptocurrency part means resorting to more exclusionary mechanisms to control write access (and potentially read access too) like blockchain cartels (also erroneously called consortium chains). Exclusion means loss of trust, and removing the cryptocurrency component might simply make the blockchain a pointless exercise in pointlessness because all you’re left with is an awkward database structure stripped of its key value proposition, the trust environment.

On the other hand, anyone who is able to solve that puzzle might be the winner of the high-stakes race for the blockchain standard implementation. More on this in a potential part 3…