Decentralize it, Don’t Decentralize it…
Don’t let a daisy decide for you to go for decentralization or not
There are so many good teams and ideas out there working in the blockchain space and many projects are focusing on infrastructures because, right now, improving blockchains scalability is a big challenge. Nevertheless a lot of high-level projects are trying to ride the wave sometimes adopting some “public blockchain” for a specific use-case even if it could be counterproductive. Being a “blockchain company” seems to be mandatory and that’s why everyone is joining the blockchain race: a decentralized race where the only rule is there are no rules, no central authority, no “medical clearance” required.
In the following there are some “obvious” considerations to take into account, at idea stage, when deciding to apply a decentralized model into your project.
Proof-of-I’mtheretoo !
As emerging technology “blockchain” (?) is becoming more and more famous in every industry at every level. Projects are mushrooming left and right, ICO ads are everywhere, BA and VC are hungry for blockchain startups, many non-technological companies are trying to provide services to support blockchain projects.
Driven by a mass-excitement “visionary entrepreneur”, “blockchain experts”, “innovation companies”, “opportunity seekers” are filling their profile, websites and social media with magic words like blockchain, decentralization, distributed ledger, proof of whatever!
If we add to this phenomenon a mass economic interest related to tokens, bounty programs, referral links, ICO, funding and marketing strategies we could easily understand how, in few months, we are now totally surrounded by misinformation.
If you have never ran how would you prepare yourself for a sky-race marathon that everyone is so excited about? I personally would start from understanding what a sky-race marathon is.
Different perspective
- “Let’s develop a new document management application. We could also provide a proof-of-existence feature based on a public blockchain!”
- “Let’s develop a blockchain proof-of-existence system for providing a new document management application!”.
The starting point is completely different, the first “product-centric”, the second “tech-centric”. It’s a slightly different way-of-thinking and both approach can eventually lead to provide a similar result but the path taken with the second one could end in a bind. Unfortunately the blockchain race excitement has got many companies to start develop a project over a technology instead of adopting a technology for a project.
Food for some decentralized thoughts
Before starting to dream about a “blockchain based” product why don’t you take some times to brood on the following considerations?
“BLOCKCHAIN” AS A FULL PACKAGE
Q1: “Does our project need all the capabilities offered by a blockchain?”
It’s important to understand that the word “blockchain” is a friendly-one used to recap a system made by a mix of combined technologies providing different capabilities: a blockchain (!), peer-to-peer distribution, consensus algorithm, cryptography and more. For example cryptography and hashing functions are some “old math” that the blockchain excitement has now made famous even among business-oriented product managers. While you are planning your project try to understand if it needs just a set of those functionalities. Ex. calculating an hash and saving it with a timestamp in you own server it’s easy and it has always been possibile. You don’t need “a blockchain” just for that!
BLOCKCHAIN TECH IS CONTINUOUSLY CHANGING
Q2: “Are we willing to invest and develop on a young and growing technology?”
There are many “blockchains” out there with different features and purposes. All of them keep changing, growing, adapting and scaling thanks to dedicated teams of core developers working hard. There is still a long way to go in most of those projects. While considering to adopt a specific “public blockchain” (or a set of technologies — see q1) for your high-level use case you should keep in mind that you have be ready to adapt and change as fast as the infrastructure grows. A constant R&D approach would be required.
MORE THAN LIKELY YOU ARE NOT “DECENTRALIZING A XX BILLION MARKET”
Q3: “Does it worth developing an hybrid solution considering the effort of maintaining two different architectures?”
A “blockchain” could be used, for example, to securely store and verify small amount of data, record transactions, running smart contracts or as an alternative payment gateway. While you are designing a solution remember that, right now, based on your use case, perhaps you still need to use a common client-server architecture for all the back end management. Given the current capabilities of the major “public blockchains”, in terms of storage and data processing, many applicative projects are developing hybrid solutions where the backend still being managed by the company (using their own server and classic approach for accounting, storage, etc…). Besides, probably, you are not decentralizing a market instead you are just providing some functionalities that leverages a decentralized model. As an hybrid solution, you still have to pay your bill for your private infrastructure, it is important to have clear how it could reflect in your decentralizes, sorry, hybrid offer.
TOKENS HAVE TO BE USEFUL
Q4: “Shall we provide a token in our platform? Is the token used for what?”
Projects like Ethereum allows everyone to generate and distribute tokens in few minutes. This has introduced the possibility to design rewards system giving to new platforms a powerful leverage for attracting users or increase conversion rate in a new way. With a distribution token functionality it is possibile to overturn (or extend) classic business model, that’s why this is an opportunity that could be reflected inside a blockchain project. Raising money with an ICO is a good way of funding but cannot be considered part of a business model. Giving a real value to your token will reflects how your platform grows. If you design an useful service and, if a token model apply, why don’t give to it an useful purpose? I know…it’s cool to say “we are distributing our crypto!” just because you can but it isn’t enough.
TRANSACTIONS FEE AREN’T FREE
Q5: “How do we deal with the transactions fee?”
In a “public blockchain”, right now, transactions fees has to be paid. If your project has got a potentiality to go viral and users would be willing to pay their transactions fee you are making a goal. Unfortunately sometimes in hybrid application design, trying to “removing a centralized fee” the focus on “who and why is going to pay the transactions fee” is underestimated. Let’s assume your blockchain projects will have an audience of 300.000 users and each of them are signing five transactions per year, 0.50$ average network fee: 750.000$/years given to the network. If less than half of that money were used to rent a PaaS infrastructure (ex. AWS) it would be able to provide a more wide technical support for your users (of course with a different set of benefits then the one provided by a decentralized model).
One last final question
I consider real runners in the blockchain race those teams who are working on infrastructure, scalability, integration services, off-chain development, identity management. Anyway if you and your team want to leverage a decentralized set of technologies for higher level projects I hope my previous questions could help you on finding a strong answer to the most important one, question zero:
Q0: “Why is decentralization important for our project?”
Hope it could be useful.
Ciao!
Luigi
