You Don't Need A Blockchain

you-dont-need-a-blockchain.md

You don't need a blockchain.

If you're reading this, you probably suggested to somebody that a particular technical problem could be solved with a blockchain.

Blockchains aren't a desirable thing; they're defined by having trustless consensus, which necessarily has to involve some form of costly signaling to work; that's what prevents attacks like sybil attacks.

In other words: blockchains must be expensive to operate, to work effectively. This makes it a last-resort solution, when you truly have no other options available for solving your problem; in almost every case you want a cheaper and less complex solution than a blockchain.

In particular, if your usecase is commercial, then you do not need or want trustless consensus. This especially includes usecases like supply chain tracking, ticketing, and so on. The whole point of a company is to centralize control; that's what allows a company to operate efficiently. Trustless consensus is the exact opposite of that.

Of course, you may still have a problem of trust, so let's look at some common solutions to common trust problems; solutions that are a better option than a blockchain.

• If you just need to provide authenticity for a piece of data: A cryptographic signature. There's plenty of options for this. Learn more about basic cryptographic concepts here.
• If you need an immutable chain of data: Something simple that uses a merkle tree. A well-known example of this application is Git, especially in combination with signed commits.
• If that immutable chain of data needs to be added to by multiple parties (eg. companies) that mutually distrust each other: A cryptographically signed, append-only, replicated log. Chronicle can do this, and a well-known public deployment of this type of technology is Certificate Transparency. There are probably other options. These are not blockchains.
• If you need to verify that nobody has tampered with physical goods: This is currently impossible, with or without a blockchain. Nobody has yet figured out a reliable way to feed information about the real-world into a digital system, without allowing the person entering it (or handling the sensors that do so) to tamper with that data.

Some people may try to sell you one of the above things as a "blockchain". It's not, and they're lying to you. A blockchain is defined by its trustless consensus; all of the above schemes have existed for way longer than blockchains have, and solve much simpler problems. The above systems also don't provide full decentralization - and that is a feature, because decentralization is expensive.

If somebody talks to you about a "permissioned blockchain" or a "private blockchain", they are also feeding you bullshit. Those things do not actually exist, and they are just buzzwords to make older concepts sound like a blockchain, when they're really not. It's most likely just a replicated append-only log.

There's quite a few derivatives of blockchains, like "tangles" and whatnot. They are all functionally the same as a blockchain, and they suffer from the same tradeoffs. If you do not need a blockchain, then you also do not need any of the blockchain derivatives.

In conclusion: blockchains were an interesting solution to an extremely specific problem, and certainly valuable from a research standpoint. But you probably don't have that extremely specific problem, so you don't need and shouldn't want a blockchain. It'll just cost you crazy amounts of money, and you'll end up with something that either doesn't work, or something that has conceptually existed for 20 years and that you could've just grabbed off GitHub yourself.

---

Additions

I'm going to add some common claims here over time, and address them.

"But it's useful as a platform to build upon!"

One of the most important properties of a platform is that it must be cost-efficient, or at least as cost-efficient as the requirements allow. When you build on an unnecessarily expensive foundation, you can never build anything competitive - whether commercial or otherwise.

Like all decentralized systems, blockchains fail this test for usecases that do not benefit from being decentralized, because decentralized systems are inherently more expensive than centralized systems; the lack of a trusted party means that work needs to be duplicated for both availability and verification purposes. It is a flat-out impossibility to do less work in an optimal decentralized system than in an equivalent optimal centralized system.

Unlike most decentralized systems, blockchains add an extra cost factor: costly signaling, as described above. For a blockchain to be resiliently decentralized, it must introduce some sort of significant participation cost. For proof-of-work, that cost is in the energy and hardware required, but any tangible participation cost will work. Forms of proof-of-stake are not resiliently decentralized; the cost factor can be bypassed by malicious adversaries in a number of ways, meaning that PoS-based systems aren't reliably decentralized.

In other words: due to blockchains being inherently expensive to operate, they only make sense as a platform for things that actually need trustless consensus - and that list pretty much ends at 'digital currency'. For everything else, it is an unnecessary expense and therefore a poor platform choice.

It's still not trustless and not immutable, which to me is a requirement for any decent digital voting system that wants to be used for things other than a Telegram poll or any other trivial thing. Any centralized and mutable voting system is not good enough, to me.

The full list of results is published, with the registered vote. So the result is visible, the total amount of possible-votes is known and thus everyone can check that the counting is done properly.

