Alternatives to the blockchain for maintaining secure registries
Technology "blockchain" is beautiful and promising. Everything in it would be quite wonderful if a few annoying nuances:
- A very long time. The time of adding a transaction to a bitcoin chain, for example, is estimated from a minute to half an hour. In Ethereum it is added faster, but in any case it is impossible to bring time to fractions of a second. There is nothing to think about making the addition of data to the blockchain part of an OLTP transaction.
- Mining is very resource intensive . It is, in fact, necessary in order to add computational complexity to the architecture.
- Very expensive. The consequence of resource intensity.
- Technology disgustingly scaled both up and down. If you need to build a system that will register billions of records daily, the blockchain is no good. Also, the blockchain will be firing a gun at sparrows, if you try to adapt it for reliable logging of some petty nonsense.
I would like to have a technology that would simultaneously allow registries to conduct in an impenetrable reliable manner, and would be somehow simpler and cheaper.
Model situation (fiction based on real events)
In one large production and distribution company there was a large sales department, in which, as usual, bonuses to managers depended on the volumes sold.
The sweetest sales volumes are made on the most popular and, as a result, in short supply. Sales managers - the guys are cunning. They quickly realized that the surest way to have good bonuses is to constantly monitor shipments, and as soon as there is a shortage in the warehouse, quickly reserve it for yourself. Create a fictitious “Buyer’s Order”, fill it with a deficit and tell everyone that this is a client who, for the time being, thinks he needs to take more (in general, the situation is normal). Then, when there is a real request for a deficit, quickly remove the required amount from the fictitious account, and at the same second add to the real one.
')
As a result, the business incurs losses. In the warehouse for weeks lying goods, which would have to go on the first day. The sales department, instead of looking for new customers and building relationships with them, has been monitoring deliveries all day. Squabbles, hassle, mutual recriminations and offenses. Something had to be done with this, but in such a way that it did not hurt the core business process. We decided to start logging backup operations. To keep track of situations when the deficit is reserved by the “buyer's order”, but then this reservation does not turn into a sale with the same document. Those who abuse this most are hanged on the pillory.
At first, it helped, but then a strange effect began to be observed: the indicators for the shortage of stock in the warehouse returned to the previous ones, although everything was chocolate in the logs. It turned out that the realization did not take into account the power of the charm of sales managers. For the sake of high bonuses, they got into the habit of conspiring with the system administrators so that they clean out compromising materials from the logs. In the course went the whole arsenal of funds - bribery, blackmail, flirt, women's tears. The guys from the administration service had nothing to oppose such an attack.
The question arose that the technical means make it impossible to retroactively distort the log. We looked in the direction of the blockchain, but we found out that it was too expensive to pass product reservations through popular blockchain platforms, and there was no desire to build a separate server rack for our own blockchain for settling squabbles in the sales department. What to do is not clear.
The sweetest sales volumes are made on the most popular and, as a result, in short supply. Sales managers - the guys are cunning. They quickly realized that the surest way to have good bonuses is to constantly monitor shipments, and as soon as there is a shortage in the warehouse, quickly reserve it for yourself. Create a fictitious “Buyer’s Order”, fill it with a deficit and tell everyone that this is a client who, for the time being, thinks he needs to take more (in general, the situation is normal). Then, when there is a real request for a deficit, quickly remove the required amount from the fictitious account, and at the same second add to the real one.
')
As a result, the business incurs losses. In the warehouse for weeks lying goods, which would have to go on the first day. The sales department, instead of looking for new customers and building relationships with them, has been monitoring deliveries all day. Squabbles, hassle, mutual recriminations and offenses. Something had to be done with this, but in such a way that it did not hurt the core business process. We decided to start logging backup operations. To keep track of situations when the deficit is reserved by the “buyer's order”, but then this reservation does not turn into a sale with the same document. Those who abuse this most are hanged on the pillory.
At first, it helped, but then a strange effect began to be observed: the indicators for the shortage of stock in the warehouse returned to the previous ones, although everything was chocolate in the logs. It turned out that the realization did not take into account the power of the charm of sales managers. For the sake of high bonuses, they got into the habit of conspiring with the system administrators so that they clean out compromising materials from the logs. In the course went the whole arsenal of funds - bribery, blackmail, flirt, women's tears. The guys from the administration service had nothing to oppose such an attack.
The question arose that the technical means make it impossible to retroactively distort the log. We looked in the direction of the blockchain, but we found out that it was too expensive to pass product reservations through popular blockchain platforms, and there was no desire to build a separate server rack for our own blockchain for settling squabbles in the sales department. What to do is not clear.
In principle, this could be the end of the publication and offer the respected public to dream up in the comments on how to make a super reliable recording of transaction steps in the conditions of total distrust of all to all without meaninglessly burning the processor power with a worthless selection of hash functions. But in order that the only answer to the question was not a banal “this is impossible” or something about sidechains, I will try to offer my own version.
At once I will make a reservation that the speech is not about how “how we should reorganize Bitcoin”. Let bitcoin remain the way it is, and we will talk about how to make something functionally similar to the blockchain, but usable for a variety of needs, in particular in corporate systems. Cheap and angry.
First, look closely at the task itself. Firstly, we already have a registry that is protected from tampering. Secondly, the distribution of the system is not very important to us. It is most convenient if the registry protection system is centralized. Ideally, on the same server as the registry itself. Distribution of the registry and its protection system can also be useful in many cases, but you need to start with a simple one. With the principle of protection.
Registry protection system in the corporate system infrastructure:
A priori, we believe that everything that happens on the servers is in the full power of the administrators, and these administrators with their human passions are the weak link. Therefore, the function of monitoring the integrity of the registry is partially assigned to the workstations of users. The principle of "do not trust, verify." The administrator can do anything with the data located on the server, but he is unable to track where and on which computers (as well as smartphones, tablets, flash drives, etc.) spread checksums that fix the integrity of the registry. A function is built into the client application (or, possibly, into a separate special monitoring application), which, if a violation of the registry integrity is detected, lights a red light and allows you to generate a cryptographically reliable indictment.
Protected registry and its checksums:
For each registry entry, its own hash (H0 i ) is calculated, and the binary tree hashes of the second, third, and so on orders (H1, H2, ...) are automatically expanded. After the next entry is entered in the registry, the entry itself is returned to the client application, as well as such a set of hashes of higher levels, so that it completely covers all previous registry entries. For example, adding the sixth record returns D 5 , H0 5 , H1 2 and H2 0 (it is more convenient to look at the picture below). Adding the 15th record, respectively, returns D 14 , H0 14 , H1 6 , H2 2, and H3 0 . Having received the answer from the server, the client application:
- Checks the compliance of D i with what it was about to register.
- Independently calculates H0 i and checks whether the result is equal to what the server sent.
- It remembers the response received from the server to its local database.
In order to exclude a fake server response and other troubles, this response can be protected by electronic signature of the server.
Express check of invariance of own records of the client
When a client has added another entry to the registry, he can verify a new received slice of hashes with slices obtained during previous calls. Since additional levels could have increased since the previous access, a certain amount of additional data from the server may be required to verify the hashes. For example, if a client first added D 5 , and then added D 14 , then for checking H2 0 from H3 0 he requests the value H1 3 from the server, then calculates H2 1 from H1 2 and H1 3 , then from H2 0 and H2 1 calculates H3 0 , which compares with that obtained. If the values ​​do not match, a red light turns on and an alarm is triggered.
Gray color shows data missing on the client. When adding the first record (D 5 ), the client saved the data highlighted in green in its local database, and when adding the next record (D 14 ), it received the data highlighted in blue. The highlighted yellow is additionally requested from the protection server.
Complete check of the registry
The client requests a section of the registry from the server and checks whether it is possible to exit from the received data to those hashes values ​​that are stored in its local storage.
As a result, we have:
- The speed of adding data to the registry. Mine Coin is no need. Increased performance to the extent that the data in the secure registry can be recorded inside the OLTP transaction.
- Reliability. Imperceptibly delete the entry from the registry is impossible. The complexity of data corruption is equal to the difficulty of selecting a full hash collision.
- Ease of implementation. Excellent downward scalability.
- Excellent upward scalability. Even if there are one hundred billion entries in the registry, the number of levels of the binary tree is 36. If SHA-256 hashing is used, the hash data transmitted from the server is less than 2 kilobytes.
- Although the registry maintenance becomes centralized (which is not very good for Bitcoin-style cryptocurrency), a distributed architecture is quite possible based on replication and on-line switching from compromised nodes to those that were not found to be a forgery.
PS About the source code on the githaba, please do not ask. They are not. The idea goes into publication with the wheels.
Source: https://habr.com/ru/post/331706/
All Articles