Judging blockchain by its use cases
Most blockchain proposals arrive with a description of the technology and a short paragraph about the business problem. The more useful way to read one is the other way round. Start with the problem, and ask whether a blockchain is the simplest thing that solves it.
These five questions help.
1. Who needs to share this record?
A blockchain is a shared record that several parties can add to and read. If only one organization writes to the record, a normal database it controls will usually be cheaper and easier to run. The case gets stronger when several organizations need to update the same record and none of them should own it.
2. Do those parties trust each other?
If the parties already trust one central operator, such as an industry body or a shared service, that operator can keep the record. A blockchain earns its place when they do not want any single party to be able to change past entries without the others noticing.
3. Where does the data come from?
A blockchain keeps a record from being changed after it is written. It cannot check that the record was right to begin with. If a person or a sensor enters the wrong figure, that wrong figure is now hard to change. Ask how data gets in, and who checks it at that point.
4. What happens when something has to change?
Real processes have corrections, refunds, disputes and records that must be deleted for legal reasons. Find out how the proposal handles each of these before anything is built.
5. Who runs it, and what does it cost?
Someone has to operate the network, pay for the computing and keep the software up to date. Compare that running cost with the cost of the problem you are trying to solve.
What a good answer looks like
A proposal worth a closer look names the parties who will share the record and explains why they will not hand it to one operator. It also has a plan for bad data and for corrections. If a proposal mostly describes the technology, check whether a shared database would do the same job.
