With ‘Ethereum Style’ Blockchains, I refer to any permissioned or unpermissioned Distributed Ledger Technology (DLT) that uses a Turing complete language and allows to have a significant part of application logic, typically called smart contract, running on its platform.
Ethereum and similar platforms tend to generalize Bitcoin’s Technology by adding a Turing complete language to the stack, the idea is to have a powerful language at hand with which to implement all kinds of applications (‘Bitcoin is just the 1st app, the real Technology is the immutable Blockchain and Consensus over a distributed System’). Bitcoin on the contrary deliberately supports a very sparse, incomplete scripting language to avoid attack vectors. The focus is to transfer value ‘Bitcoin’ between endpoints, implemented as public keys.
‘Smart contracts’ with code that is shared among all participants, which cannot be (unless there is a hard fork, which requires the consent of the community) changed and data in an immutable ledger can be a powerful platform for certain use cases. Often, those can be legally relevant contexts – contracts that enforce itself based on input (an oracle from the outside world, claiming e.g. a certain temperature at some place at some time or a payment received) and an effect, e.g. regulating energy supply or enabling a key for a flat. Cause and effect do not need an intermediary, an agent or a legal system other than the smart contract.
These just execute ‘unstoppable’ – like a vending machine: insert a coin and the mechanics ensure you get your bottle and you don’t need a shop in between. Investigating how far we can push this idea promises to be a fascinating undertaking. Note that this an important, but a rather limited set of use cases, which so far we didn’t implement satisfactorily mainly because we don’t have a platform enabling them. Sharing data and Rules in an open platform is essential for this use case: Rules and Actions need to be verifiable, Data and Code need to be unforgettable.
However, this is not the case for the overwhelming amount of use cases. That is a triviality because we implement all kinds of use cases without having Blockchain Smart Contract Platforms. In fact, we claim even when we will have such platforms there is not reason whatsoever – on the contrary – to implement all use cases and applications on top of them, unless they have the very specific characteristics smart contracts try covering
(1) Application Enabled Blockchains centralise Technology
Imagine you decide you ‘really need’ some of the blessings of distributed technology. Yes, you want smart contracts, you want code that cannot be changed once deployed, you have a need for crypto payment and you believe this is the future. You are all ready for de-centralization – it sounds like a new and free and better tech utopia to you. But then you realise, you might not be as free as you’d like to be. Because while you can choose in your own box any language you like, any database you like and any UI framework you like (some are around for years, proven and specialised for some of your needs), in a decentralised platform you are ‘stuck’ with e.g. solidity. Which someone as part of some community deems to be the ‘way to go’. All nice and respectable – but doesn’t ‘smell’ that an awful lot like even worse than e.g. choosing an Amazon platform where at least you can choose pretty much anything on top of the servers you choose? The most radical form of decentralisation seems to just hook on your own barebone server and throw anything you deem best for you on it.
That granted, why would you even need such a decentralised platform then? The answer in my humble opinion is obvious when you investigate the context the platform was invented for with Bitcoin: A decentralised ‘Bitcoin style’ platform is interesting when and only when, you want to do transactions with another actor in the network. There is no point sharing your data, there is no need for unforgeable data or code, unless you are executing transactions with another player. A whole lot of your can be use-cases however can be entirely to yourself, your organisation and typically they will be.
There is no reason to place them on a Blockchain. Only data that is relevant for min. 2 players in a network should even get considered for such a platform and e.g. smart contracts doing ‘something’ with them. To speak in examples: When you send a purchase order from a web shop to a vendor, e.g. a large logistic party then this order could go on an immutable Blockchain shared between several players. Data should be immutable and there might be smart contracts in the sense of code that executes automatically like e.g. picking the book you ordered from the shelf as soon as a payment was received.
(2) Application Enabled Blockchains centralise Data and Logic
Now, consider the other approach – allegedly – how a decentralised trading platform would look like. You take ebay and re-implement it on an application enabled Platform. So, you decide to succumb yourself to whatever technology patterns this platform advocates e.g. because you want immutable transactions and you want this marvelous DAO concept (no irony, we are referring to the original sense in which Bitcoin is a decentralised autonomous organisation not the ethereum DAO disaster) re-used to have a more democratic and transparent and a less monopolistic and centralised approach to trade. There is an obvious problem and an obvious solution: Blockchains at least in their original form share data – even though they can encrypt it and we can make smart choices what to share, anyone should be able downloading the Blockchain. But why would you want your purchases on Blockchain-ebay (potentially) shared with the world ? You don’t – so obviously you shouldn’t use a shared platform here. Is your whole application logic even that relevant for the rest of the world to share it ? Absolutely not, a part of the transactions can be useful for sharing in a (semi-) public ledger for verification and re-using in smart contracts but certainly this is just a small part of your application and all your other logic (what is offered, how to offer the client the next best product, how to do credit card payments) really has no function on a public ledger. In other words when you place your entire application on a Blockchain you create a ‘honeypot’ of data on a platform which is in principle shared and at the same time you burden the Blockchain with data and logic which is not relevant for anyone else in the network.
The first part of the platform (you expose too much sensitive data on a Blockchain) is addressed often with the concept of a permissioned ledger. That is a ledger, which is accessible e.g. only by a consortium but noone possible. Even though ‘immutability’ (less hashing power if the consensus mechanism is proof of work) might be ‘less immutable’ there can be cases where this scenario is useful. Some might argue in reality one could just as well use a shared database with advanced auditing and logging to avoid forging. I believe we could even go a step further and say: if you have data, that you don’t want to be shared you just don’t use a distributed system. No matter how smart and sophisticated your cryptography will be, at the end of the day there is some form of data sharing and if you don’t want that you just shouldn’t go for a distributed ledger. Differently put: You should share your data exactly with those for which a transaction is relevant (to execute or verify) and you should share only data and logic, which is relevant for more than one actor in the network. Placing your entire application on a shared distributed ledger will almost always violate this principle and therefore is not an appropriate architecture. What can be useful is to use a (permissioned) distributed ledger including smart contracts for transactions between participants in the network, such that you can control who sees what with partial sharing (e.g. hash fingerprint of a transaction) and advanced cryptography.
If all this wouldn’t convince you and you believe Blockchain is (kind of) the ‘only’ way to go (‘on premise is so 90ies and you can’t be serious about advocating centralised clouds like amazon web services!’), consider this point: Wouldn’t it be natural for a decentralised paradigm to allow as many different technology and governance approaches as possible ? If someone prefers his COBOL on premise or his amazon cloud platform – shouldn’t it be that persons decentralised choice to use it ? No matter if this very application is entirely centralised with him. There might be perfect reasons like: “I must keep most of my data behind my firewall” or “Python on heroku is simply the best – at least our teams skills are such that we are brilliant on this platform” or “I don’t like solidity as a language, in fact I don’t like ethereum at all. I just can’t stand this de-centralization community with their presumptuous metaphor ‘world computer’, their DAO drama and so on …”.
I think the answer from a de-centralization perspective can only be ‘YES! OF COURSE!’ We should have as many technology paradigms as possible and those should compete and for different contexts, different stacks will be useful.
Application Enabled Blockchains hardly tackle the ‘Dataformat Problem’ – but they should!
If you accept this verdict – and you should – the focus shifts and the ‘real’ problem of decentralisation is a well-known problem, sometimes referred as ‘Integration’. It is the problem that different Applications often talk about the same thing (a Client, an Order) but have different data formats and different message formats and different APIs to address those when they interchange information. There is no automated way to translate these – usually humans need to ‘code up’ a solution and that can be tedious and it is actually the basis of a large industry.
The decentralisation ecosystem for some reason doesn’t even look at this problem. Allegedly this might be because of a false feeling of ‘we decentralise enough!’. The Bitcoin lent concept of Miners, Consensus and a Distributed Systems can help making code unforgeable and Data immutable and gives rises to a most exciting governance concept of a Decentralized Autonomous Organisation up – what else ? This is however is really just ‘decentralising from within’ – it is as of Amazon web services or google decided to go to the bright side and re-organise their internal departments democratically and consensus oriented.
It really doesn’t mean too much (it’s a good thing and has some effect) for the user of a platform: if the ethereum ecosystem decided all nicely and civilised we are going for a hard fork or not or we gonna do language xyz now and learn from our mistakes, then is nice to know but from the ‘outside’ it really doesn’t matter if some top-leader CIO had decided that alone. What you want instead is total autonomy of your application and governanceand for your transactions with others using the ledger a technology as seamless as possible with as many benefits as possible (immutability, unforgeable, rich and secure language to write smart contracts). There is some dependency to the eco-system, but really just for this little and important part of your application, where you transact with others.
Generalising Bitcoin the ‘other way’ – exchange and transact over any kind of information (not ‘ just’ money!)
If one is more interested in Bitcoin as a Transaction Platform (as opposed to an Application Platform) one could try to generalise, which information can be passed between endpoints, i.o.w. we wouldn’t be interested in the question so much what application logic could run or not on the Blockchain but rather what information (e.g. an order) we can exchange between endpoints via a decentralised platform. Such scenarios can be useful for e.g. trade among parties and there are platforms (often referred to as middleware or Enterprise Service Bus) which do that but they are not decentralised.
We will refer to this problem as the ‘Data Exchange Format’ Problem. It is a well-known problem, there is an entire industry around it. In fact, the problem serves as an ‘entry door’ for many very centralised platforms to dominate. Imagine a world where applications could seamlessly talk to each other, there would be some magic ‘babelfish’ translating messages between systems reliably and we could even commit transactions (‘I order your room for nights xyz for price abc from you’) in an immutable transaction log, where some smart contracts (‘the key to my flat is activated after I received an amount X’). Would we still use Airbnb in this world ? Maybe not, maybe we would. But undoubtedly the need to use Airbnb as a place where people can ‘virtually meet’ and do business would be much less, because one could essentially use one’s own little applications, because such a layer would connect different parties. Platforms like Airbnb (or uber or eBay or facebook) have a similar position like banks: they enable people to transact and via this position as a middleman dominate an entire ecosystem, presumably taking too ‘large of a cut’ of the transaction.
Recently, there are efforts from consortia and bodies like the W3C to standardise Intercommunication formats. The approach is to simply agree between humans, with which data formats Blockchains conventional applications should interoperate. This approach is the standard approach – in fact, it is basically the only approach to ‘make applications speak’ and used in any enterprise internally. Attempts to standardise communication with open standards is laudable but has the unfortunate side effect – with its boards and processes – to stifle innovation. If there is a dominating player, standards are just set by them to enable communication: facebook just controls with its own protocols how members can talk to each other, they are not open and reusable by anyone like SMTP.
This is the other decentralisation problem: how can you make applications talk to each other as seamlessly and reliable, that there is no ‘translating middleman’ needed. Decentralised Ledgers can contribute to this architecture.