Does your project need blockchain? Well probably not . I actually ended up in a meeting recently where a product manager asked the attendees in the room (most of them tech people): “Can we fit blockchain somewhere in there or is that just not possible?”. As with all new buzzed IT stuff, this blockchain thing is no different.
When it comes to building real business solutions on fancy, green or hip tech most decision makers don’t have enough knowledge on the topic to make the right decision. So what exactly do you need to convince yourself (and maybe others) that you actually might just need blockchain technology for that specific project?
So we take a look at the key pillars of blockchain technology (implementation independent as I see it):
- Speed of execution;
- Built for incentives.
Going through these topics will fuel your discussion with managers and peers. And you might come to the conclusion that you actually need blockchain in your next project.
There is no such thing as perfect immutability in any blockchain. Every blockchain allows for conditions where transactions can be altered, but it depends on the type of consensus mechanism how a blockchain behaves under such changes. Immutability is usually pursued by some “proof of something” economic mechanism and sheer number of compute you would need to bring to force consensus.
Public networks are in great favor here. Private networks use less nodes and convincing the majority of nodes to allow a fraudulent mutation would be rather easy (this is typically known as a “51% attack”). More info on this: Preventing the 51 percent attack
The key feature here is, that nobody owns all the information…nobody owns the chain. Maybe parts of it, your own personal data for instance. As with immutability, this can only be practiced with public nodes. With private networks, companies usually own the nodes. And if you own the nodes you own the chain and potentially all the information contained in it.
Blockchain based technologies are often based on distributed ledgers, which means that the ledger (and the work associated with the transactions on this ledger) is distributed among nodes. But most blockchain networks are also decentralized and that characteristic ensures there is no central point of control, no central body of governance. More info: Blockchain technology Principles and Applications
In a centralized application a certain amount of trust between the partners is essential. If there is a lack of this trust, blockchain technology might help out. This “one version of the truth” characteristic helps partners accepting information from each other.
When you trust the data presented by the system, you don’t need to verify all individual transactions. But what if you wanted to? Blockchain technology allows you to sync all data locally and replay every single transaction. This requires a bit of compute and some patience
Speed of Execution
Compared to a central database running in the cloud, execution is not as immediate. But it is still extremely fast. Since there is no intermediary, the transactions can travel the globe in minutes. All partners on the chain comply to the same set of rules, the same protocols and the same information schema. So no transformations, conversions or migrations required.
Built for incentives
The best known blockchain networks are used to support cryptoeconomics (Bitcoin, Ethereum, etc.) and the incentive system is vital to their success. If you need a solution to support both decentralized applications and leverage custom incentives…… blockchain technology has your back.
To sum it up
In all fairness, blockchain technology can be a vital part of a solution. In fact, I am working on several business opportunities (both commercial and governmental) where blockchain does have its purpose. But you have to be careful to not rush into this new technology. There can be huge risks and the topic is (over) hyped. I for one do not trust people that eagerly list all kinds of blockchain skills on their resume.
And if you do come to the conclusion this new technology matches your project’s needs, there are more decisions ahead. The obvious ones being: public or private and what type/protocol to choose.
I find the first the easiest to answer. If we cannot run it on any public net, than the decision to use blockchain might just be wrong. You would need to bring your own nodes and that usually defeats a lot of general concepts (immutability, independency and probably even trust). Besides, if you need to provide all the decentralized hardware, you are potentially better off economically choosing centralized (cloud) compute and services.
The second decision (what type/protocol/generation) is much harder and should be motivated by solid research on the project’s requirements.