With a blockchain and a smart contract, you wouldn't need all of this. If you want, you can check the SC code once, and you're done, as long as you use that SC for any future voting session, you are sure the process is going to be carried out in a certain specific way, and it cannot be done otherwise (i.e. you check the process instead of the outcome).
It also adds A LOT to the whole transparency of the process, which as a voter myself is a BIG plus.
Immutability is also a requirement for voting. You wouldn't want anyone rewriting the history of a voting process, and possibly your vote, wouldn't you?
Plus, my vote HAS to be totally private. There's a way to do so on a blockchain (though it isn't a blockchain-specific thing), with ZK proofs. I can cast a vote and no one would know what I voted for, even if they had my voting address. Still, I would be able to demonstrate that I cast a vote without disclosing it, achieving trustlessness in the process, the immutability of my vote, and total privacy while voting (even from the comfort of my home). Plus, it can all be mathematically proven.

If enough people check, then this can't be cheated.

Not safe enough, to me, for any respectable digital voting system. Blockchains were in a way developed specifically to remove trust from processes because let's face it, it can be harmful. In a system like this, I would have to trust other people for it to be ok, and I personally would still have doubts.
And what is the "token distribution problem"? Could you please elaborate on this? I imagine for a country it wouldn't be a big hassle (relatively speaking, obviously) to issue some sort of election card enabling the user to vote through a specific address (or better, through a specific set of addresses generated from a seed).
For a voting system to be used, for example, with elections, you would need trustlessness, immutability, and decentralization, things which are all offered by a blockchain.
Also, what do you think about the other thing I said in my message above?

FYI: There is already a lot of transparency to voting systems in a lot of countries. You can just sign up as a volunteer to work at the booths, counting process, etc., and see for yourself that noone is tampering with the process.

You can do that for your specific district (at least in Italy). A district is a part of a city. There are more than 8k cities in Italy, so yeah, while I agree that you can volunteer (and that in and on itself is a step in the right direction), there are problems here for some cities that might have some parties interests in tampering with the process due to political favors or other things in return.
To say that there is a lot of transparency in voting systems in a lot of countries is probably naive.
It wouldn't be the first time if in my country, for example, some people tried and succeeded to vote multiple times in different districts (it has happened while electing the new secretary on one of the major parties of the country, Partito Democratico).
In some super grave cases mafia can actually pressure people to vote for certain people in exchange for favors, and actually enter the booth with them in order to ensure that they vote for who they think is better for their interest (a lot of omerta here).
Generally speaking, the traditional voting system involves A LOT of trust. At scale, that's a very very big no-no.
And yes, this is primarily a social and cultural problem, but we could all take advantage of a new voting model that strives to be the most transparent and tamper-proof possible.
By having a truly trustless process these illegal behaviors could be a thing of the past. Unfortunately, these are the same reasons why we probably are not going to have a truly trustless and transparent process in place (at least here in Italy). There are too many personal interests at stake, and too much power involved. It's truly disgusting.

@joepie91

And that means different things in different contexts. Yes, Git absolutely qualifies as immutable in the context I'm describing it in.

Just for the sake of my own understanding (bearing in mind I am not the person you were debating with originally), you are essentially saying that because even amending a commit changes the commit's identifying hash, it's immutable? At least, if you gpg-sign each commit (and validate those signatures somewhere in the rest of your application)? Just want to make sure I have this straight.

That's quite a list, and I'll have to read it in more detail later.

Did you ever end up reading that or did you effectively concede the point by leaving the "burden of proof" ball in your court? Just curious; I haven't read it either, though I might™ later.

Just for the sake of my own understanding (bearing in mind I am not the person you were debating with originally), you are essentially saying that because even amending a commit changes the commit's identifying hash, it's immutable?

The hash changing is indeed required for an immutable system.
The extra part that is essential is that this hash is then used in the historical list and this effectively means that 100% of the people that have a current copy will have used the original hash to come to this tree. The effect of this is the important part;

to make a single change requires rewriting all of the commits that followed and requires updating every copy on the planet with this entire new history. Due to this being too costly to do we can claim the history is immutable.

As a blockchain enthusiast, I must say this is one of the best explanations I've read so far. I agree on all points. I notice it's also often a debate about private/semi-private blockchains vs append-only databases etc.

I'd like to ask you a question related to a very basic (and overhyped I agree) use case in the public sphere: digital artwork. I've known several digital artists struggling for years to gain 'status' giving the lack of 'uniqueness' (vs. physical artwork). Let alone establishing a fanbase that is portable across platforms with these tokens as identifiers. Tokenisation did make a change. How could this have been done otherwise (meaning: without the existence of a public blockchain)? And if other tech could achieve this, why wasn't this done before?