Skip to content

Instantly share code, notes, and snippets.

Embed
What would you like to do?
You Don't Need A Blockchain

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.

@taoeffect

This comment has been minimized.

Copy link

taoeffect commented Aug 26, 2018

You don't need a blockchain.

How do you know?

"You" (your readers) might.

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.

Blockchains are very useful for verifying signatures, and will only become more important in the future.

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.

Git isn't immutable.

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.

CT is crap. This is a perfect use case for blockchains.

If you need to verify that nobody has tampered with physical goods: This is currently impossible, with or without a blockchain.

True dat.

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.

Some people genuinely stand to benefit by adopting this technology, and others genuinely don't.

Understanding the technology is the most important thing, and nobody can do that for you. Once you understand what it is and isn't useful for, then you can decide for yourself whether "blockchain" (whatever that means) is Right For You™.

Don't ask your doctor. If you don't understand then hire good engineers and ask them.

@joepie91

This comment has been minimized.

Copy link
Owner Author

joepie91 commented Aug 27, 2018

Blockchains are very useful for verifying signatures, and will only become more important in the future.

Signature verification does not in any way, shape, or form require a blockchain.

Git isn't immutable.

You cannot retroactively change commits without affecting the entire tree. So yes, when a commit or tag is signed, it is immutable.

CT is crap.

"Crap" how? You're not making any technical arguments here.

This is a perfect use case for blockchains.

How is it? A blockchain is overall more expensive to operate than CT, and it doesn't provide any actual benefits over how CT already works. That makes it far from 'perfect'.

Some people genuinely stand to benefit by adopting this technology, and others genuinely don't.

I have yet to see a single usecase that isn't Bitcoin or another cryptocurrency, where a blockchain was the optimal solution. I've assessed hundreds of non-cryptocurrency usecases that were supposedly valid ones. Not a single one of them passed the sniff test. In virtually every case, the developers were outright unaware of other existing technologies that could solve their problem better.

Understanding the technology is the most important thing, and nobody can do that for you. Once you understand what it is and isn't useful for, then you can decide for yourself whether "blockchain" (whatever that means) is Right For You™.

That I can agree with. Unfortunately, most of the people who believe they 'understand' the technology, don't really understand it at all; and more concerningly, they don't understand the other options. Every solution looks optimal in isolation; you need to understand the alternatives before you can make a reasonable judgment.

@taoeffect

This comment has been minimized.

Copy link

taoeffect commented Aug 29, 2018

Signature verification does not in any way, shape, or form require a blockchain.

Where did I say it "required" a blockchain?

You cannot retroactively change commits without affecting the entire tree. So yes, when a commit or tag is signed, it is immutable.

The meaning of immutability is that something does not change. Git does not offer immutability, and on top of that, it is based on the broken SHA1 hash. You're welcome to try building on top of it but you'll likely find that it's not reliable or secure.

"Crap" how? You're not making any technical arguments here.

You've followed my twitter feed for a while, so I am curious, how did you miss this?

How is it? A blockchain is overall more expensive to operate than CT, and it doesn't provide any actual benefits over how CT already works.

Have a look at the okTurtles posts and what and others have done, answering exactly these questions.

I have yet to see a single usecase that isn't Bitcoin or another cryptocurrency, where a blockchain was the optimal solution.

This means you've been asleep at the wheel.

@joepie91

This comment has been minimized.

Copy link
Owner Author

joepie91 commented Aug 29, 2018

Where did I say it "required" a blockchain?

You never used the word "required", true. You also didn't provide any details on how a blockchain supposedly aids in signature verification, though. Either way you haven't made a valid argument.

The meaning of immutability is that something does not change.

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

and on top of that, it is based on the broken SHA1 hash.

I completely agree with this point, and I've been complaining about this for a while. It is, however, an implementation detail; and the selection of hashing algorithm doesn't affect the inherent immutability of the scheme that surrounds it. Replace it with a non-broken hash and it works absolutely fine.

