I often see the question “what does a blockchain solve?” Other times, blockchains are presented by critics as solutions in search of a problem, or that the ideas that blockchains aim to solve are simpler to achieve with a typical private database. I think it’s worth analyzing this, to understand the fundamental properties of a blockchain that distinguish it from other solutions.

At its core, you can imagine a blockchain as a list of records; a ledger that is append-only and, once written to, rather impossible to change. The state of this ledger is distributed across nodes in a network, and participants come together via a consensus mechanism to collectively agree on the current state of the ledger. These systems are typically designed with cryptographic proofs so that, ideally, transactions are secure and verifiable.

There are many different blockchains that aim to solve these problems in different ways, but they often provide certain features that are unlike standard databases. Many aim to be: public, decentralized, secure, permissionless, and verifiable. To use a simple analogy, imagine a public and collaborative Google Sheets document that has a growing list of records. Each record has a timestamp, and indicates the amount of “tokens”—which hold some value in the network—that were sent from user A to user B, with an optional message.

Unlike a traditional Google Sheet, the blockchain aims to be decentralized and effectively ownerless: no single user manages the ledger, or even hosts the data, as it is distributed and secured across many nodes. It is also public and permissionless in that any user can freely view and, for a small fee, append to this ledger—network operators have no simple way to collectively prevent a user from writing to it. Transactions are verifiable, relying on cryptographic techniques so that all users in the network can validate and cryptographically prove each record, allowing us to say with a high degree of confidence that “John really did send Bob 1 token.” The network also aims to be secure, ensuring users cannot create frauds (such as sending more tokens than they own) and that previous records cannot be altered without dismantling the entire chain.

All of this, if it were to work correctly, is somewhat interesting and solves certain problems within the niche context of “how can you create a public ledger that is global, secure, and decentralized.” This is a worthy goal, and these peer-to-peer networks stand in contrast to centralised approaches built on private ledgers and transactional systems controlled by a “trusted” few parties (such as for-profit enterprises like Meta, Apple, and PayPal). Being a globally shared ledger, it also stands in stark contrast to systems of transaction that build upon a central bank, like the United States dollar.

Yet, this distributed ledger may not seem that interesting, if all you can do is store value in the form of tokens, and occasionally transfer them to other users inside the network. What I’ve described so far broadly describes the Bitcoin protocol, and perhaps explains why myself and many others have not really been that interested in this technology the last several years, as our goals have not been to dismantle the state or seek deflationary stores of value.

Programmability

Perhaps the most interesting development in this space, and how I came to be more excited about these ideas last year, is programmability, which enables application-level development on top of these distributed systems. Unlike Bitcoin, the Ethereum blockchain was built on the premise that users can not only append transactions to the ledger, but also programs—pieces of software, written with code, that are executed and secured in the same distributed manner as the rest of the chain. These smart contracts have enabled a range of new applications and opportunities that are, in some ways, profoundly different from what we have seen before.

To give a concrete example, let’s imagine a decentralized escrow. An escrow agent is typically a trusted third party that holds some amount of currency or goods on behalf of two or more parties, and manages the funds in accordance with the terms that have been laid out and agreed upon by all parties.

For example, if you wish to purchase an expensive domain name (like “art.com”) directly from another individual, you may not wish to send them the funds until they transfer ownership of the domain to you. Likewise, the seller may not wish to send you the domain name until they have received your payment. Escrow agents are sometimes used to manage these sales, where you instead send the funds to a mutually trusted third party, who then instructs the seller to transfer ownership of the domain name to you. Once the domain is received, the escrow agent will release the funds to the seller, finalizing the sale.

This already works with online services like Escrow.com and others. But, these are run by for-profit companies, take a significant percentage of the sale price, require weeks or months to settle, and must be constantly and carefully regulated by any states they may be registered in. If you live outside those states, you may find challenges using the services, such as additional currency conversion fees, a lack of regulatory safety net provided by your government, or simply an inability to use them at all. If the prices exceeds certain quotas set by the escrow agent, then settlement may take longer, require audits of user’s private information, and additional fees paid to the escrow agent.

Whereas a programmable blockchain could be used to describe a decentralized escrow agent in the form of a smart contract. This contract would take no fees, and the funds held in escrow would not be in control of any single party. Settlement time would happen in seconds or minutes rather than months, and there would be no need for expensive currency conversions, constant regulation and audits by each state, private information sharing with a third-party company, and dependence on for-profit enterprises to manage these deals for us. Once a smart contract is deployed on Ethereum, the code cannot be altered, and so consensus can be built around its uniquely addressable hash.

