Under what conditions do you need to use blockchain?

Translator’s note: The original author of this article is Gideon Greenspan, CEO and founder of the Israeli company Coin Sciences Ltd, which developed the private chain platform multichain.

Blockchain technology is overhyped. I mean, from Sibos to Money20/20, or The Economist to Euromoney, everyone wants to jump on the blockchain bandwagon. Like other companies in the blockchain space, we have received many inquiries from companies wanting to use our platform (multichain) to build proofs of concept and help.

As a young startup, you must think we have already reached the sky. Now we must have raised a large sum of money to build the next generation high-performance blockchain platform we have designed. So what are we waiting for?

In fact, we can patiently discover what benefits blockchain technology will bring to enterprise-level information technology companies. A large part of the projects we help with have nothing to do with blockchain. Why is this so? Big companies heard that blockchain will be the next hot spot, and they found people who are interested in it to study it. Big companies took out some budget and told them to do something that looks like blockchain. Soon these people came to knock on our door, waving dollars in their hands, asking us to help them think of an application scenario. What can you say?

For those who have a project in mind, what’s the problem? In most cases, this project can be perfectly solved with a traditional relational database. You know, the behemoths like Oracle and SQL Server, or for the more open-minded, MySQL and Postgres. So let me be clear:

If the current relational database can meet your needs, then you must be crazy to use blockchain.

Why? Because products like Oracle and MySQL have gone through decades of development cycles. They are deployed on millions of servers running hundreds of billions of requests. They have the most thoroughly tested, debugged, and optimized code in the world, handling thousands of requests per second without taking a breath.

What about blockchain? Our product was one of the first to enter the market. It has been downloaded thousands of times in just five months. In fact, it is very stable. We developed it based on the Bitcoin core. But even so, the entire blockchain product line is still in its infancy.

So am I saying that blockchain is useless? Absolutely not. But before you start that shiny new blockchain project, you have to be very clear about why you are using blockchain. There are certain conditions that must be met. If they are not met, you should go back to the whiteboard. Maybe you can define the project better. Maybe you can save everyone time and money because you don't need blockchain at all.

1. Database

Let's talk about the first principle. Blockchain is a technology that serves shared databases. So you need to know why you use a database, a structured information, from the beginning. It can be a traditional relational database, including one or several tables like database tables. Or it can be the recently popular NoSQL, which is more like a file system or dictionary. (In theory, NoSQL is a subset of relational databases)

The ledger of financial assets can be naturally represented as a database table, where each row represents an asset type owned by a specific entity. Each row has three columns: (1) the owner’s personal identifier, such as an account number; (2) an identifier for the asset class, such as “USD” or “AAPL”; and (3) the number of assets owned.

2. Multiple writers

This is relatively simple. Blockchain is a technology that supports multiple inputs. In other words, more than one entity must generate transactions that change the database. Do you know who these inputs are?

3. Absence of trusts

The third principle. If more than one entity has input into a database, then some level of distrust between these entities is required. In other words, blockchain is a technology based on a database and multiple untrusted inputs.

What do I mean when I talk about distrust? I mean that a user would not want others to modify a database that they "own". Similarly, when reading the contents of a database, a user would not accept the data reported by another user as "truth" because each user has their own economic or political motivations.

4. Cut out the middleman

So the problem, as defined before, is to make it possible to have a database with multiple untrusted inputs. There is already a well-known solution: a widely trusted middleman. This is a person that every input trusts, although they may not trust each other. In fact, this data is full of databases of this nature, such as the general ledger of accounts in a bank. Your bank controls the database and ensures that every transaction is valid and authorized by the customers who participated in the transaction. No matter how hard you ask, your bank will never let you change the database directly.

The blockchain eliminates the need for trusted middlemen by making the database directly modifiable by multiple untrusted inputs. There is no central gatekeeper required to verify transactions and authenticate their origin. However, the definition of a transaction is extended to include authorization and reliable evidence. Transactions can be verified and processed individually by each node, which can maintain a copy of the database.

But the question you need to ask is: do you want or really need to remove the middleman? Depending on your use case, is there really anything wrong with having an intermediary entity maintain a trusted database and act as a gatekeeper for transactions? Reasons to prefer a blockchain-based database over a trusted middleman might include: lower costs, faster transactions, automatic reconciliation, new regulations or simply not being able to find the right middleman.

5. Transaction interaction

So blockchain is suitable for multiple untrusted inputs that directly modify a shared database. But this is not enough. Blockchain really shines when transactions created by multiple inputs interact.

What do I mean when I say interactive? In general, it means that transactions created by different inputs are related to each other. For example, Alice gives Bob a sum of money, and Bob gives Bob a sum of money. In this case, Bob's transaction depends on Alice's transaction, and we cannot verify Alice's transaction without checking Alice's first. Because of this connection, these transactions naturally belong to the same shared database.

Going a step further, a nice feature of blockchain is that multiple inputs can collaborate to create transactions without risk to any party. This makes blockchain unnecessary for middlemen to achieve a situation where each party must fulfill their obligations for the transaction to occur.

A weaker application is when different independent inputs have relationships with each other. An example is an identity database where different entities verify different aspects of a customer's personal identity. While each verification certificate is separate, the blockchain provides a way to bring everything together.

6. Set the rules

This is not an independent condition, but a natural consequence of the previous argument. If a database can be modified simultaneously by multiple inputs, who do not all trust each other, then the database must have built-in rules that constrain how transactions can be performed.

