This is the second in a series of posts on blockchains. The first post explained what a blockchain actually is. This post focuses on the advantages and disadvantages of blockchain technology.
“A blockchain is a series of states of a distributed ledger where each state, except the first, contains a secure reference to the prior state and sufficient information to demonstrate that the transition from that prior state is valid according to the system’s rules.
So why use a blockchain?
The primary advantage of a blockchain design over previous designs is that a blockchain design naturally allows every participant who wishes to do so to ensure that every system state change complies with every system rule. This is both a security and a design advantage.
It is very difficult and expensive to provide this kind of security in a non-blockchain system. If one tried to put this capability into a non-blockchain system, one would essentially be turning it into a blockchain. It is this property that gives blockchains one of their most important characteristics — the absence of any central data store that needs to be defended.
The need to create and defend such a central data store drives a lot of the cost and complexity of non-blockchain systems. Significant amounts of a system’s operating budget can be related to precisely this. Who will operate this central data store? Where will it be hosted? What controls will be placed around it? How will its security be tested? What will the recovery process be if it is compromised? How will it be determined what data is reliable and what is not?
Another key advantage of a blockchain is its unstoppability. Other than those caused by safety windows around rules changes, none of the top five blockchains had any actual downtime in the past three years. Very few centralized services can say the same.
To get comparable reliability from a non-blockchain system is simply not possible. Non-blockchain systems get reliability from complex redundancy and failover schemes that have their own complex failure modes. If you have a centralized transaction processor that you make reliable against failure by having two of them, you get a new failure mode where each processor thinks the other failed. Blockchain systems have this kind of reliability fundamentally built in by design.
Aren’t blockchains slow and expensive?
No. Blockchains are not inherently slow or expensive.
Some blockchains are slow because they have designs that are extremely trust-minimized, that is, they prioritize trust minimization over speed. For systems like this, levels of trust minimization are achieved that are impossible without a blockchain. But you can still get the reliability and security benefits without that kind of trust minimization and its accompanying performance penalty.
Some blockchains are expensive because they have designs that can perform the initial distribution of a cryptocurrency as it is created in a decentralized way. For systems like this, decentralized distribution is achieved that is impossible without a blockchain. But you can still get the reliability and security benefits without that kind of cost if you do not need this particular functionality.
Blockchains, however, do have a scalability problem. Non-blockchain systems often have horizontal scalability, that is, if you want to process twice as many transactions, you just double the number of transaction processors. This is not really possible with blockchain technology yet quite this easily. While there are numerous different promising developments on this front, it is by no means certain that blockchain systems will ever be as scalable as non-blockchain systems.
This means there are a significant number of applications for centralized transaction processing systems that would definitely be made significantly worse by attempting to implement them with a blockchain design. This will probably always be the case. Blockchain is absolutely, definitely not going to make everything better.
Aren’t blockchains just good for cryptocurrencies?
No. Absolutely not.
Consider, for example, the tracking of pharmaceutical products. Pharmaceutical manufacturers compete and do not want to share their shipping and distribution information with their competitors. They would prefer not to pay millions of dollars a year to give their data to a central company that would operate a critical part of their regulatory compliance. They want to ensure that if the government accesses any system information, they are, at the very least, notified of that access.
This can be solved with blockchain. Each manufacturer can stand up a private blockchain node. Zero knowledge proofs can be used to validate the transfer of pharmaceutical products from manufacturer to distributor and distributor to customer. The zero knowledge proof transactions can include encrypted portions that can only be decrypted by the manufacturer so the government has to go the manufacturer to unblind the information and manufacturers cannot see each other’s distribution information.
This system will run reliably so long as some subset of the manufacturers keep their nodes operating. Manufacturers are not trusting third parties with access to their distribution and sales networks. The public, but encrypted, data allows any recipient to confirm at any time that they are the only recipient of a particular item placed into the system by its manufacturer.
This is a great example of a problem that is a perfect fit for today’s blockchain technology that has nothing to do with cryptocurrencies. It is a real-world use case for a permissioned blockchain.
Is is hard to develop blockchain software?
Yes, it absolutely is. But this not because of any inherent property of blockchains, it is due to a historical accident.
When blockchain was first developed, there were no tools for developing blockchain software. The only apparent significant application was launching a cryptocurrency. So bitcoin was developed as a blockchain for issuing and transferring a cryptocurrency.
As other applications for the technology began to be envisioned, the implementation was focused around a blockchain designed for issuing and transferring a cryptocurrency because that was all there was. We would up with platforms like Ethereum that support developing decentralized applications built around a blockchain for issuing and transferring a cryptocurrency.
This is a somewhat unfortunate timeline. In an ideal world, someone would have thought of a blockchain design and developed a great toolkit for developing blockchain applications. On top of this platform, applications for issuing and transferring cryptocurrencies would have been developed as would have, on an equal footing, other blockchain applications.
Unfortunately, we may be stuck with this scenario for some time. The projects that are working on developing platforms and tools for decentralized applications tend to look for a quick, simple way to monetize their efforts. The easiest way to do this is to issue some kind of token and, once again, we wind up with a platform for developing decentralized applications that is built around issuing and transferring a cryptocurrency.
This strategy may be doomed to fail anyway. If you introduce a new token merely as a means of payment into a system that is open source, anyone can modify the system to permit payment with other tokens. A system that absolutely requires someone to pay in some niche token is inferior to a comparable system that permits people to pay in several major tokens. Nobody wants to have one kind of money to pay for food, one for clothing, and one for rent. That does not really make any sense.
Next time:
- What technologies do we already have?
- What do we not have yet but know how to build?
- What do we not yet know how to build?
- What can we do with just what we already know how to build?
One thought on “What are blockchains good for?”