How to understand that before you "half-baked" blockchain

When “chains” and “blocks” still do not guarantee that you have a full blockchain

Almost a year and a half has passed since the moment when most of the representatives of the financial sector “woke up” and began to seriously study the possibilities of closed blockchains, or the so-called distributed registries. From the very beginning, this process was accompanied by a whole avalanche of activities, including research reports, strategic investments, pilot projects and the formation of various consortia. As a result, now no one will be able to blame representatives of the banking sector for not taking the potential of technology seriously enough.

And, of course, the explosive growth of blockchain projects has acted as a driving force for the development of private blockchain platforms on which these projects work. For example, the solution MultiChain over the past year has become more popular three times as the number of web traffic, and the number of monthly downloads or commercial requests. And of course, there are many other platforms, such as BigChainDB , Chain , Corda , Credits , Elements , Eris , Fabric , Ethereum (its closed version), HydraChain and Openchain . And this is not to mention other startups that have developed their own blockchain platforms and have not yet made them available to the general public.

In an environment where companies want to explore and understand new technology, the variety of choices is usually very good. Nevertheless, in the case of blockchains, which continue to remain a rather abstract and poorly understood phenomenon, this abundance has a significant drawback: many of the blockchain platforms currently available do not really deal with the underlying problem, which they would seem , must decide. To understand what kind of problem we are talking about, let's turn to the definition given by Richard Gendal Brown, R3 Chief Technical Officer:

A distributed registry is a system that allows a group of participants, without any trust in each other, to come to a mutual agreement about the existence, nature and development of one or another set of collective facts without having to rely on the help of some trusted, centralizing their work of an outside participant.

Let us give a vivid example: consider several parts of a lego, connected with each other by a thread. If we apply the term “block chain” to this group, will anyone be able to object and point out to us the inaccuracy of such a definition? And yet, such a block chain will not help a group of participants to have safe and direct access to the collective base without a central intermediary. Similarly, many blockchain platforms are engaged in some activity that is very close to processing chains of blocks, but in fact their products do not have all the necessary properties to serve as the basis for a peer-to-peer database.
')

Another chain of blocks that does not help its users to have shared access to the database is the source .

Minimum set of blockchain requirements

In order to understand the basic requirements for a distributed registry, it would be useful to clarify how these systems differ from ordinary databases, usually managed by a single organization. As an example, let's look at a simple tracking system for ownership of a company's stock. Each row is placed in the registry database contains two columns: the identity of the person, such as the name, and the corresponding number of shares.

There are six key aspects in terms of which this system may not fulfill its responsibilities.

• Fake: Transfer of shares from one person to another without the permission of the owner.
• Censorship: Refusal to fulfill any request for transfer of shares in someone's favor.
• Rollback of operations: Cancellation of previously completed transfers.
• Illegitimacy: Change in the total number of shares in the system without the issuer's knowledge or actions on its part.
• Inconsistency: Providing different responses to identical requests from different users.
• Simple: The complete absence of any response to received requests.

The likelihood of each such failure forces shareholders to closely monitor that the middleman on their behalf, the intermediary, really deserves such a high level of trust. Creating an organization worthy of such trust and successful management requires considerable effort and cost.

Blockchains and distributed registries eliminate the need for such kind of centralized database operators, allowing database users to interact directly with each other on the basis of an equal approach. In relation to our example, shareholders could safely keep their shares on the blockchain and make instant direct transfers to each other’s favor, managing them collectively.

All this brings us back to the blockchain platform issue. To be suitable as a basis for a peer-to-peer collective database, the blockchain must protect its members from all six types of failures, i.e., fakes, censorship, undo operations, illegal operations, inconsistency and downtime. Despite the fact that many products on the market meet these requirements, there is still a whole group of solutions that do not fit into this characteristic. I call these blockchains "half raw" because they allow you to eliminate some of the risks listed above, but not all. In each of these projects, there are at least some aspects where users of the database remain dependent on the correct behavior of a single participant in the process — a scenario that blockchain solutions need to be avoided.

Despite the great diversity of such half-bloody blockchains, there are three archetypes that stand out from the general stream as the most common or obvious. In this article, I will refrain from the name of individual projects because I do not want to throw stones at someone’s garden. Nevertheless, it is important to understand that if we want blockchains to gain recognition sooner or later as a full-fledged, understandable and complete product category, it is important for us to learn how to draw a line between half-baked and real solutions.

