Illustration | Which projects are suitable for blockchain? What is not suitable?

Foreword: What is the blockchain suitable for and what is not suitable for doing? It has always been controversial. So, by what way to identify it? This article uses a detailed flow chart to deal with this problem. The author of this article is Mohammed ElSeidy, translated by the "Xin Xin" of the "Blue Fox Notes" community.

The hype surrounding the blockchain has greatly exaggerated the practical capabilities and applications of this new technology. This enthusiasm makes it difficult for companies, developers and investors to understand their actual limitations and find the right application for a blockchain or distributed ledger technology.

Karl Wüst and Arthur Gervais from ETH Zurich recently published a peer-reviewed paper that proposes a structured approach that helps determine a reasonable technical solution for how a particular application problem should be solved. In this article, we will introduce this method and explain some of the examples used in the paper.

Technical comparison

• Ethereum co-founder Joseph Lubin: EOS is too central, only Ethereum can be used as a global settlement
• Viewpoint | Vitalik: Radical Market, ZK, Privacy and more
• Talk about (public key) cryptography entry materials

Different types of state persistence comparisons

A blockchain is a "additional only" book that is persistent (save). The status can be transaction information, program data, or hashed documents, and so on. Basically, it is any information that needs to be persisted. The database has been in this task for decades. In addition, the blockchain represents a new state persistence technology – and includes additional features such as digital signatures and tamper resistance. Let's revisit the three main technologies:

Database

First, databases (single, parallel, or distributed) have been used to persist state and query data for decades. A lot of valuable research has been used to optimize query processing and state persistence at different levels.

• Naturally, they have the highest performance in terms of transaction throughput and query latency.

• However, they have long been designed as a centralized management of a single institution. Therefore, there is no need for a consensus mechanism between different parties.

2. Public chain (Permissionless Blockchains)

A public chain is a public ledger (state) that is not managed by a centralized organization. That is to say, the books are distributed in a dynamic P2P network, and there may be malicious nodes in the network.

• Nakamoto's wisdom lies in designing a mechanism for maintaining consensus in a distributed state and in a dynamic and untrusted network. This means that the public chain can tolerate a small amount of Byzantine or untrustworthy behavior in the network.

• Everything comes at a price and there is a trade-off in performance overhead (throughput and latency). In Bitcoin, the sharp performance degradation is due to the very slow design of the POW protocol itself. In any public chain, performance degradation is inevitable compared to a normal database. Because, in any case, to maintain the consistency of the distributed state, communication between different nodes in the (geographically distributed) network is necessary.

3. Alliance Chains (Permissioned Blockchains)

The alliance chain represents a hybrid design choice. In particular, they are not a single centralized entity, but are authorized to a small number of pre-selected trusted nodes that can be written to.

• Because the database network does not scale to a large number of public nodes, its throughput and latency are much better than the public chain.

• Still, its performance is still not comparable to a centralized database.

After reading these different systems, it's easy to realize that there isn't a solution for all scenarios. Everything needs to be chosen. Different applications have different needs and therefore require different suitable solutions.

"Do you need a blockchain?"

Select the flow chart for the correct technical solution. TTP (Trusted Third Party) represents a trusted third party, and the writer is an entity that can write state to a database or blockchain.

This section describes a common high-level flow chart in the paper to find the right technology for your application. Note that the writer is an entity that can write state to a database or blockchain.

1. If your application does not require a persistent state, then obviously no blockchain or any database is needed.

2. Similarly, if there is only one writer in the write state, the blockchain does not provide additional protection compared to the regular database. Conversely, the database may be more efficient from a performance perspective.

3. Otherwise, if there is more than one writer in the write state, we choose another path. The question becomes whether there is an online TTP (trusted third party) is enough, or in other words, whether tampering is needed. If the application cannot rely on a single trusted entity, we can further analyze whether a blockchain is needed. Otherwise, there is no need to use a blockchain, and it is more efficient to rely on a centralized entity from a performance perspective.

4. The next question is "Is the identity of all writers in the write state known?". If the identity is unknown because of an untrusted dynamic network, such as the Internet, then the public chain is the right choice.

