
The practical application of blockchain as a distributed data warehouse
Blockchain is a technology everyone is talking about right up to housewives, newspapers and magazines. If you forget about hype and do not add blockchain to the project for the sake of blockchain, then its application will not always be justified. We were fortunate enough to encounter just such a situation. We were approached by one of our major customers - a company that provides site services for electronic public procurement.
Registration at the site for public procurement is quite bureaucratic. Fulfilling the requirements of the law and implementing the Know your customer (KYC) principle, sites and certification centers have to collect a lot of documents confirming the identity of the client and the origin of the funds. The customer company had the idea to create a one-time accreditation service at all public procurement sites regulated by different laws - to create a single counterparty profile (this would allow collecting the necessary documents only 1 time). Such a service would be useful to everyone - users after registration at any site would be able to work with everyone else without additional red tape; platforms would receive new users, due to the simplification of registration. Further,
In fact, we were faced with the task of creating a decentralized data exchange system (hereinafter referred to as the Platform) within the framework of the consortium - i.e. closed community members. Although in our case, we were talking about a system in which access to data is provided to all participants, we decided to approach the task broader and create a system within which users could decide for themselves which system participants they want to provide access to data, and who is not.
Multichain was chosen as the technological base of the project since this platform was originally designed with the support of the consortium as the main mode of operation and contains convenient means of working with the blockchain as a data warehouse. The Platform itself, which implements a data exchange interface and means of restricting access to data, was developed on the .NET platform.
The main characteristics of the developed solution:
As you can see, the list is pretty impressive. Of course, the system has some drawbacks that we know about: for example, if we once gave someone access to data, we can assume that he already copied this data and can give it to someone else, but this is already out of control our system. However, any system has such risks. Another drawback of the system, due to the use of the blockchain and the need for encryption / decryption of data on the fly, is the total throughput of ~ 30 transactions per second, which turned out to be more than enough for a specific task, but it can be a limiting factor for using the Platform in a number of other scripting.
As for the principle of operation of the data access control mechanism, it is based on a hybrid encryption scheme:
This is how the work scheme looks in the general case. If we consider a specific implementation made for our customer, it looks like this:
At the moment, our solution has been implemented and is working successfully. If you have questions or comments - write in the comments, we will be happy to answer or debate.
Task
Registration at the site for public procurement is quite bureaucratic. Fulfilling the requirements of the law and implementing the Know your customer (KYC) principle, sites and certification centers have to collect a lot of documents confirming the identity of the client and the origin of the funds. The customer company had the idea to create a one-time accreditation service at all public procurement sites regulated by different laws - to create a single counterparty profile (this would allow collecting the necessary documents only 1 time). Such a service would be useful to everyone - users after registration at any site would be able to work with everyone else without additional red tape; platforms would receive new users, due to the simplification of registration. Further,
Decision
In fact, we were faced with the task of creating a decentralized data exchange system (hereinafter referred to as the Platform) within the framework of the consortium - i.e. closed community members. Although in our case, we were talking about a system in which access to data is provided to all participants, we decided to approach the task broader and create a system within which users could decide for themselves which system participants they want to provide access to data, and who is not.
Multichain was chosen as the technological base of the project since this platform was originally designed with the support of the consortium as the main mode of operation and contains convenient means of working with the blockchain as a data warehouse. The Platform itself, which implements a data exchange interface and means of restricting access to data, was developed on the .NET platform.
The main characteristics of the developed solution:
- Data is distributed among all nodes of the system, not one of the participants in the system can falsify or delete data once issued to another participant, and there is no single point of failure. Even if the participant’s node is physically disconnected from the network, the data received before the moment of disconnection remains on this node and is available for working with them, and when the connection is restored, data is received that appeared during the absence of the node in the network.
- A closed blockchain (consortium) is used - i.e. To connect to it, either coordination with the coordinating node is required, or, if a consensus administration model is chosen, by all network participants.
- After connecting, a consortium member can create both public (accessible to all participants) and closed (accessible to a selected circle of participants) data collections. The security of closed data is ensured through cryptographic protection of data using GOST algorithms.
- Access to the collection can only be controlled by its creator.
- When a new member is added to the access list, the previously published data becomes available to him automatically.
- When a member is removed from the access list, new published data will be inaccessible to him.
- The platform supports the structuring of data in the collection in JSON format and validation of the document format in it according to the JSON scheme.
- The platform provides an API that isolates the user from the details of the implementation of the blockchain itself and allows you to work with concepts of a higher level (“document” and “collection”).
- The platform does not provide for the deletion of data, so no participant can delete a document from the collection available to other participants.
- When updating a document, a complete history of its changes is saved, and there is the possibility of obtaining any version of the document.
- The platform supports sending custom participant notifications about data change / update in the collection of interest to the participant’s external systems, so the information systems of one participant can quickly respond to data updates made by the information systems of the other participant.
As you can see, the list is pretty impressive. Of course, the system has some drawbacks that we know about: for example, if we once gave someone access to data, we can assume that he already copied this data and can give it to someone else, but this is already out of control our system. However, any system has such risks. Another drawback of the system, due to the use of the blockchain and the need for encryption / decryption of data on the fly, is the total throughput of ~ 30 transactions per second, which turned out to be more than enough for a specific task, but it can be a limiting factor for using the Platform in a number of other scripting.
As for the principle of operation of the data access control mechanism, it is based on a hybrid encryption scheme:
- A registered member of the system receives a public and private key. Each member’s public key is publicly available and published on the blockchain.
- Participant No. 1 creates a new collection and determines with which of the participants in the system he would like to share its contents (Participant No. 2 and No. 3), then he adds a document to this collection.
- The platform encrypts the document with the generated symmetric key (this means that the decryption will require the same key as for encryption). Such a key has a significantly smaller volume than the encrypted document itself.
- The platform extracts the public keys of participants No. 2 and No. 3 from the blockchain and encrypts the symmetric key with them, and puts the results on the blockchain.
- Participants 2 and 3 enter the system and try to view the contents of the collection. The platform decrypts the private key of participants No. 2 and No. 3 with a symmetric key, and then decrypts the document with this key. Thus, participants No. 2 and No. 3 gain access to its contents.
This is how the work scheme looks in the general case. If we consider a specific implementation made for our customer, it looks like this:
- The participant passes registration in the Accounting Center (hereinafter UTS No. 1), submitting all the necessary documents and data.
- The accounting center gives the participant an electronic signature and binds to it all the data submitted to them, adding all this to the blockchain.
- When a participant enters the public procurement site (hereinafter Site No. 1), she extracts his registration data from the Collection created by UTs1.
- There may be a situation when the site does not have enough of this data and it asks for additional information or wants to store other information (for example, the history of bidding) for a particular client in order to share it with another friendly site. In this case, she creates a new collection in the blockchain with these additional data.
- When the Participant decides to register at Site No. 2, she also takes his registration data from the collection of CA No. 1 or from the collection created by Site No. 1
Total
At the moment, our solution has been implemented and is working successfully. If you have questions or comments - write in the comments, we will be happy to answer or debate.