Single Validator Blockchain

One common approach is to create a blockchain, in which the task of generating blocks of confirmed transactions is assigned to a single network node. Instead of sending out transactions to all nodes of the network, the system sends them to a single node, with the result that instead of an objective process of reaching agreement from the majority of participants, this process becomes dependent on the vagaries of the central node. However, after the generation, each block is still sent to all the others, each of which independently confirms the validity of the transactions contained in it and fixes the new block in its local copy of the registry without the possibility of its subsequent change.

If we consider this type of blockchain from the point of view of our six-point model, it will turn out to be quite a very useful product. Transactions are subject to a mandatory subscription by the node whose funds they affect, so the central validator will not be able to fake them. They are non-refundable, since each node stores its own copy of the “chain”. In addition, transactions cannot be used for prohibited operations, such as creating assets from the air, since each node checks each transaction for authenticity independently and independently of the others. And finally, each node maintains its own copy of the database, so its contents are always readable.

Unfortunately, four of the six points is not enough. A validator node can easily censor individual transactions by refusing to include them in the blocks it creates. And even if the operator of this node behaves as honestly as possible, a system or communication failure can make it inaccessible, which will lead to the suspension of the processing of absolutely all transactions. In addition to this, depending on the settings, the node-validator has the ability to send different blockchain versions to different participants. From the point of view of such characteristics as censorship and work consistency, this type of database still has a single point of failure, on which the performance of all other nodes depends.

There is one platform offering some modified version of this scheme, when blocks are generated centrally by a single node, but are checked by a quorum of specially designated nodes that sign the blocks and thereby complete the process of reaching consensus. In terms of consistency in such systems, the situation is much better. Quorum nodes give their signature in favor of a single version of the blockchain, which, therefore, can be considered authoritative. However, quorum nodes will not be able to help if the block generator wishes to censor transactions or simply lose connectivity to the Internet. Ultimately, the architecture of this type of blockchains boils down to the principle of “head and subordinates”, but not to a peer-to-peer network.

Collective state blockchain blockbuster

Technically speaking, there are many similarities between blockchains and more traditional distributed databases, such as Cassandra and MongoDB. In both cases, transactions can be initiated by a single network node, and information about them should be transferred to all nodes in the process of reaching a consensus on the state of the database and changes made to it. Both blockchains and distributed bases must be able to cope with latency (for example, communication delays due to the distance between nodes) and provide the likelihood that some nodes and / or communication channels periodically experience problems.

Distributed databases have been around for quite some time, so any developer of blockchain platforms can easily figure out the consensus algorithms and strategies they use for general transaction management and conflict resolution. Be that as it may, it is important not to go too far in this comparison because blockchains, unlike the first, always appear before a key and difficult additional condition - the lack of trust between the nodes of the database. While distributed databases provide scalability, reliability, and high performance across a single organization, blockchains must be designed from the start up to be able to overcome such a framework.

Let us return, however, to our six risks characteristic of the database. The distributed database node only takes care of the idle time. For example, about situations when other nodes become unavailable. Under such conditions, the validity of each transaction or message on the network can not be verified, and therefore the facts of falsification, censorship, return, violation of rules or erroneous processing are overlooked. The worst problem from the point of view of such databases is the processing of two simultaneous but valid transactions initiated by different nodes and relating to the same information. Of course, resolving these conflicts is not a trivial process at all. Yet the handling of such situations is much simpler than the “ tasks of the Byzantine generals, ” when some nodes intentionally act in such a way as to undermine the functioning of others.

Secure teamwork with a database outside the framework of trust can be achieved only if all nodes initially belong to any activity with a certain degree of suspicion. For example, every transaction that changes a database must be signed with an individual digital signature, since using a peer-to-peer architecture there is no other way to know where these or other changes started from. Similarly, each incoming message, such as the announcement of a new block, must pass a critical assessment of both the contents of the block and the context of its formation. Unlike distributed databases, here each individual node should not be able to directly and instantly change the state of any other node.