You've followed my twitter feed for a while, so I am curious, how did you miss this?

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

This means you've been asleep at the wheel.

Not at all. I've actively engaged in discussions with proponents for years, and none of them have been able to present a single usecase that was not more efficiently and effectively solved with a different approach.

@VivaCaligula

This comment has been minimized.

Copy link

VivaCaligula commented Oct 1, 2018

Aside from currency, there seems to be plenty of financial services that are /not/ better supported by non-blockchain solutions. In particular, advanced contracting, asset settlement, property management, and so on. Commerce in general seems better supported by platforms like OpenBazaar. If you know of better (meaning more secure, and secure means private) solutions to these financial services, please tell.

Additionally, some other privacy-reliant services seem to stand in warmer shores by utilizing blockchain tech. Specifically, VPN services (I know you have a hard stance against VPNs). Cryptographically secure, decentralized, VPN services can't fail in any of the regards you've written about since none of the developers can access any of the content. Sentinel.co and Mysterium.network are examples of this. Truly secure comms are also not possible without this technology (e.g. Bitmessage).

Rights-securing services for proof of ownership also seem to excel in ways not possible without blockchain tech. Poex.io and docstamp.io are examples of this.

Most of all, government. With the trustlessness of economics that cryptocurrency allows, a similar trustless nature can (and ought to) be instilled in government frameworks as well. I believe that, in principle, there is no technology that allows for this in the way that blockchain does; examples being bitnation.co and aragon.org.

Surely being "engaged in discussions with proponents for years," means some of these examples have been given before. What have you said to them / what do you think supplants these examples?

@gitbugged

This comment has been minimized.

Copy link

gitbugged commented Oct 23, 2018

Truly secure comms are also not possible without this technology (e.g. Bitmessage).

@VivaCaligula You do realize that Bitmessage doesn't actually use a blockchain right?

Bitmessage nodes store the encrypted messages only for two days before erasing them, therefore, messages are not archived in the network. New nodes joining the network can only download and broadcast the pool's messages from the last two days.

@VivaCaligula

This comment has been minimized.

Copy link

VivaCaligula commented Oct 24, 2018

It's a cryptographic, distributed, decentralized network that stores network transactions/messages for a given period of time in a segmented series of data blocks. Just because it deletes old data or doesn't secure qua longest chain doesn't make it not fall under the definition of a blockchain. Even if Bitmessage didn't use a blockchain protocol, I maintain that a blockchain would be superior to any other communications method for securing the network.

@killerstorm

This comment has been minimized.

Copy link

killerstorm commented Feb 19, 2020

Costly signaling is not a part of blockchain definition. if that was true Elements/Liquid is not a blockchain.

@joepie91

This comment has been minimized.

Copy link
Owner Author

joepie91 commented Feb 19, 2020

@killerstorm As far as I can tell, looking through all the marketing hype, Elements is indeed not a blockchain; but rather something tacked onto Bitcoin, which does use costly signaling. The costly signaling is required for trustless decentralization to work.

@killerstorm

This comment has been minimized.

Copy link

killerstorm commented Feb 27, 2020

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.

@joepie91

This comment has been minimized.

Copy link
Owner Author

joepie91 commented Feb 27, 2020

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

@zander

This comment has been minimized.

Copy link

zander commented Apr 2, 2020

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

@luzzif

This comment has been minimized.

Copy link

luzzif commented Apr 3, 2020

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!

@joepie91

This comment has been minimized.

Copy link
Owner Author

joepie91 commented Apr 3, 2020

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

@zander

This comment has been minimized.

Copy link

zander commented Apr 4, 2020

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

@luzzif

This comment has been minimized.

Copy link

luzzif commented Apr 4, 2020

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?

@joepie91

This comment has been minimized.

Copy link
Owner Author

joepie91 commented Apr 4, 2020

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.

@luzzif

This comment has been minimized.

Copy link

luzzif commented Apr 4, 2020

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.