Member preview
Loading…
0:00
18:00

A map of Manhattan and Wall Street in 1661. Like “New Amsterdam”, blockchains are still just getting started.

The Blockchain Primer That George Washington Would Understand

Blockchains. Decentralized protocols. Distributed ledgers. Cryptographic hash functions. Consensus algorithms. The sheer amount of terminology around cryptocurrencies can make you feel like someone transported in time from the 18th century. Not only are you trying to familiarize yourself with some of the more mind-bending concepts in computer science, but you also have to deal with a great dose of economics jargon.

Blockchains are bringing together two opposites of the scientific mindset, which may initially seem to be at odds with each other. On one side of the ring, we have the extreme unforgiving rigor of cryptography: a math-heavy branch of computer science that used to be the exclusive domain of dusty academics. At the other side of the ring stands the brash superstar of social sciences, the economist; ready to pounce, competitive, possessing what some would describe as an abrasive personality. In this situation, however, opposites attract! When two such discrete sciences meet, there is unique opportunity in the air — but also ample room for misunderstanding and misdirection by bad actors.

So what is that makes the blockchain unique? A marriage of economics and cryptography, ok — but is it all just about a technological solution? If you read online discussions, you may find that most participants are very caught up in high-pitch debates involving the merits of exceptionally specific details of blockchain implementations. Getting the big picture is not easy.

Fundamentally the most important part of blockchains is not algorithms, nor cloud servers, nor user interfaces — it’s people. More specifically: it’s about accountability between people. This is a concept which is closely related to trust, yet narrower because trust comes in so many forms. For example, trust in a marriage is something that typically is not built on accountability — your wife, husband, or partner doesn’t expect you to file precise reports of everything you did during an average day. Hence marital trust is not something that seems very amenable to a blockchain-based solution, or a technology solution in general. (Of course, if you think you have a viable project concept here, disregard this example and go for it! The market would certainly be enormous.)

Accountability has sparked financial revolutions before. The modern accounting system of double-entry bookkeeping was widely adopted in Italy in the 13th century, and it became a crucial foundation of the economic and creative boom in Western Europe during the Renaissance. In Florence, a man named Giovanni de’ Medici founded a bank on the rigorous principles of the double-entry bookkeeping system. His son Cosimo became the ruler of Florence, and three generations later one of Cosimo’s great-grandsons became Pope Leo X, the highest office in Europe at the time. This is pretty good for a dynasty built on Giovanni’s astute understanding of an accounting innovation!

Most applications of modern information technology in corporations are evolved descendants of the medieval Medici Bank’s operations: maintaining databases, recording transactions, and storing the details of who did what and how other accounts were affected. In accounting terms, these systems are ledgers. How is a blockchain different from what goes on in a corporation’s IT systems already? How does a blockchain enable new forms of accountability between people?

The keyword is decentralization. Whichever previous system you consider — the Medicis’ handwritten ledgers stored in volumes of books, a present-day bank’s IBM mainframe, or even the cluster of replicated cloud servers you might find at a more forward-looking corporation today — you’ll discover that there is a single source of truth. Someone is authorized to perform operations on the accounts, and that “truth” is stored in all copies of the information. No matter how many cloud servers are used to provide resiliency in case a system goes down, inputs to the system are centralized — there’s ultimately an authority that says, “this data comes from a reliable source, it’s approved to be recorded in our system”.

The blockchain is not like those traditional ledgers with a single input for truth. It is a distributed ledger — a term you will hear often in blockchain discussions. When there are multiple inputs, a single gatekeeper can’t decide what truth “sticks” in the permanent ledger, so there is the need for consensus — another term that you’ll encounter frequently.

To better understand distributed ledgers and consensus, let’s step back entirely from the context of computers and digital systems, and look at a historical example. Imagine yourself in New York in 1750! You’ve just stepped off a ship that brought you all the way from London, a three-week journey across the Atlantic. Rough seas, bad food, foul-smelling fellow passengers — you’re happy to be back on solid ground.

As it happens, you are a rich man. In your pocket you have a bill of considerable value: a money order for one thousand pounds from one of the most respected banks in London. The bank’s name is well known even in the most remote English colonies, and your note carries the official stamp of their London branch. In New York, you immediately seek out a wealthy trader whose company has a formal association with the London bank. The bank provides the trader with a credit line back in England, and in exchange the trader has made a pledge that he will accept the bank’s money orders in New York and cash them out.

The trader never expected someone with your kind of wealth to walk in with a money order in hand, though. Cash is scarce in the colonies. The trader keeps perhaps 50 pounds’ worth of gold in his office. Cashing out a thousand-pound money order is an operation that will take weeks, or even months, to execute. He’d very much like you to just go away and take your money order somewhere else, but he’s bound by the contract made with the London bank.