Some “blockchain platforms” were originally developed on the basis of a distributed base, and then adding such “chips” on top of this base that would allow them to better pass for their own in the series of full-fledged blockchain solutions. For example, by grouping transactions into blocks and storing the hashes of these blocks in a database, they try to get some form of immutability. However, in conditions where each node cannot be sure that its list of hashes is not protected from modification by another node, such immutability is easily circumvented.

Black blockchain box in the cloud

The strangest phenomenon I have ever seen is blockchain platforms, access to which can only be obtained through the acquisition of a cloud platform-as-a-service service, located on the developer’s side. I’ll clarify right away and say that this is not about the decision of some sector participants to choose cloud providers, such as Microsoft Azure or Amazon Web Services, as a platform for their nodes. We are talking more about blockchains, which can be used only through an API accessible from the servers serving the company’s blockchain.

Suppose, for the sake of dispute, that a centralized blockchain provider really possesses a group of nodes working under its control. But what does this change for system users, who in this case can only send API requests and receive answers to them? They actually have no way of assessing errors or omissions arising in the processing of transactions. As a result, the situation in which the central service may work incorrectly, as well as deliberately censor or roll back individual transactions, becomes real. But even if you believe that the blockchain provider has no reason to do this, why not use this service to store the most common centralized database instead? You will get a more mature product with better performance, eliminating any risks associated with working with new technologies. In short, centralized blockchains are as useful as a few lego pieces, connected together by a single thread.

Riddles and their solution

So, we have just considered three types of platforms positioning themselves on the market as “blockchains”, actually applying “blocks and chains” in practice, but not providing, however, solutions to the fundamental task for which they were originally invented. In short, its essence is to create conditions for secure collective work with the database in the absence of any trust and central intermediary.

In addition to the story itself about this curious phenomenon, I think it would be instructive to also consider what may be its basis. Why do so many blockchain startups create products that are incapable of keeping promises related to this technology? Why do they stop at the level of traditional centralized or distributed databases? Why do so many talented people waste so much of their time?

Here I see two main directions of reasoning - technical and commercial. From a technical point of view, the creation of a distributed system to achieve a consensus that can withstand the unpredictable and harmful behavior of one or several nodes is not an easy task. In the case of MultiChain, the developers cheated a little, taking as a basis for the development of a Bitcoin reference implementation tested in combat conditions, and later, replacing the “proof of work” mechanism with a structurally similar consensus algorithm called mining diversity. Commands involved in the development of blockchain nodes from scratch should properly consider asynchronous and adversary processes, and this is such a combination, experience with which not all programmers have. I perfectly understand the desire to succumb to the temptation and go along a shorter path, concentrating, for example, the generation of blocks “in the hands” of one node. Similarly, the desire to create a variation on the theme of modern distributed databases or to launch "combat" nodes only in a trusted environment is understandable. The choice of any of these approaches, without any doubt, simplifies the life of developers, even if such a decision affects the final practical benefits of the project.

As for commercial reasons, here every startup is looking for its own approach in order to get the most out of Blockchain as a business idea. Coin Sciences, for example, distributes MultiChain for free, while at the same time providing the possibility of developing premium sites with additional functionality. Other startups want to sell subscription services and therefore, as is customary in such models, they create platforms that customers cannot fully accommodate in their own environments. Some hope to manage blockchains centrally or help their partners exercise such control (which, of course, sounds very strange, considering that this is a technology that eliminates intermediaries) and therefore, for obvious reasons, they choose consensus algorithms that rely on a single node. Finally, there are companies whose main goal is to sell consulting services. They do not need their own functioning platform as long as their website continues to attract some large customers.

Another possible problem is that the managers of some blockchain companies - people, of course, very talented - simply lack a deep understanding of the technology as such. Yet in startups that form new areas and markets, key strategic decisions must be made by people who understand the nature of the technology well and are able to appreciate the difference between it and its counterparts. The history knows a lot of examples of startups that have themselves cornered themselves, trying to keep up with an attractive for their customers, but unrealizable vision in practice.

As a blockchain user, how can you avoid the same mistakes? When evaluating a blockchain platform, always ask if it fulfills the six main requirements that are true for each secure peer-to-peer collective database: prevention of downtime, identical results of processing identical transactions, availability of mechanisms to protect against counterfeit, censorship, transaction rollbacks and legitimacy violations. And, of course, be very careful if in reply you hear muffled mutter or active gesticulation with your hands: most likely, all this will mean “no”.