- This story was first published in LinkedIn on April 30, 2017 https://www.linkedin.com/pulse/pavlovs-schr%C3%B6dingers-blockchains-roberto-capodieci/
We all know about Pavlov’s dog and Schrödinger’s cat. After working on MANY Blockchain projects over a few years, now that Blockchain is reaching a hype, I believe the following analogies may ring a bell to many other real Blockchain consultants.
Pavlov’s Blockchain (Pavlov’s dog analogy)
This one is simple: at the sound of the word “Blockchain” investors start salivating. Add the sound “ICO” and the excitement goes so high that it gets embarrassing.
Schrödinger’s Blockchain (Schrödinger’s cat analogy)
This one is a little bit more complex to explain, and it is the core of my article. Schrödinger’s Blockchain, while staying inside the box, is at the same time both a Blockchain and a centralised system. How does this happen? Let me explain.
Due to “Pavlov’s Blockchain” induced excitement, many entrepreneurs in need of an IT implementation request “the Blockchain” from their suppliers as the core element of the solution infrastructure. Why do they ask for Blockchain often without knowing what it is, how it works, or what it is for? Because it is a buzz word, because it helps in their PR work, because the stock of their company needs a push up, because their competitors are using it, because they think they know what it is about, because a consultant told them they should use it, because there are billions invested in Blockchain projects, because everyone has one and they want one too…
Well, I can’t completely blame a client for requesting something he feels he needs and is ready to pay for, even if he doesn’t know what it is. The issue comes when a dev shop, a consulting firm, a software house, or whoever is asked to deliver a Blockchain solution, accepts the job without fully understanding Blockchain. In my opinion, offering to work on something without knowing it, is not only unethical (in some countries it is even criminal), but is damaging for the client, and a theft of money.
There is great scarcity of Blockchain experts, and not enough serious trainings done to create competent Blockchain consultants. For this reason many organizations fall in the hands of Blockchain-incompetent developers and consultants, leading to the Schrödinger’s Blockchain effect.
Forcing “a Blockchain” into a solution, implemented by (even great) developers who have no idea how a decentralised and distributed system works, leads to tragicomic situations. I have witnessed several on my own, and had to deal with requests that didn’t make a bit of sense.
The Blockchain in a Box (when it is both a centralised system and a Blockchain)
Case 1: a multi-million dollar company that deals with messaging (I can’t say anything else) sent their top IT architect to our office to study how to integrate a Blockchain in their solution. Their proposal was to have a “single-node blockchain in a local network and behind a closed firewall (and thus not accessible via Internet) to be used as data storage”. Their system would have had access to the node API to save data and present query results to users via their web interface.
Case 1 considerations: this company wanted to put their idea of Blockchain in a box and treat it as a centralised system. They were interested in a particular function of our Blockchain, not in a Blockchain. We turned them down, explaining it would be much easier to code that functionality in a more conventional centralised solution.
Case 2: a company with millions of users wanted to upgrade their system to a Blockchain system. They paid millions of dollars to a software house that created a blockchain with several nodes… all inside a VPN with no access to the internet. Users would access the “Blockchain” services through a website, where their private keys were saved. Yes, you read that correctly: the users’ private keys were saved in the website database. For example if a user wanted to transfer some tokens to another user, the system behind the website would prepare, sign, and broadcast the transaction on behalf of the user, with that user’s private key?—?all in a VPN-enclosed Blockchain.
Case 2 considerations: Not only did they close the Blockchain in a box (making it a centralised system) but they also kept all the users’ private keys in clear-text in a centralised database. What is missing here is an understanding of the reasons a decentralised and distributed system uses cryptography to identify users. Can you imagine a PGP system that keeps all the private keys on a centralised server that signs or decrypts emails on our behalf?
Case 3: a company with hundreds of thousands of active users runs its own PoW Blockchain, controls 100% of the nodes without opening the network to the users, and hosts all the nodes in a single AWS account (with no ASICS). The AWS bill at the end of the month is on the order of the hundreds of thousands of dollars, all to mine their own private blocks!
Case 3 considerations: why? why use a Blockchain as a centralised system and pay millions of dollars over the years for it? We are not talking about a consortium that set up a private Blockchain behind a VPN where each member of the consortium controls a single node. Even that could justify the infrastructure (thought servers with ASICS cards in a data center are cheaper.) But here we have a single company controlling all the PoW nodes, and keeping all of them in a single expensive AWS account. Who are they are competing against when hashing? Themselves?
Case 4: a company invests a few million dollars for a new Blockchain solution, The developers clone an existing PoS system and set up a new blockchain with this node software. They implement a middleware that manages the business logic (which transactions are good, which should be rejected, what are the consequences of a transaction, etc.) They force the users to post transactions through their middleware to enforce their business logic. After consulting us they realised that anyone connecting to their Blockchain’s P2P with a copy of a node could post any transaction they wanted in the Blockchain, bypassing the middleware.
Case 4 considerations: The only solution to avoid users posting transactions directly to the blockchain (bypassing their middleware) has been closing the Blockchain in a VPN, and thus putting the blockchain in a box, where it is simultaneously a Blockchain and a centralised system: Schrödinger’s Blockchain.
Misconceptions about Blockchain are worse than not knowing anything
It is important to understand Blockchain before consulting and offering to implement or design Blockchain solutions for someone. It is important to understand a Blockchain both in a conceptual and technical manner. This is why I do workshops and seminars on this subjects. The coding part comes later, once it is very clear how a blockchain works and what technical needs surround it. I am not talking about learning to code smart contracts in Ethereum. That is a great skill to have, but if I may offer an analogy: coding smart contracts in Ethereum is like preparing lunch using those pre-made boxes with some instructions to follow. One can’t call himself a chef for doing that. I am talking about cooking a blockchain from the bottom-up, understanding the ingredients and why they needs to be there.
Some people (consultants, developers) go to a Bitcoin seminar and come back thinking they know all about Blockchain. A few become arrogant in their little and confused knowledge, as they must feel very secure about it. Many times I been accused of being wrong by such people on very basic topics. For example after showing an example about transactions with hundreds-of-millions of tokens in PoS blockchains, I been interrupted by someone saying: “the blockchain has a maximum of 21 millions coins”. The Blockchain, because many think there is only one. Same with people coding smart contracts for Ethereum not knowing the difference between a “Smart Contract” and a “Smart Transaction”.
Implementing business logic in middleware that manages the Blockchain node, rather than putting the business logic into the Blockchain consensus system, is ok to prepare a PoC as it is faster and cheaper, but should never be put into production. The validity of a transaction has to be determined within the consensus system, by all the nodes, and voted as good. And we are not talking of remittance transactions such as a Bitcoin one, we are talking about the implementation of Blockchains where users post contracts and the consensus system validates data fields such as expiration date (to be not in the past), or a shipping number to see if follows the given format, etc. How a Blockchain processes transaction data to guarantee in a distributed and decentralised manner that the transactions are legitimate, come from the right users, follow the prescribed logic, etc, is something any consultant and software analysts must know before working on Blockchain, to avoid putting the Blockchain in a box.
Written by Roberto Capodieci, edited by Tim Johnston