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
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.
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.
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 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:
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.