How to understand whether to integrate blockchain into your product?

Blockchain technologies are currently too bloated. Everybody writes and speaks about him: from the Sibos and Money20 / 20 conferences to popular materials in The Economist and Euromoney publications - it seems that everyone is trying to grab their share of the gold blockchain-fever.

How to determine that you have a real case of blockchain technology? We in Web-payment.ru write a lot about the technology of the distributed registry, and by the nature of our Digital Agency’s activity at Fintech, we notice that the issue raised is very relevant for many market players. This article, published on the open platform blog for creating your blockchains MultiChain , is designed to help you figure this out.

A huge number of projects coming to MultiChain has nothing to do with blockchain technology at all. Everything happens according to the following scenario. A big company finds out that blockchain is the technology of the future. A large company finds people from outside who work with banking technologies to convert bitcoin cryptocurrency. A large company allocates them a budget and orders them to do something blockchain. And soon these craftsmen come to MultiChain and, waving money, ask us to help them invent some kind of usage scenario.

And what is wrong with those who really have a project idea? Very often, a project can be wonderfully implemented using a conventional relational database. These are iron monsters like Oracle and SQL Server, and for the less biased, MySQL and Postgres. So let me start by dotting all the i's:
')
If modern relational databases meet your requirements, then you need to be crazy to use blockchains.

Why? Because products like Oracle and MySQL have been tested for decades. They were installed on millions of servers that handle trillions of requests. Their code was most thoroughly tested, optimized and debugged in comparison with others on planet Earth. They, without straining, process thousands of transactions per second.

So what about the blockchain? There are products that have become the pioneers of the market and are distinguished by relative stability. But despite this, all the products in this category, figuratively speaking, are still sitting in diapers.

Am I trying to prove that blockchain technology is useless? No, not at all. But before you run into such an advanced and brilliant blockchain project, you need to develop a clear understanding of why you are using the blockchain . There are several conditions that must be met. And if not, then you should return to the design stage. Maybe you could better define and describe the project in more detail. Maybe you can save for all tons of time and money, because you don't need the blockchain technology at all.

1. Database

Here is the first rule. Blockchain is a technology for public databases. Therefore, you should start by understanding why you are using the database. Here I mean a structured repository of information. This can be a traditional relational database with one or more spreadsheets. Or it could be more trendy NoSQL databases that work more like file systems or dictionaries. (In any case, in database theory, NoSQL is a subset of relational databases.)

The register for financial assets can usually be expressed as a database table, in which each row represents one type of asset belonging to one specific entity. Each row contains three columns containing: (a) an owner identifier, for example, an account number; (b) an asset type identifier, for example, “USD” or “AAPL”; (c) the number of units of the asset in the account of a particular owner

Databases are modified using “transactions”, which are a set of changes in the database that must be accepted or rejected. For example, in the case of asset accounting, payment from one user to another is represented by a transaction that subtracts the appropriate amount of funds from one line and adds it to another.

2. Many authors

This is a simple rule. Blockchain is a technology for databases with many authors. In other words, there should be more than one entity that generates transactions that modify the database. Do you know who these authors are?

In most cases, authors will also support nodes that contain a copy of the database and relay transactions to other nodes in peering mode. However, transactions for starting a node themselves can also be created by users who do not support nodes. Consider, for example, a payment system that is collectively supported by a small group of banks, but has millions of end users with mobile devices that interact only with the system of the bank they have chosen.

3. Lack of trust

And now for the third rule. If several entities change the database, then there must be a certain mistrust between them. In other words, blockchain is a technology for databases with multiple authors who do not trust each other .

You might think that distrust arises only between individual organizations, such as banks or companies involved in the supply chain. But distrust also appears within a single large organization, for example, between departments or when conducting operations in different countries.

What exactly do I mean by the lack of trust? I say that one user does not want another user to modify the rows in the database that "belong" to him. Similarly, when it comes to reading the contents of a database, the user will not take on faith the "truth" of another user, because each of them has different economic or political motivations.

4. Transactions without intermediaries

So, until now the problem was that numerous authors have access to the database who do not trust each other. But there is a well-known solution to this problem: a trusted intermediary . This is the one whom all authors trust even taking into account the fact that they do not trust each other. Indeed, the world is full of such databases, and these include registries of accounts in banks. Your bank controls the database independently and ensures that each transaction is valid and is performed by an authorized user, whose funds are transferred from the account to the account. And no matter how politely you ask, your bank will never allow you to directly make changes to its database.

The blockchain cuts off the need for trusted intermediaries, allowing many authors who do not trust each other to directly make changes to the database . There is no authority checking the validity of transactions and the authenticity of their sources. Instead, the definition of a transaction is extended and includes proof of authorization and proof of validity. Thus, transactions can be independently verified and processed by each node that has a local copy of the database.

But here's a question you should ask yourself: do you want and need refusal from intermediaries? If you take your case, do you really get in the way of a central organization that maintains a trustworthy database and acts as an intermediary in transactions? Good reasons for rejecting a trusted intermediary in favor of blockchain databases are, for example, large cost savings, faster transactions, automatic reconciliation of accounts or the inability to find a suitable intermediary.

5. Transactional Interaction

So blockchain technology is good for databases with many authors who do not trust each other and who directly modify the database. But this is still not enough. Blockchain fully pays for itself when the transactions created by these authors interact with each other.

What do I mean by interaction? This is when transactions created by different authors often depend on each other. For example, let's say Alice sends funds to Bob and then Bob sends funds to Charlie. In this case, Bob’s transaction depends on Alice’s transaction, and there is no other way to verify Bob’s transaction without first checking Alice’s transaction. Due to this dependency, together these transactions belong to a single distributed database.

