Blockchain for distributed ledger

[Tomcat]

This article is not about cryptocurrency, but about blockchain and the set of technologies and ideas that, in my opinion, will help create a fast, scalable and secure distributed ledger (DLT). Simple DLTs can be created using the smart contract capabilities of second- or third-generation blockchains, but more complex ledgers may require alternative solutions. An example of a fairly complex and specific DLT would be a decentralized public payment system compatible with government monetary policy, that is, a platform for “digital money.” The implementation of such a project using smart contracts is hardly possible. Therefore, in this article I propose to consider AppChain, a hybrid application and blockchain platform, for this role .

AppChain has a number of advantages over smart contracts. First, AppChain allows you to implement complex and specific business logic, which may be difficult or impossible to do with smart contracts. Here you will have all the power of your favorite programming language at your disposal. Second, AppChain provides higher performance and scalability because applications run in the operating system environment rather than in the blockchain smart contract execution environment. Third, AppChain can provide a higher level of security than smart contracts if implemented equally well, since it will be less dependent on vulnerabilities in the execution environment.

The application in this combination is domain specific and will likely require development from scratch. Blockchain is not ordinary; this class of software is called “Application specific blockchain”. There are several well known projects that can be used as a basis. The most famous is probably Hyperledger Fabric. But Tendermint seemed more interesting to me from the point of view of the application interface and the possibility of expanding its functionality.

Tendermint​

Tendermint is known for being the basis for the Cosmos SDK, with the help of which the third generation blockchain ecosystem of the same name (ATOM coin) is created. The figures below illustrate the architecture of the Cosmos SDK framework and AppChain. They were taken from an article that covers the topic of the Cosmos ecosystem well .

Tendermint is highlighted in green. The other color in the first case is Cosmos SDK, in the second - AppChain.

Looking at these illustrations, the question arises: why not use the Cosmos SDK? Cosmos SDK is already smart contracts, but we need a lower level. Our application will interact with Tendermint directly using the ABCI (Application BlockChain Interface) protocol. The physical implementation of this protocol allows the application to be implemented using different methods. It can be in the form of a Golang module that is linked with the Tendermint code into a single executable file. Or it will be a separate application, written in any common programming language, interacting with the Tendermint blockchain node through several network connections.

Tendermint provides basic blockchain capabilities, but they are as general as possible and do not impose a number of serious restrictions on the application. For example, a transaction is not specified and can be represented by any byte array, the structure of which is determined by the application logic. In addition, the consensus mechanism is very flexible, and is achieved through the Byzantine Fault Tolerant ( BFT ) protocol, with a limited list of validators specified in the genesis block and can be changed by the application.

High-level logic has been removed from the platform, which allows you to create applications that make maximum use of the blockchain's capabilities with minimal restrictions.

Identification, Authentication, Authorization​

There is a good reason why Bitcoin and other classic blockchains will not become full-fledged payment systems. Trade and services are controlled by the government to ensure that taxes are collected. To determine how much each person should contribute to the treasury, it is necessary to identify payers and recipients, sellers and buyers, employers and employees. In other words, identification is required to uniquely link transactions and distributed ledger records to taxpayers. And where there is identification, there is authentication.

For classic blockchains, they are trying to do this through the control of exchanges and exchangers, introducing KYC and AML. This solves the income tax problem when exchanging cryptocurrency for traditional money, but not the turnover tax problem. Or it will be very difficult to do. It is possible to analyze the transaction chains of a Silk Road dealer, but tracking the transactions of a large retail chain is almost impossible.

In addition, it is necessary to implement banking secrecy, where only those who are supposed to can see other people's transactions. And this is only part of such tasks. Therefore, authentication is required.

In other words, if we want to create a national payment system, identification, authentication and authorization are necessary.

Distinguished names are good for identification , for example: CN = Vasily, STREET = Vasily's Farm, L = Nizhniye Bubentsy, ST = Zalesye, C = Our Country. I think many have encountered them in LDAP and x.509 certificates . By the way, certificates are one of the mechanisms used to authenticate distinguished names. Considering that the x.509 standard of the third version (Extended Key Usage) allows you to store arbitrary objects in the body of the certificate, the issue of a simple solution for authorization will be resolved. For something more complex, you can use attribute certificates.

Consensus mechanism​

As mentioned, Tendermint uses the Byzantine Fault Tolerant (BFT) protocol. However, in order to reach consensus and determine the state of the blockchain, the application must define a list of validators that will participate in this process. Accordingly, the algorithm used to compile this list is implemented in the application.

In our case, this is the PoA (Proof of Authority) algorithm. In short, in PoA, transactions are confirmed by those who are entitled to it, not by those who spend more hashing power (PoW) or who have more coins (PoS). To determine who is eligible, we will use certificates by analyzing the distinguished name and/or additional attributes in them.