How does this turn out? How can the trader know whether your money order is valid? How can you prove its validity in despite the trader’s obvious desire to not give you the cash? It’s a scenario that asks core questions about accountability between people. (By the way, it is also the plot of the novel “Golden Hill” by Francis Spufford. If you like the concept, check it out!)

At the bank in London, there is a ledger that proves your account contains a thousand pounds. The trader doesn’t have a copy of those books, though, and requesting proof across the Atlantic will take months. How to distribute the information in that ledger without having to send letters back and forth at every request? There are two ways.

First, you could send the same information through multiple routes. In fact, this is what the bank and the trader have agreed to do. For any money order, the bank will send a second copy of the bill on another ship, entrusted to the ship’s captain personally. When (or if) the second ship arrives and the captain appears at the trader’s office to vouch for your bill with another stamped copy in hand, the trader will most likely accept its authenticity. In that case consensus has been achieved.

Another way to distribute the ledger would be to send cryptographically verified bills. This was feasible — though admittedly not common practice — even with 18th century technology. The bank and the trader could have shared a code book when they originally met in London. Using the code book, the bank would insert a message into your money order that could only be decoded by someone who has a copy of the code book.

The problem with this approach is that you’d have to trust the trader when it comes the verification of the money order. He doesn’t really want to pay you the thousand pounds, so even if your order’s coded message verifies, what’s stopping him from lying to you about it?

Ideally you’d have both. The bank would use cryptography to make their money orders verifiable by the recipient, and they would also use consensus by sending a copy of the data by a trusted party — in this case the second ship’s captain who was paid by the bank to lend his authority to the order’s copy.

Flash forward 250 years. It doesn’t take two months to send a message and get a reply across the Atlantic anymore, but the problems of sharing ledgers and trusting accounts haven’t gone away. Now that sending messages themselves is nearly instantaneous even across oceans, the issue is the great number of participants, all busy with various trades. Our 1750 scenario had just four people — you, the bank, the trader, and the second ship’s captain. The trader received only a handful of money orders a month, so he could dedicate time to resolving the transaction. Today we have billions of people each doing potentially hundreds of transactions daily. Who are the gatekeepers of all this? Who owns the ledgers and decides who gets an account in them? Who decides that, say, someone in a particular country is forbidden from participating in the global financial system due to political events that took place before the person was even born? What kind of alternative systems could we build without the previous set of assumptions?

The blockchain allows an opportunity to explore those questions outside the structure of the established systems that have a single source of truth. It combines two features we already saw in the 1750 scenario — consensus and cryptographic verification — and puts them together in a novel way to create a truly decentralized system where multiple actors can be sources of truth, and they have shared incentives to arrive at a single truth which then gets permanently recorded by everyone. Those “truths” are stored in uniquely identified blocks, and the permanent, mutually agreed record is a “chain” where every block points to the previous one so the order can’t be tampered — hence blockchain.

Although our examples so far have dealt with transferring money, remember that this is really about accountability between people. The accounts and values represented on the distributed ledger do not necessarily need to represent a currency transaction. They can consist of basically any situation where one party (or several) acknowledges a fact about another party on the network.

In practice, the facts you’d want to store on a blockchain divide primarily into two categories: ownership and promises. What exactly a particular blockchain supports depends on its protocol.

The first widely deployed blockchains only concerned themselves with a single type of value (or asset), the accounts containing those values, and the records of transactions between those accounts. Bitcoin is the flagship example of this type of “value-store” blockchain. To put it another way: the Bitcoin protocol doesn’t let you do anything with your account’s Bitcoin balance except transfer it to another account. The Bitcoin ledger records ownership and that’s it.

There are many other blockchain protocols that are concerned with the second category mentioned above which we called “promises”. Think of a simple non-monetary exchange: maybe you buy us coffee and we promise to clean your apartment later. (We’re desperate for coffee!) That’s not exactly ownership — you don’t own a cleaned apartment — but it is a promise that could be stored on the blockchain so that you can hold us to it. These kinds of simple promises are often tokenized, that is, turned into an asset category that can be traded and owned on the blockchain. If we gave you the same promise in the form of a generic “apartment-cleaning token”, you could then sell it to, or trade it with, someone else on the blockchain and we’d have an undeniable agreement that we are now obligated to clean the apartment of that third person instead.

An advanced form of promises is called smart contracts. With these, you can essentially ask the blockchain deep questions and hold the participants to some behavior that is automatically applied by the blockchain itself. For example, we could promise to clean apartments for the first ten people who buy us coffee today. As coffee gets offered, our “apartment-cleaning token creator” smart contract would get executed to generate up to ten tokens — but no more than ten, and only today. Those limits are enforced by the smart contract definition which is automatically processed by the blockchain participants. Since the smart contract is encoded on the blockchain, the rules are visible to all and cannot be changed, so we can’t later decide to make changes unilaterally even if we wanted to get out of this promise to clean ten apartments.

