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.

What you're talking about is "permissionless/public blockchain".

Permissioned (private, federated, etc.) blockchains do not require "trustless decentralization".

E.g. see the paper by BitFury: https://bitfury.com/content/downloads/public-vs-private-pt1-1.pdf

From the point of view of cryptography, a blockchain is essentially a kind of linked timestamping optimized for synchronization.

If you add a requirement of "trustless decentralization", it becomes incredibly vague. For example, Bitcoin testnet won't be a blockchain. Even though it has blocks just like Bitcoin mainnet. So in this case it's not longer a technical way to described a style of structures/protocols, but a value judgement.

@killerstorm "Permissioned blockchains" are not a thing; they're just databases with some fancy marketing to make them easier to sell.

From the point of view of cryptography, a blockchain is essentially a kind of linked timestamping optimized for synchronization.

Nonsense. That concept far predates blockchains, and has had many different implementations already. "From the point of view of cryptography", a blockchain isn't anything, because a blockchain is a network design thing, not a cryptography thing.

If you add a requirement of "trustless decentralization", it becomes incredibly vague. For example, Bitcoin testnet won't be a blockchain.

Bitcoin's testnet has the exact same architectural design as the mainnet, with the same trustless decentralization model, so yes, it's a blockchain.

As a long time blockchain developer, I just want to comment that I agree with your points.

To me its not so much the technical definitions that matter, it is that in the last 11 years literally nobody has managed to start a company that we can deem successful (making a profit) selling any other type of blockchain solution, other than Bitcoin. Which isn't even a company.

After all the ICOs and millions of dollars put into every conceivable problem solved with blockchain, we have not seen a single one of them actually produce a competitive product. In most cases there wasn't even a non-competitive product...

What do you think about blockchain and voting?
Could blockchain one day be leveraged to develop a reliable, secure and anonymous digital voting platform?
Blockchain (namely Ethereum), in conjunction with a decentralized storage system can also be used to have censorship resistant websites. ENS and IPFS come to my mind. One could register a domain on ENS, upload a website to IPFS, make the ENS domain point to the IPFS blob et voila! I'm interested in hearing from you!

@luzzif The short answer: no.

The longer answer: voting security is an incredibly complex field, that works totally different from the types of application security that developers are used to dealing with. For example, voting security doesn't try to prevent attacks! It only tries to prevent scalable attacks, because those are the ones that sway a vote effectively.

This pretty much disqualifies the entirety of electronic voting, blockchain or otherwise. The great property of a paper + human system is that it's super difficult to manipulate at scale without being found out; you need to trick literal thousands of people, and do it perfectly every time, and never be found out in the future either, or it's game over. Humans are messy and unpredictable, so there's no way to simultaneously compromise everyone either.

Electronic systems, on the other hand, are highly consistent and predictable; and whereas in normal security that would be a good thing, in voting security it is a very, very bad thing. It means that if you find one flaw, any flaw, you can immediately compromise the entire system. Attacks on electronic systems are, by definition, scalable - the exact thing you want to avoid.

Blockchains, like all technically decentralized systems, make this even worse. Whereas with a centralized system you can at least pull and inspect the entire system, it's impossible to unilaterally stop a decentralized system; you're dependent on the rest of the network.

On top of that, blockchains have public information by design, and the fully-automated decentralized decisionmaking requires that the same system have access to both your identity (or pseudo-identity) and your vote, so as to prevent double voting. That's an absolute no-no in a voting system! It's precisely why in a secure paper election system, your voting ballot has a sequence number and not your ID number on it, and it's picked from the top of the stack at the venue.

So, to return to my original point: no, voting is not a usecase for blockchains. Electronic voting is already a bad idea for anything with serious social consequences, and the properties of blockchains just make it worse.

A really good semi-anon voting system already exists.

The biggest issue with this is social. Not technical. People don't have a digital ID or token assigned to them.

The system I'm talking about simply assigns a 20 or 30 byte token to each user (you can make this more complex with pub/priv-key) and people register their votes via tor or something.
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. On top of that, individuals can go and check that the vote they registered is properly stored in the result. If enough people check, then this can't be cheated.

There is no need for blockchain here, a central system makes more sense in many ways. At best you could map 'blockchain' to have one block per vote. It just doesn't add anything to do blockchain.

Again, this (and any blockchain system) have the problem of token distribution.A social, or people, problem. Not a software technical problem.
You need to solve that problem. Blockchain would not help you there

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?