Developing this topic, a remarkable feature of the blockchain is that transactions can be created jointly by many authors , while no one takes the risk. This is what allows us to solve the problem of the order of payment without the need for a trusted intermediary.

A less visual case of interaction is when transactions of different authors correlate with each other, while remaining independent. One example would be a distributed database with personal data, in which a multitude of entities confirms various aspects of consumer identities. Despite the fact that each of the checks is done separately, the blockchain allows the user to merge all the changes.

6. Setting Rules

This is not a condition, but rather an inevitable consequence of previous conditions. If we have a database in which many authors make changes, and these authors do not fully trust each other, then this database should provide for the rules according to which the transactions are conducted .

These requirements are significantly different from the restrictions that exist in traditional databases, because they relate to the legality of transformations, and not the state of the database at a particular time. Each transaction is checked by each node in the network for compliance with these requirements. Those transactions that do not meet the requirements are rejected before.

Asset books contain a simple example of this type of rule to prevent transactions creating assets from scratch. According to this requirement, the total number of each asset in the registry remains unchanged before and after each transaction.

7. Choose your validators

So, we have described a distributed database in which transactions can come from different sources, spread from one node to another, and be checked by each node independently. So what does the blockchain do? Here the work of this technology is to be a trustworthy final version of the transaction log, with the content of which all nodes agree , and this can be proved.

Why do we need this magazine? First, it allows newly added nodes to calculate the contents of a database from scratch and without having to trust another node. Secondly, this provides for the possibility that some nodes may skip some transactions due to communication failures. Without a transaction log, this would cause the database of one node to be different from the others, which is contrary to the purpose of the distributed databases.

Third, there is the possibility that two transactions conflict, and only one of them can be accepted. A classic example of this is double waste, in which the same amount of funds is sent to two different recipients. In a peer-to-peer database without a central administrator, nodes may have different opinions about which transaction to accept, because in this case there is no objective correct answer . By demanding confirmation of transactions in the blockchain, we guarantee that all nodes will agree with a single solution.

And finally, in Ethereum blockchains, the exact order of transactions plays a decisive role, since each transaction can affect the next one. In this case, the blockchain determines the chronology of events, without which transactions cannot be processed.

A blockchain is a chain of blocks in which each block contains a set of transactions confirmed as a group. But who is responsible for choosing the transactions that go into each block? For “private blockchains” that are suitable for corporations, this is a closed group of validators (miners) who leave a digital signature in the blocks they create. This white list is combined with the distributed consensus scheme in order to prevent the validator from gaining control over the blockchain minority.

Regardless of which consensus scheme is used, the validator nodes have far less power than the administrators of a traditional centralized database. Validators cannot fake a transaction or modify a database against rules. When it comes to asset accounting, this means that they cannot spend other people's money or change the total number of assets represented. However, there are still two cases where validators may inappropriately affect the content of a database:

• Transaction Validation If a sufficient number of validators collude, they can prevent the confirmation of a particular transaction in the blockchain, permanently leaving it in the pool of unconfirmed transactions.
• Biased conflict resolution. If the two transactions conflict, the next block validator decides which transaction in the blockchain will be accepted, and which as a result will be rejected. A fair choice is a transaction that appeared earlier, but validators can base their choice on other factors without showing it.

Because of these problems when deploying blockchain databases, you should have a clear idea of who your validators are and why you trust them . Depending on the case, validators can be selected as: (a) one or several nodes managed by a single organization, (b) the main group of organizations that support the chain, or (c) each network node.

8. Secure your assets

If you’ve read this article, you might have noticed that I’m rather referring blockchains to distributed databases, rather than to “distributed account books,” which is more common. Why? Because as a technology, blockchain can be applied to problems that lie beyond the tracing of ownership of assets. Any database that has many authors who do not trust each other can be implemented via the blockchain without the need for a trusted intermediary. Examples include distributed calendars, forums, and collaborative projects such as Wikipedia.

At the moment, blockchains are mainly of interest to those who track the movement of financial assets. In my opinion, there are two reasons for this: (a) the financial sector responds to the (still very insignificant) threat of such cryptocurrencies, such as Bitcoin, and (b) the asset book is the simplest and most natural example of a distributed database with interdependent transactions created by many entities that do not trust each other.

If you want to use the blockchain for asset accounting, you need to answer another important question: what is the nature of these assets? I do not mean cash, bonds or bills of lading, although this is also very important. The question is rather who is behind the assets represented on the blockchain ? If the database has information that I own 10 units of something, who will allow me to claim these 10 units in the real world? Who can I sue if I cannot convert what I have in the blockchain to traditional physical assets? (See example asset agreement )

Of course, the answer to this question depends on the specific application. For example, for monetary assets, custodian banks can take cash in the traditional form and then transfer funds to user accounts in a distributed accounting system created on the basis of the blockchain. In the area of ​​trade finance, letters of credit and bills of lading can be provided by the importer’s bank and transport company, respectively. It is likely that in the more distant future, the main issue of corporate bonds will be carried out directly with the help of the blockchain by a company seeking to raise funds.

Conclusion

As I mentioned in the introduction, if your project does not satisfy at least one of these criteria, you should not use the blockchain. If one of the first five conditions is not met, then you should use one of the following solutions: (a) regular file storage, (b) centralized database, (c) replicated database, (d) several databases with a subscription for users.

And if the first five conditions are met, this is not all - you will need to designate the rules of your application in terms of transactions allowed by the database. You must be confident in your validators and in your distributed consensus mechanism. Finally, if you are going to create a distributed asset accounting system, you need to know who will provide these assets.