These rules are fundamentally different from the constraints of traditional databases because they are related to the legality of changes rather than the state of the database at a specific time. Every transaction is checked against these rules by every node in the network, and those that fail the check will be rejected and not passed on.

The asset ledger contains a simple example of this rule, to prevent transactions from creating assets out of thin air. This rule states that the amount of each asset in the ledger must be consistent before and after the transaction.

7. Choose your validator

So far we have described a distributed database where transactions can be initiated from multiple locations, propagated in a peer-to-peer manner among nodes, and verified individually by each node. So where does the blockchain come from? Well, the task of the blockchain is to have an authoritative and final transaction log, the contents of which are provably agreed upon by all nodes.

Why do we need this log? First, it allows newly added nodes to calculate the contents of the database from scratch without having to trust other nodes. Second, it solves the possibility of some nodes losing transactions due to system failure or short circuits in information communication. Without the transaction log, this would cause the database of one node to be different from that of other nodes, which would undermine the meaning of sharing the database.

Third, it is possible for two transactions to conflict, resulting in only one being accepted. The classic example is "an asset is successfully spent twice", where the same asset is sent to two different recipients. In a peer-to-peer database without a central authority, nodes can disagree on which transaction to accept, because there is no objective correct answer. By having transactions "confirmed" in the blockchain, we ensure that all nodes reach a consensus on the choice.

Finally, in an Ethereum-type blockchain, the precise order of transactions is critical, because each transaction affects what happens in the next transaction. In this case, the blockchain will define the authoritative order in which things happen, and without this, transactions cannot be processed.

A blockchain is literally a chain of blocks, where each block contains a collection of confirmed transactions. But who is responsible for selecting the transactions that go into each block? In a “private blockchain” suitable for enterprise applications, the answer is a fixed group of validators (“miners”) who digitally sign the blocks they create. This whitelist will be combined with some form of distributed consensus scheme to prevent a small number of validators from controlling the blockchain. For example, multichain uses a scheme called “mining diversity”, in which allowed miners will work in a round-robin manner, while giving a certain degree of tolerance to nodes that do not perform their duties.

Regardless of the consensus scheme used, the nodes responsible for verification have much less power than the owners of traditional centralized databases. Verifiers cannot forge transactions or modify the database in violation of the rules. In an asset ledger, this means they cannot spend other people's money or change the total amount of assets. But even so, verifiers still have two ways to influence the contents of the database:

Transaction censorship: If enough validators collude maliciously, they can prevent a specific transaction from being confirmed in the blockchain, making the transaction permanently forgotten.
Bias. If two transactions conflict, the validator who creates the next block decides which transaction gets confirmed and the other gets rejected. The fair choice is the first transaction seen, but validators can make choices based on other factors without revealing which came first.

Because of these issues, when deploying a blockchain-based database, you need to be clear about who your validators are and why you trust them. Depending on the scenario, validators can be chosen to be: (1) one or more nodes controlled by an organization (2) a core group of organizations that maintain the blockchain (3) every node on the network

8. Back your assets

If you've made it this far, you'll have noticed that I tend to describe blockchains as shared databases, rather than the more common "shared ledger". Why? Because blockchain, as a technology, can be used to solve a much wider range of problems than just tracking ownership of assets. Any database with multiple, mutually untrusting inputs can be built on top of a blockchain, without the need for a centralized middleman. Examples include shared calendars, Wikipedia-style collaboration, and discussion forums.

That said, it seems that blockchains are currently of interest primarily to those who track the movement and exchange of financial assets. I can think of two reasons: (1) the financial industry is responding to the (in retrospect, very small) threat posed by cryptocurrencies like Bitcoin. (2) An asset ledger is a shared database of transactions that are created by multiple, mutually untrusting entities, which is the simplest and most natural application of blockchain technology.

If you do want to use the blockchain as an asset ledger, you need to answer the next more important question: What is the nature of the assets in motion? By this I don’t mean cash or bonds or bills of lading, although those are important too. The question is: Who is the person behind the assets represented on the blockchain? If the database says I have ten units of something, who will allow me to claim sovereignty over those ten units in the real world? Who should I take to court if I can’t convert the assets declared on the blockchain into traditional visible assets?

Of course, the answer will be different for different scenarios. For monetary assets, you can imagine a regulated bank accepting cash and then adding money to a distributed ledger for depositors under blockchain technology. In trade finance, letters of credit and bills of lading will be endorsed by the corresponding importer's bank and shipping company. In the future, we can imagine an era in which corporate bonds in the primary market are directly found on the blockchain for financing.

in conclusion

As I mentioned in the beginning, if your project does not meet every condition, you should not use blockchain. If any of the first five conditions are not met, you should consider the following options: (1) ordinary file storage (2) centralized database (3) master-slave database replication (4) databases that multiple users can subscribe to

If you have met the first five requirements, there is still some work to do. You need to express the rules of your application as transactions in the database. You should feel confident that you have found trusted verifiers and how to define distributed consensus. Finally, if you want to create a shared ledger, you need to know who will endorse the assets represented in the ledger.

About the Translator:
Lu Rou Fan: A non-mainstream programmer working in Silicon Valley, he graduated from Columbia University and Beijing University of Posts and Telecommunications. He has a quirky, interesting, fun and funny personality.