By Sajida Zouarhi
Originally published on Medium.
This is no secret for anyone, Blockchain has fully grown up to a social buzz and proudly sits on top of the peak of inflated expectations (i.e. Gartner’s Hype Cycle).
Banks, companies, institutions … none could escape the Blockchain tsunami that has been raging for almost 3 years.
People usually react in two opposite ways: either fear (we are going to be disintermediated !) or excitement (Blockchain is an opportunity, it is going to reduce costs, increase incomes, secure processes, make coffee ☕…)
Though if we take a closer look at the latter — which we can summarize as “let’s put Blockchain everywhere” — things go wrong immediately.
Let’s get back to reality, Blockchain is not a solution for all your problems. In fact, you need to associate it with other technologies to even make it work. As for making it relevant …
Thinking as the image above suggests, denotes a misunderstanding of the way Blockchain works, as well as failing to get its full potential. With this vision, if you think about using a Blockchain in your next project, whatever the cost, you are wrong for 2 reasons:
- Most people are going to see that you didn’t get it.
- You are going to waste time working on false use cases, or even waste your money and your human ressources. But with further thinking, maybe you could come up with a better idea.
Of course if you only mean hype, Blockchain is another word for buzz generator, even if not everyone is fooled.
Ok! Now that we have made things clearer, a question raises by itself:
“Is Blockchain relevant
to my use case?”
Excellent question, here are 5 advices …
1. Understand what is the purpose of the Blockchain.
You don’t need to understand every aspect and all the technical details. You simply have to get the main properties that will be useful to you.
Example of possible descriptions: Blockchain as a tool for traceability, integrity, multi-party transactional architecture.
Examples of what Blockchain won’t do (alone)
You can store data with it and be confident that it won’t ever get corrupted. But you have no way to be sure of the veracity of this data.
This is because Blockchain isn’t smart, it doesn’t know the context of use, nor does it know your sector of activity. If no verification is made when an entity brings information to your Blockchain, then it is basically saved whether it is correct or not. But you know it won’t be possible to modify it in the future anyway. 🙂
It is a point to remember when conceiving a use case around assets traceability, like fighting counterfeit for example. Particularly when dealing with food, drugs, electronics, … wine, jewels, auto components, and so on.
2. Start from the use case, not from the tech!
You have to ask yourself if you even have a “pain point” in mind. Is it clearly identified? Given your actual understanding of the Blockchain, do you think that it brings any advantage to solve your problem and that it really fulfils your need?
3. Understand pros and cons of a Blockchain.
At this stage, if you passed the first 2 items, you should take a bit of a step back and list what can be solved directly by a Blockchain and what has to be added to it to solve your problem in a proper, efficient way.
To say it differently, you have to understand where a Blockchain stands better than a traditional counterpart and vice versa. You should identify situations where it would be less performing or even completely unsuitable. Just be honest with yourself.
4. Use the power of the Blockchain or leave it be, and use something else.
Bitcoin is often referred to as a Blockchain Killer App. This is simply because it uses every main properties of the Blockchain. Be it from a technical, strategical or economical standpoint.
Therefore, Bitcoin profits very well from using Blockchain.
What about your use case? Do you need to store data? To make transactions with other peers? And are these very transactions based on data that is already stored in your Blockchain? Is there some kind of incitement or payoff for the entities of the network?
By using the different aspects of the Blockchain, you both ensure relevance and a certain level of security. Indeed, when the Blockchain “references” itself, you know it’s going to be ok because veracity of this data is already established. But what if it comes from an external source in the first place?!
As a general fact, if data comes from an external entity, like oracles, you have to provide proofs and involve a third party, which makes the process less fluid, even though it does work. See Provable (ex Oracliaze).
Let’s not dive too much here into the details — that’s not the point of this article — and instead introduce the Blockchain Canvas.
5. Use the Blockchain Canvas!
“The canvas below helps you identify the applicability of Blockchain for your use cases. Fill it with your own case”
Simply explain your problem, use short sentences that allow people to quickly catch the context, thus dealing with your need.
Explain your strategy to solve the problem, while using or not the term “Blockchain”
Blockchain mandatorily involve several entities since it is meant to emule decentralisation.
If you are the only user of your Blockchain, it’s called a database.
In this part, you have to define entities and groups/categories of entities.
We often quote the number of nodes as a factor of decentralisation (and better security), I would add diversity of entities here. Indeed, diversity is a key ingredient for your ecosystem as it enhances discrepancy between entities which reduces the risk that they form profitable coalition or alliance. Now try to visualize your ecosystem and fill the canvas.
Where are you standing?
As you can see, there are no figures on this graph, for a good reason! People often ask: “how many nodes do I need to be sufficiently decentralised?”
It completely depends on several linked factors: the use case, the entities, the required level of security, the profit that an attacker could make. You need to take these factors into account to settle the size of your network.
To make this less of an evasive answer, let’s say that 10 nodes aren’t enough to make a decentralized network. And to provide an example, Bitcoin (launched in 2008, considered the most secured Blockchain as of today 2016) involves a little less than 6000 validation nodes.
As for diversity, 3 or 4 different categories of entities are usually enough to make an interesting use case. Moreover, this dissimilarity is a good point to advocate the use of a Blockchain which is particularly adapted to take care of the inherent complexity of multi-party interactions.
Here you have to describe the nature of your transactions. Do you need to transfer financial worth, intellectual property, access rights, or to log important events?
The peers of your network
Peer = node. An entity may have several peers (or nodes) running on different facilities.
If you chose to use a Blockchain in your application, you are going to need Validators. For example, a transaction is solely registered in a Blockchain with the acceptation of at least the majority of Validators. It is extremely important to decide who will endorse the responsibility of being a Validator as it will have decisive consequences.
Would you decide to use a public Blockchain (Bitcoin, Ethereum, …), you would have no control on the transactions validation system, because the infrastructure already exists and you have no rights on it. But it’s still possible to develop your own validation overlay (decentralised itself).
On the other hand, if you opt for a Consortium Blockchain (or “Private”), for example an application of Hyperledger, you are totally able to constitute your own Validators network. You have to chose wisely how to allocate your validators among entities, since the goal is to ensure a maximum diversity as well as a sufficient multiplicity in your ecosystem.
Of course you could do otherwise, everything is possible, you only have to design your network according to the use case, the aimed level of decentralisation in a Private Blockchain, or the degree of independence from a public Blockchain.
In a similar way, it is totally plausible to give different roles to your peers. Are they all able to read or write data? Do they all possess the “validation power”, namely the right toparticipate to the consensus to validate an incoming transaction?
What are the rules to verify and then to validate a transaction?
How does one decide that a transaction is correct?
What kind of consensus are you going to use? (If you decide to use Hyperledger for your Blockchain for example. Note that Bitcoin and Ethereum don’t leave a direct access to this aspect)
This is like thinking about the governance of your system which is — by far — one of the trickiest aspects to design in a Blockchain project.
Data and analysis
The main idea is to define the data you are going to manipulate. Is it of critical nature? Is it voluminous?
This is important to figure it out, because a Blockchain grow with each registered activity and nothing will ever be deleted. Therefore, it is a lot better to get rid of useless, unworthy information and/or data that use a lot of space and could use some diet plans…
In fact, it is advised not to store any inherently voluminous data in a Blockchain, like high resolution images for example, e.g. medical imaging. Although it is not a bad idea to keep the hash signature only, for checking the integrity of the original file (which is stored in a third database).
There are 2 types of processing in the Canvas. Distributed storage (to store data like a database, which it is after all). But it is also possible to use it to make calculations (which can also be achieved while being a database at the same time through smart contracts).
With Ethereum, writing a program (smart contract) that verifies rules or conditions (insurance, gambling, communication with connected devices) makes it possible to process information and then output provable results and directly store them in the Blockchain.
For example, if Alice doesn’t trust Bob for a given calculation, Bob can create a smart contract on Ethereum. The smart contract delegates both calculation and storage of the result to the peers of the network (decentralised). This way, Alice can rest assured that the result is trustworthy.
Here Blockchain acts as an intermediate and substitutes the needed confidence between entities Alice and Bob, by the already acquired confidence in the Blockchain itself. This sounds like the problem is solved, especially if we consider that it’s safer to trust a program than a human (wait, programs are coded by humans right? D’oh!)
The base principle is that you do trust the program behind the process even though it has been written by humans. It is easier to trust a program made once, than to trust every decisions, many humans could make, at different moments.
Last but not least …
This box of the Canvas is difficult to explain (and to fill as well), because it depends a lot on the use case, to the point that it may be optional in certain occasions.
Let’s use two different examples of use case: Bitcoin and Everledger
On the Canvas, you read “Is your system based on (or does it use) a value system making it possible to establish the link between the Blockchain and the real world?”
For Bitcoin, the link between the value of a bitcoin in the real world and its value in the Blockchain is noticeably due to validators work (aka miners), which are investing a lot of money in hardware and electricity bills.
“To mine” bitcoins is not very power efficient and consumes a lot of ressources. Value of a bitcoin can be seen as a result of validators (miners) efforts and investments. This also brings another reason for validators not to mess with their own Blockchain, because they have a lot to lose, and are dependant on the trust of entities (the users).
For Everledger, the problem is completely different, it is to fight against diamond counterfeit, by registering true ones on a Blockchain.
The value, or rather the link between the real world diamond and its asset on the Blockchain have to be strong enough to overcome any threat of destruction or corruption. Otherwise, the whole traceability system would fall through.
They came up with the idea of generating a unique ID and engrave it on the diamond itself. This very ID is naturally registered in the Blockchain and constitutes the link
The bright side of this idea (joke intended) is that to erase the ID from the diamond would require extremely expensive and hardly obtainable equipment. Thus making of the task a counterproductive one for most criminals, since it would either cost too much or involve the risk of flawing diamonds. Imperfect diamonds lose a lot of value which would make any attempt to fake diamonds not really profitable.
But diamonds obviously have unique properties that Everledger handled very well, resulting in a very effective system, capable of preventing a specific fraud.
All use cases don’t fit that much the Blockchain aspects which doesn’t mean they aren’t made for it. You only need to know what it can do best and what it can’t do at all. Then try to figure out where does your project stand, hopefully somewhere in the middle.
I hope you have enjoyed this article. If you were wondering whether or not you could make use of a Blockchain, I would really like to know if it helps you decide!
The canvas is a useful tool for Brainstorming. Ideally, it should reveal by itself if a Blockchain is suitable for your use case and ultimately if your project is relevant.
It also is a good specification support, should you wish to go further. It allows to identify needed information, which leads to make choices of technology and architecture.
Still, if you feel the need to be guided in your process, or for an expert to review the specifications of your project, you can contact me via this form.
This canvas may evolve in the future with its users feedback. It has been used for several blockchain projects in companies. It is also used during Workshops and Hackathons as a tool to help participants imagine and evaluate possible relevant use cases.