5. Otherwise, if the identity is known, then the next question is "Do these writers trust each other?". If so, then no blockchain is needed, and it is sufficient to use a database that provides shared write access. Otherwise, if the writers don't trust each other, then the most appropriate technology is the alliance chain.

6. Finally, if it is a coalition chain, depending on whether public verifiability is required, anyone is allowed to read the state (open chain of alliances) or only a small number of restricted users (private alliance chains).

Applications

Let's use some examples to understand what applications really need blockchain, what not needed, and why not.

No need for blockchain applications

Supply chain management system

• Supply Chain Management (SCM): This is indeed a recurring application. Let us follow the flow chart to find the best matching technology.

1. SCM does need to store data.

2. Involves multiple writers, that is, different participants who have certain parts of the final product.

3. Continuing our approach, SCM is technically likely to always use an online TTP. For example, Skuchain recognizes that only a single source of trust is needed, but this removes the decentralized component of the blockchain, so it is equivalent to a trusted centralized server.

4. If that doesn't work, at least all of the writers are known, leaving us with only the alliance chain or not using the blockchain.

5. SCM has consistency issues in the interface between the digital and physical worlds. Usually a person or some machine controlled by a single writer is required to register an item arriving at the warehouse, if the quality is not a problem. If the operations of these employees are not credible, then the entire supply chain is a technical compromise because malicious writers can provide arbitrary data. On the other hand, if all the writers are trusted, then the blockchain is not needed, because a regular database that provides shared write access is used.

Note that if the connection between the digital and physical worlds can be achieved in a secure manner through some technical means, the previous arguments may change.

• Internet of Things: Many people have proposed possible use scenarios for blockchain technology on the Internet of Things (IoT), providing an autonomous system for the payment and consumption of resources through smart contracts. Due to the inherent decentralization of the system, entities don't trust each other, and using blockchains seems natural.

However, as with supply chain management, the interface between the physical and digital world creates potential problems. If the computer supplies the values ​​read from the sensor to the blockchain, the blockchain cannot guarantee the correctness of these values. If you just need automation, there is no need to use a blockchain, you can use a trusted party instead.

Suitable for blockchain applications

Inter-bank and cross-border payments: For financial applications, blockchain technology is generally appropriate because participants often want to avoid risk and do not want to rely on strong trust assumptions.

1. In a cross-bank payment, a multi-party (bank) writer and a subject who wants to exchange value and transactions. So the state needs to be persisted.

2. Banks are all writers, so there is more than one writer.

3. In a single currency system, the central bank can act as a TTP.

4. Otherwise, there is another configuration. The central bank does not want to act as a verifier for each transaction. It only wants to act as a certification authority to issue licenses to banks to participate in the system. This means that all the writers of the system are known, we can use the alliance chain.

• Trade and Fair Dealing Agreements: Similarly, transactions in digital goods are likely to not require a trusted dispute mediator, so it is well suited to use blockchains, while physical goods still require trusted third parties to resolve disputes.

• Electronic voting: Similarly, electronic voting also has attributes that blockchains can come in handy. For example, on the one hand, privacy is a major requirement because voting must be anonymous to avoid being coerced. On the other hand, electronic voting needs to provide some public verifiability. Because of these needs, it seems reasonable to use blockchains to help get these desirable attributes.

in conclusion

 

Contrary to traditional wisdom, blockchain is not a solution to all technical problems. In fact, they are more suitable for a certain type of application that meets a set of requirements. Especially those applications that would sacrifice performance in exchange for decentralized and tamper-resistant consistency.

Despite this, many "committed" applications are still not suitable for blockchains, such as supply chain management. We need to be vigilant when it comes to those fanatical developers and entrepreneurs who follow the trend and don't really think about the underlying technology and necessity of their programs.

Until now, digital goods and services with trusted needs seem to be the most suitable application scenarios for using blockchains.

——

Risk Warning: All articles in Blue Fox Notes do not constitute investment recommendations . Investment is risky . Investment should consider individual risk tolerance . It is recommended to conduct in-depth inspections of the project and carefully make your own investment decisions.

We will continue to update Blocking; if you have any questions or suggestions, please contact us!