There is also a special kind of ownership that can be represented on a blockchain which links other kinds of digital data into the blockchain’s world of cryptographic truths. It revolves around the concept of a hash value. A “hash” is like a fingerprint represented by a short sequence of numbers that is guaranteed to be unique, which can be computed for any kind of digital content. You could take this text and calculate its hash, or an entire Windows install disk, or a digitized copy of a Beatles album — all those, and anything else in digital form, can be condensed down into a single hash. Hashes are “one-way”: you can’t reconstruct the data from the hash, and neither can you come up with invented data that would fit a particular hash.

This latter property of hashes turns out to be very useful. By computing a hash and publishing it, you can prove the existence of some data right now, without exposing any potentially proprietary details, so that you can refer to this record of the data later. A patent makes a great example because there could be legal disputes regarding who invented something first. When you’re preparing to file for a patent, you could save a draft explaining the invention and publish that text’s hash on a blockchain. If there is ever a dispute later, you’d be able to prove your invention date by publishing the draft text and showing that it matches the hash that remains stored on the blockchain. It’s not possible to forge a text later that would match the hash, so this is solid proof that you had the invention written down when the hash was published. Hashes are extremely important to how many aspects of blockchains are implemented, so you’ll encounter the term in many contexts.

Remember how it was mentioned earlier that the Bitcoin ledger just records ownership of the coins created on the network? Strictly speaking there is a “loophole” in the Bitcoin protocol for tucking small amounts of other data within transactions, and this loophole is just large enough to put a hash value there. So, you could even use the Bitcoin blockchain to save your digital ownership fingerprints. It is worth noting that you’d pay the Bitcoin transaction fee each time, which currently equal to about $1 USD.

In practice you’d be better off using a different protocol, specifically one that’s explicitly designed to store this kind of data cheaper and more efficiently. Still, this Bitcoin transaction loophole is an illustrative example of how a blockchain really is just a shared record of facts, and those facts can be anything that the protocol lets you store and access.

There are two features that are commonly associated with blockchains, yet are actually implementation choices and not inherently required by the concept. They are mining and anonymity. Maybe you’ve seen stories in the press about how Bitcoin mining now consumes more energy than the entire country of Denmark, or how Ethereum mining has fueled such demand for high-end GPUs that it’s nearly impossible to buy a graphics card for your gaming PC. These are highly visible side effects of a choice that was made by the Bitcoin and Ethereum blockchain protocol designers. They both acquire consensus through “mining”, which means that blockchain participants will have their computers perform complex computations that are useless in and of themselves but verifiable by others, all while processing transactions, and for that work they get rewarded in coins on the blockchain.

This kind of consensus-building is called Proof of Work (POW). It’s a very clever way to ensure that a blockchain with an arbitrary number of participants who don’t know each other can still reach consensus. As long as there’s not a single party doing more than 50% of the mining, this approach guarantees fairness. Its downside is energy consumption due to the work which is useless in itself since each of those computations don’t have any meaning other than verifying transactions. There are other approaches, in particular Proof of Stake (POS).

To get better understanding of the issue, let’s quickly refer back to the 1750 scenario: what kind of consensus was used there? The second ship’s captain provided a copy of the money order and vouched for its authenticity on his honor, so we could call this approach Proof of Authority. It’s an illustrative example of an “old world” way of solving the same problem, but the whole point of blockchains is to be independent of centralized authorities, so we don’t commonly see Proof of Authority used there.

The other feature mentioned above — often associated with blockchains but not inherently required — is anonymity. Accountability between people is independent of whether those people can identify each other. Some blockchains are explicitly designed to hide participants’ real-world identities which can be useful for a wide range of things from avoiding state censorship to selling illegal drugs. Others are explicitly designed to provide verified personal identities e.g. for storing real estate deals on the blockchain. Most blockchain protocols actually fall somewhere in the middle on the anonymity spectrum. For example Bitcoin seems anonymous on the surface, but tracing transactions back to real identities is often not as difficult as it appears. In other words, you probably shouldn’t count on the IRS or your local tax office being totally ignorant of Bitcoin sales.

—

This concludes the gentle introduction to blockchains. Admittedly there were a couple of unexplained terms like “computer” that, if you were George Washington, would probably confuse you. (But if you are George, go check out your monument in the American capital — they put up a giant obelisk for you! Crazy, right?!)

If you are not a time traveller and still found yourself confused, please write a comment and let’s sort it out! Thanks for reading all this way.

(Thanks to Sydney Rose for invaluable comments and editing on this post.)

Like what you read? Give Pauli Olavi Ojala a round of applause.

From a quick cheer to a standing ovation, clap to show how much you enjoyed this story.