TECHNOLOGIES

Blockchain

A shared, append-only ledger that a network of computers agrees on without a central operator. Nobody can quietly edit the history.

Last reviewed: byKevin Riedl wiki ↗

A blockchain is a database with two unusual properties. First, it is append-only: you can add records but you cannot rewrite the ones already there without every participant noticing. Second, no single party controls it. A network of nodes runs the same software and agrees on the next block through a consensus mechanism (proof-of-work, proof-of-stake, or a permissioned variant). The result is a ledger multiple parties can trust without trusting each other.

There are two broad kinds. A public blockchain (Ethereum, Bitcoin, Solana) is open: anyone can read it, run a node, or transact, and it is where smart-contract systems and the broader web3 stack live. A private or permissioned blockchain restricts who participates, which usually means you have rebuilt a slower, more complex version of a normal database with extra steps. If one company controls all the nodes, you do not have a blockchain advantage, you have a distributed system you now have to operate.

Worked example of the question that settles it: a logistics company wants a blockchain “so partners can trust the shipment data”. Walk the three tests. Do the records need to survive the company going bankrupt? Not really, the company is the one running the network. Do mutually distrusting parties need to share state without an operator? Closer, but in practice one party is clearly the hub and everyone connects to it. Do they need permissionless composability with other on-chain systems? No. So what they actually want is a well-permissioned shared database with an audit log and signed entries, which is cheaper, faster, and something their existing team can operate. The blockchain pitch was solving a trust problem that a signature and a read replica already solve.

The honest stance: most projects pitched as needing a blockchain do not. A blockchain earns its complexity only when you need assets that survive the operator’s bankruptcy, shared state between parties who do not trust each other, or permissionless composability. Everything else is a database. When a public chain is the right call, fees and throughput usually push the build onto a Layer 2 rather than the base layer. We have shipped real blockchain systems and we have talked clients out of more than we built. Our blockchain work starts with whether you need one at all.

// FAQ

FAQs

A shared ledger that many computers keep a copy of and agree on through consensus, so no single party can rewrite history. It trades speed and simplicity for the ability to operate without a trusted central authority.
Public chains give you censorship-resistance and permissionless access at the cost of fees and transparency. Private chains drop those benefits and usually end up as a slower database. If one entity controls the nodes, a normal database is almost always the better engineering choice.
Three tests: must assets survive the company’s bankruptcy, do untrusted parties need shared state without a central operator, do you need permissionless composability? If none apply, you need a database, not a blockchain.