More broadly, protocol standards could be defined on top of the network, establishing a common set of rules and interfaces for a wide variety of types of escrow services—auctions, atomic transfers, crowdfunds, and more. This could become the backbone for easier, more composable, and safer interfaces and interoperability surrounding this kind of functionality (the same happened with the NFT/ERC721 protocol standard, enabling a richer ecosystem of tools and applications to build around these types of contracts).

You can see a real-world example of an escrow contract here.

Problems

The above describes the ideals of these systems, and answers some questions around what problems does this solve, but there are of course trade-offs and new problems that emerge from such a system:

• The system only operates on digital constructions defined by the network; i.e. you cannot use this to securely transfer a physical real-world good.
• The system requires technical knowledge, hardware, software, and internet access. You cannot simply ask your bank teller to transfer funds to an escrow contract.
• The system requires that the two parties have already bought-in to a particular crypto currency and are using it.
• Blockchains typically cap network bandwidth to maintain their overall security; this limited blockspace and high demand often leads to prohibitive transaction fees to ensure the transaction will be written into the blockchain by the node operators.
• The system must be upheld by a consensus mechanism that may have negative externalities, such as extremely high energy usage in Proof of Work.
• The contract code may have a bug or flaw, leading to lost or stolen funds.
• The system has no concept of humans—only wallets—and so certain applications may be vulnerable to concerns like Sybil attacks.
• The system itself may not be suitably decentralized if too much power over its consensus mechanism is in the hands of a few people or a few nodes.
• The way in which you interact with the contract may not be secure, such as through an untrusted RPC endpoint, frontend application, or wallet.
• In practice, developers who build these contracts often like to be paid for their services, which may include running web or native interfaces atop these contracts and/or providing customer support, i.e. leading back to fees and centralized silos.
  • A dramatic example of this can be seen in the context of art galleries and auction houses, where a 40-60% cut of the artist’s sales are rather common. On the other hand, crypto art marketplaces such as Foundation, ArtBlocks, OpenSea, and Hic Et Nunc range from 1-15%.
  • Platforms like Uniswap aim to further reduce centralization by directing fees toward governance token holders (i.e. a permissionless group of users whose incentives may be aligned with upholding the overall health of the platform).

Applications

The space of these applications is quite nascent, having only been around for several years, but various novel applications have begun to emerge on top of blockchains like Ethereum:

• Multi-signatory wallets, so that funds can only be transferred if a majority of signers agree to the transaction by signing with their private key.
• Cryptographically verifiable scarcity, such as having a token that can only exist in one user’s wallet at a time. Duplicating the token is not possible, as it would lead to a new addressable hash. This is the basis for NFTs.
• New modes of escrow and crowdfunds that may securely operate across hundreds of thousands of users worldwide, with near-instant settlement times and low fees.
• Decentralized finance tools such as lending and borrowing.
• Decentralized exchanges that allow trading one token (i.e. “currency”) for another.
• Stablecoins that algorithmically peg their value to mitigate price volatility.
• Decentralized Autonomous Organizations (DAOs) that aim to distribute organization and governance amongst participants (however successfully or unsuccessfully they do this).
• Applications such as NFT and crypto art: allowing creators to be paid for distribution of a signed token, perhaps even earning royalties in perpetuity on each secondary market resale.
• Payment splitting: such as a charity auction of an NFT that splits payment evenly across 50 beneficiaries, without these funds even touching the seller’s wallet.
• Decentralized name services such as ENS.
• Decentralized applications that take advantage of zero-knowledge proofs, such as a contract that executes a trade only if the user shares a proof (without requiring them to share any private information associated with that proof).

Many of these fall into the same set of problems as before, and are generally only useful if you place value in that network. If you believe that cryptocurrency networks are hogwash, it can be easy to dismiss the entire field of study as imaginary internet money—despite some of the interesting applications that are beginning to be built and used within these networks, and the real-world positive externalities they are enabling.

This has been a pretty broad and high-level overview. In a future post I might like to break down ERC721 and similar constructs, to analyze some of the the technical underpinnings of the crypto art and NFT scenes that exploded in 2021.