Public Key Infrastructure​

It is already clear that X.509 certificates can simplify the task. However, they require a public key infrastructure (PKI) to be used. PKI is based on a public key cryptographic system. What is the basis of blockchain security? A similar public key cryptographic system. This means that users using the distributed ledger will have a key pair. All that remains is to associate the user's public key with his distinguished name through the issuance of a certificate. After which, all of his transactions and records in the distributed registry will be uniquely associated with him.

The minimum required components of a PKI are a Certificate Authority (CA) and a repository that stores two lists: "Issued Certificates" and "Revoked Certificates". The repositories will be stored in our distributed ledger entries. CA functions will be performed by the corresponding subsystem in our application. On nodes where a certification authority certificate will be present, this subsystem will operate in CA server mode, and on all others - in CA client mode. This way we get a Distributed Public Key Infrastructure (DPKI).

Hierarchies​

Distinguished names can consist of components of multiple hierarchies. Most often this is:

• Location hierarchy represented by the attributes "C" (country), "ST" (region), and "L" (city).
• The hierarchy of an organization, represented by the attributes "O" (organization) and "OU" (organizational unit).
• The network hierarchy represented by the "DC" (domain component) attribute.

Consider the distinguished name: CN=First Wonderland CA+DC=node01,OU=Data center,L=Cheshire,C=WN+DC=wn,O=The Corporation+DC=thecorp. It is quite unambiguous; all three hierarchies can be distinguished:

• CN=First Wonderland CA,L=Cheshire,C=WN
• CN=First Wonderland CA,OU=Data center,O=The Corporation
• DC=node01,DC=wn,DC=thecorp - easily converted to FQDN node01.wn.thecorp

They not only uniquely identify an object, but also provide an idea of the object's ownership, location and network address.

Below is a graphic that illustrates the hierarchies and location of an object with the example distinguished name. The network hierarchy is not shown so as not to overload the diagram.

Network segmentation​

The problem with the first and second generation blockchains was and remains the lack of scalability, which negatively affects the speed of transaction processing and storage sizes. However, in third-generation blockchains this problem is partially solved by using variations on the "sidechain" theme. Sidechains are a problem-oriented blockchain that has a channel of interaction with one of the base blockchains. A good example would be a blockchain used to store the state of an online game. Most of the transactions that determine changes in the game world are serviced on its own network. Only a small part of transactions responsible for the input/output of financial assets (for example, ETH) enter the mainchain network (Ethereum) and are serviced there.

I think many people remember the game Cryptokitties, which at the peak of its popularity almost finished off the Ethereum network. In this game, all game actions were served by Ethereum smart contracts and generated a large number of transactions on the Ether network. And if this were implemented on the sidechain, as described above, no one would even notice the activity of digital cat lovers.

Thus, the introduction of sidechain can solve the problem of blockchain scalability and make it more efficient in processing transactions. Hierarchical sidechains may provide a more efficient solution to this problem.

Let's go back to the picture above. The areas outlined by dotted lines are sidechains. The higher levels will be the mainchain for the lower ones, but at the same time they will be the sidechain for their higher ones. In this way, a hierarchical network segmentation will be obtained. From now on I will call them segments. Transactions on objects in one segment will not go beyond its boundaries and be sent to another segment of the same level. If the architecture of hierarchies is designed correctly, such transactions will prevail. Cross-segment transactions will be validated by more complex algorithms. Obviously, all segment validators along the ascending and descending branches of the hierarchies that logically connect the objects participating in the transaction will participate in their confirmation.

For example, consider the situation: farmer Vasily returned the million “digital rubles” he borrowed. The branch of the bank that issued the loan is located in another locality, but in the same area. Part of the bank branch's profits is sent to the head office located in another area. The network diagram is detailed in the figure below. A red cross indicates a physical lack of communication between segments.

It can be seen that there are no obstacles to fixing the transaction from Vasily. In the metropolitan segment, no one needs this information, and it does not get there. But in the segment where the bank branch is located, this transaction must fall, and the validators of this segment must confirm it.

The second transaction will hang at the level OU=Zalessky branch, ST=Zalesye, O=Bank, C=Our country. If the connection is restored before the transaction processing timeout expires, the transaction will be processed late. Otherwise, an error will occur that the application will have to process using the appropriate algorithms.

That is, in the event of physical accidents, segments below the break point will work normally with transactions whose execution route does not pass through the emergency section.

Maintaining functionality in the absence of a network​

It is known that purchases can be made using “digital yuan” even without an Internet connection. I hope that this functionality will be available for the “digital ruble”. It is unknown how the Chinese implemented this, but I believe it may be a method similar to the one described below.

Let's imagine that a merchant named Gennady is going to visit farmers and buy products from them for resale. Both Gennady and the farmers have payment terminals, or rather, a program with our payment system. However, there is not always a connection. Let's see how we can solve this problem. First, let's define the conditions:

• Gennady has a certificate certifying his personal public key (account) in our payment system, and accordingly, has an entry in the registry confirming that he has a certain amount of “digital rubles”.
• According to bank secrecy regulations, the information is encrypted and accessible only to the bank, Gennady and the tax authorities. The bank also has a certificate certifying it as a subject of the payment system. In this case, he will act as an intermediary, guaranteeing the availability of funds in Gennady’s digital account. In principle, tax authorities could act as such an intermediary.

To be able to pay offline, you must complete the following steps online:

• Gennady must create derived keys and a corresponding registry entry based on his primary key pair. This object/account will be called "Gennady's Checkbook".
• Gennady then transfers a certain amount from his main account to this new account.
• Gennady’s main account is encrypted, and only the bank can verify the presence of the required amount on it.
• The bank issues confirmation in the form of a certificate to the public key (address) "Gennady's Checkbook" indicating the amount that was credited to it. This could be implemented as a v3 extension for the certificate.

Thus, we receive an electronic analogue of a checkbook, the owner of which is known and confirmed by a certificate. The initial amount of the checkbook, confirmed by a certificate signed by the bank, is also known. When paying offline, Gennady generates and signs a transaction for the required amount from the checkbook account, assigns it a serial number and transmits it via a QR code to the payment terminal of the payee. This will be equivalent to handing over a completed and signed check from the checkbook. The recipient will probably want to make sure the checkbook is correct. To do this, it is enough to transfer locally from terminal to terminal (using the same QR codes or in another way) Gennady’s certificate, a checkbook account certificate and, possibly, information about the numbers and amounts of previous transactions.

It is clear that without checking over the network, one cannot be sure of the correctness of transactions for “double spending”. However, such an action is actually counterfeiting a checkbook and leads to natural legal consequences.

As soon as farmers have access to the network, Gennady’s signed transactions are sent for processing. Funds are credited to farmers' accounts. After this, Gennady returns the balances to the main account, creating a corresponding transaction that closes Gennady’s Checkbook.

GOST cryptography​

When aiming to create a national payment system, it is important to take into account the following factor. The cryptographic algorithms used must be certified by the competent authorities. In Russia, the following algorithms are defined:

• GOST R 34.11-2012 - Formation of hashes of 256 and 512 bits.
• GOST R 34.10-2012 - Digital signature based on elliptic curves; key size 256 and 512 bits; hashing function GOST R 34.11-2012.
• GOST R 34.12-2015 - Block cipher “Grasshopper”; key size 256 bits; block size 128 bits.

Tendermint uses cryptographic algorithms: sha256, ed25519. Support for secp256k1 is also announced. All cryptographic functions are collected in a separate package. Tendermint does not have a well-developed interface that allows you to use different algorithms, like Hyper Ledger Fabric. Therefore, its “state registration” will be more difficult than the “state certification” of HLF, but it is quite feasible.

In custody​

The topic is very interesting. For quite some time now, with pauses, but I have been studying this direction. “With pauses,” because money does not bring itself into the family. You can try to combine business with pleasure and get a job in a company that develops distributed registries. You can try, but it’s not a fact that you will be able to find it. There are companies that are doing this seriously and for a long time, but technical information about the projects is practically not publicly available. What we have been able to find out indicates that they are developing their distributed registries based on smart contracts on a modified Ethereum. It is clear that if they started work 4-5 years ago, then there were no special options. But this is not the same, not the same.

Many companies have successfully used Hyperledger Fabric, but they use it to solve specific customer problems. But the temptation is great to make your own Hyperledger Fabric with hierarchical segmentation and DPKI. Companies that officialize something fashionable and declare it a national platform for issuing tokens and NFTs can only be mentioned for show.

One of the purposes of writing this article is to find like-minded people. Habr, not quite the right place for such material. But the articles published here are well indexed, so maybe it will work someday.

It is impossible for one person to create a complete solution based on the ideas described above. For example, I really want to test the concept of hierarchical segmentation. But in order to make the first test, a huge amount of work will have to be done to modify Tendermint. However, I have already done something. I’m not sure if I can boast about this, but I’ll provide links to the repositories. Perhaps this will help to interest someone else in this topic:

• A module that makes it easy to write ABCI applications in Python . Contains an asynchronous ABCI implementation and a minimalist framework.
• The DPKI distributed public key infrastructure prototype described in the article. It's not MVP yet, but it's already worth watching. I hope to reach the MVP level soon.
• An attempt at state registration of Tendermint , not yet complete. The network layer generates derived keys and runs on ed25519. The consensus level passes tests with GOST keys, but the decision is not final. To do this correctly, you need to create a good crypto provider interface like HLF. Now all this is nailed down in Tendermint, and my attempt essentially boils down to replacing these nails.