What a blockchain is
A blockchain is a shared record, a ledger, that many independent computers keep copies of and agree on without a single owner in charge. New entries are grouped into blocks. Each block includes a fingerprint of the one before it, so the blocks form a chain, and altering an old entry would change every fingerprint after it. That makes tampering easy to detect.
The goal is a record that parties who do not fully trust one another can all rely on, without relying on one company or authority to maintain it. That goal, and the costs of achieving it, explain nearly everything else about the technology.
This article is educational. It is not financial or investment advice, and it does not discuss prices or which assets to buy or avoid.
The building blocks
Hashes
A hash function turns any data into a fixed-length fingerprint. The same input always gives the same output, but a tiny change in input produces a completely different result, and it is impractical to work backwards from the fingerprint to the input. Hashes link the blocks and make changes visible.
Digital signatures
Participants hold a pair of cryptographic keys: a private key kept secret and a public key shared openly. Signing a transaction with the private key proves it came from the key’s holder, and anyone can check the signature with the public key. This is why losing or exposing a private key is so serious: whoever holds it can act as you, and on many systems transactions cannot be reversed. Good key handling follows the same ideas as API key secrecy and password managers.
Transactions and blocks
A transaction is a signed request to change the ledger, such as moving an asset from one account to another. Pending transactions are collected, checked and bundled into blocks.
Consensus
With many copies of the ledger, the network needs a way to agree on which block comes next. Mechanisms differ.
- Proof of work. Participants compete to solve a computing puzzle, making it costly to rewrite history. It uses a lot of energy by design.
- Proof of stake. Participants who lock up value are chosen to propose and validate blocks, and can lose it for cheating. It uses much less energy, with different trade-offs.
- Permissioned approaches. A known group of organisations validates the ledger, which is simpler and faster but less open.
No mechanism is best for everything. Each trades off openness, speed, cost and security.
Public and private chains
Public blockchains let anyone join, read and often take part in validation. Private or consortium chains restrict who can participate. Public networks suit situations without a trusted central party; restricted ones suit groups of organisations that know each other but want a shared record. If everyone can be trusted to use one organisation’s database, a blockchain adds little.
Smart contracts
A smart contract is a program stored on the blockchain that runs automatically when its conditions are met. A simple example is “release this payment when both parties confirm delivery”. Because the code and its results are recorded on a shared ledger, everyone can check what it does.
Important caveats:
- The name overstates things. A smart contract is code, not necessarily a legal contract, and its legal standing varies by place.
- Code runs exactly as written, including its bugs. Mistakes and security flaws in contracts have led to serious losses for others in the past, and deployed code can be hard or impossible to change.
- Contracts cannot see the outside world directly. To use real-world information, they rely on outside data feeds, which become a point of trust.
- Running them usually costs fees, which vary with network demand.
Development in this area therefore stresses careful design, extensive testing, independent review and starting small. The habits described in automated testing and version control apply with extra force when mistakes cannot easily be undone.
What development involves
Blockchain development is a mix of ordinary software engineering and some specialised skills.
- Application code that talks to the network, often through standard web APIs.
- Contract code written in languages designed for particular platforms, whose tooling changes often.
- Wallet and key management for users.
- Testing on test networks, which use valueless tokens, before anything real is at stake.
- Monitoring and a plan for what to do when something goes wrong.
Check each platform’s current documentation, since tools, languages and best practices evolve.
Where it fits, and where it does not
Possible good fits are situations where several parties who do not fully trust one another need a shared, tamper-evident record, there is no obvious neutral operator, and the need for an audit trail justifies the cost. Some supply-chain records, shared registries and certain settlement systems are examples people explore, with mixed results in practice.
Often a poor fit are cases where one organisation controls the data and a conventional database would be faster, cheaper and simpler. Choosing between SQL and NoSQL databases is usually the better question. A blockchain is slower, uses more resources and makes errors and privacy harder to handle. Data stored on a public chain can generally not be deleted, which clashes with privacy rules that give people a right to erasure. Storing personal data on a public ledger is usually a bad idea.
Questions before you build
- Who needs to trust the record, and why can they not rely on one party?
- Would a normal database with good logging solve the problem?
- What happens if a key is lost or a contract has a bug?
- What data will be public, and is that acceptable?
- What are the running costs and the legal obligations in your area?
Be sceptical of claims that blockchain automatically makes something secure, transparent or efficient. It offers a particular set of guarantees at a particular cost, and the honest question is whether you need those guarantees.