The hype surrounding Blockchains has exaggerated the realistic capabilities and applications of this new technology. This frenzy made it hard on businesses, developers, and investors to understand the practical limitations and to identify the right applications that are appropriate for or distributed ledger technology. Blockchain and from have recently published a peer-reviewed paper¹ that presents a structured methodology that can help determine the suitable technical solution to solve a particular application problem. In this blog post, we will go through this methodology and explain some examples applied in the paper. Karl Wüst Arthur Gervais ETH Zurich Technology Comparison Blockchains are append-only ledgers that basically persist (save) state. State can be transaction information, or program data, or hashed documents, etc. Basically, any information that needs to be persisted. Databases have been there for this task for decades. Moreover, Blockchains present a new class of technology used for state persistence — with additional features including digital signatures and tamper resistance. Let us revise the three main technologies: Databases First of all, (single, parallel, or distributed) have been used for decades to persist state and query data. Decades worth of research have been invested to optimize the different layers of query processing and state persistence. databases Naturally, they have the highest performance in terms of transaction throughput and query latency. However, all along, they have been designed to be centrally managed by a single authority. Hence, no consensus mechanism is required across different parties. Permissionless Blockchains Permissionless Blockchains are public ledgers (state) that are not managed by a centralized authority. That is, the ledger is distributed across a dynamic network of peers that can include illegitimate entities too. The brilliance of Satoshi, was to present a design that maintains on the distributed state in a dynamic and trustless network. This means that permissionless Blockchains can tolerate a (fraction of the) network with byzantine or untrusted behaviour. consensus , the tradeoff here is . In , the drastic performance hit is because of the POW protocol itself which by design is slow. In comparison to normal databases, in any permissionless Blockchain, Because no matter what, to maintain the consistency of the distributed state, there has to be communication between the different peers in the (geographically distributed) network. As everything comes with a price performance cost (throughput and latency) bitcoin a performance hit is inevitable. Permissioned Blockchains Permissioned Blockchains represent a hybrid design choice. In particular, they are not centralized to a single entity, yet they are authorized to a small set of preselected trusted peers that can write state. Since the database network is not scaled to a large number of public nodes, as in the case for permissionless Blockchains, its performance in terms of throughput and latency is much better. Nonetheless, its performance cannot compete with a centralized database. After looking at these different systems, it is easy to realize that there is no one-size-fits-all solution. Everything is a trade-off. Different applications have different requirements and hence different appropriate solutions. “Do you need a Blockchain?” Flowchart Flowchart for choosing the right technology¹. TTP represents Trusted Third Party and a writer is an instance that writes state to a database or Blockchain. This section describes a generic high-level flowchart presented in the paper to find the appropriate technology for your application. Note that a writer is an entity that writes state into the database or blockchain. If your application does not require state to be persisted, then obviously there is no need for a blockchain or any database. Similarly, if there is (of state), then than a regular database. On the contrary, a database would be more suitable as it is more efficient in terms of performance. one writer a blockchain does not provide any additional guarantees Otherwise, if there is more than one state-writer we take another route. The question then becomes, . If the application cannot rely on a single trusted entity we can further move forward to see if we still need a blockchain. it would be more efficient -in terms of performance- to rely on a centralized entity. is it sufficient to have a online TTP (Trusted Third Party), or in other words, does it need to be tamper-proof Otherwise, a blockchain is not required, The next question is . If they are not known as the case in a dynamic trustless network, e.g., the Internet, then a is the right way to go. “is the identity of all state-writers known?” permissionless blockchain Otherwise, if the identity is known, then the next question is , if it is a yes, , a database with shared write access is sufficient. Otherwise, if the writers do not trust each other, then the right technology to be used is a . “do the writers trust each other?” then again a blockchain is not needed anymore permissioned blockchain Finally, if it is a permissioned blockchain, depending on whether public verifiability is required, anyone is allowed to read the state (public permissioned blockchain) or the set of readers may also be restricted (private permissioned blockchain). Examples of Applications Lets walk through a bunch of examples here to understand what applications do make sense on blockchains and which don’t and why. Applications that DO NOT need a Blockchain Supply Chain Management Systems¹ This is indeed one of the applications that arise repeatedly in the space. Lets follow the flowchart to identify which technology suits it best. Supply Chain Management: An SCM certainly requires to store data. Multiple writers are involved, i.e. the different participants of the SCM that own a certain share of the final product. Continuing our methodology, a SCM could technically likely always use an online TTP. For example, acknowledged to only require a single source of trust, which would however remove the decentralized component of the blockchain, and thus be equivalent to a trusted central server. Skuchain If that is not possible, at least all writers will be known, which leaves us to choose between a permissioned or no blockchain. SCMs have the inherent problem of the interface between the digital and the physical world. A human, or some machine under the control of a single writer, typically is required to register that a certain good has arrived in a warehouse, and if, for example, its quality is appropriate. If there is no trust in the operation of these employees, then the whole supply chain is technically compromised as any data can be supplied by a malicious writer. If, on the other hand, all writers are trusted, because a regular database with shared write access can be used instead. a blockchain is not needed, Note that if through some technical means, the connection between the digital and physical world could be realized in a secure manner, then the previous reasoning might change. Many have suggested possible use cases for blockchain technology in the Internet of Things (IoT) in combination with smart contracts with the aim to provide autonomous systems that pay for resources that they consume and get paid for resources that they provide. As the system is inherently decentralized with entities that do not trust each other, using a blockchain seems natural. However, as with supply chain management, If computers supply values that were read from sensors to the blockchain, the blockchain does not guarantee the correctness of these values. If only automation is desired, a blockchain may not be necessary if a trusted party can be used instead. Internet of Things: the interface between the physical and the digital world poses a potential problem. Applications Suitable on the Blockchain : For financial applications, blockchain technology seems well suited in general, since parties are generally risk averse and do not want to rely on strong trust assumptions. Following our Interbank and International payments In Interbank payments we have multiple parties (the banks) that act as writers and who want to exchange value and transactions. So there is state to be persisted. The banks are the writers, and hence there is more than one writer. In the case of single currency systems, the central bank can operate as a TTP. Otherwise, there is another setting where the central bank does not want to act as a verifier for every transaction but only act as a certificate authority giving out licenses to banks to participate in the system. This means that all writers of the system are known and we can use a permissioned blockchain Similarly, the exchange of digital goods is likely to be feasible without a trusted dispute mediator and hence it is the perfectly suitable for blockchains, while the exchange of physical goods still requires a trusted third party in case of disputes. Trading and Fair Exchange Protocols: Similarly, E-Voting has properties that blockchains can help with. For example, on one hand, privacy is a main requirement as votes should be anonymous to prevent coercion. On the other hand, e-voting should provide some sort of public verifiability. Due to the requirements, it seems reasonable that blockchain technology can help to achieve these desired properties. E-Voting: Conclusion In contrast to conventional wisdom, Blockchains are not a solution for all technical problems. In fact, they are more appropriate for a class of applications that satisfy a set of requirements. Nonetheless, One should be really careful when being approached by enthusiastic developers and business owners who are strongly biased by the hype and who don’t really question the underlying technicals and necessities of their solutions. In particular, those that sacrifice performance in favour of decentralization and tamper-proof consistent state. many of the “promised” applications are currently still not applicable for the Blockchain, e.g., supply chain management. Until now, it seems that applications that deal with digital goods and services and that require trust are the most appropriate for blockchains. References: 1- Do you need a blockchain? _A blockchain is a digitized, decentralized, public ledger of all cryptocurrency transactions. Blockchain has been…_hackernoon.com Blockchain Explained by Experts - Hacker Noon If you like this post or if you have any further questions or suggestions, please reach out to me on or . Twitter LinkedIn Disclaimer: Information in this article is for educational purposes only and cannot be taken as investment advice.
