Blockchain is a technology that everyone is talking about right now to housewives, they write newspapers and magazines. If you forget about the hype and not add a blockchain to the project for the sake of a blockchain, then its use will not always be justified. We were lucky enough to face just such a situation. We were approached by one of our major customers - a company that provides site services on electronic public procurement.
Task
Registration on the state procurement process is quite bureaucratic. Complying with the requirements of the legislation and implementing the principle of Know your customer (KYC), sites and certification centers have to collect a lot of documents confirming the identity of the client and the origin of funds. The client company had an idea to create a one-time accreditation service at all sites for government procurement 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 - after registering on any site, users would be able to work with everyone else without additional red tape; sites would get new users, by simplifying registration. In the future, this platform could attract competing platforms and other related organizations.
Decision
In essence, we were faced with the task of creating a decentralized data exchange system (hereinafter referred to as the Platform) within the framework of a consortium - i.e. closed community of members. Although in our case, we talked about a system in which access to data is provided to all participants, we decided to approach the task more broadly and create a system in which users could decide which of the participants in the system they want to provide access to the data, and who does 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 operating mode and contains convenient tools for working with the blockchain as a data warehouse. The platform itself, which implements the data exchange interface and the means of differentiating 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, none of the system participants can falsify or delete data once issued to another participant, and there is also no single point of failure. Even if the participant’s node is physically disconnected from the network, the data received prior to the moment of disconnection remains on that node and is available to work with them, and when the connection is restored, the data that appeared during the absence of the node in the network is obtained.
- A closed blockchain (consortium) is used - i.e. connecting to it requires either coordination by the coordinating node, or, if a consensus administration model is chosen, by all network participants.
- Once connected, a consortium participant can create both public (accessible to all participants) and closed (accessible to a selected group of participants) data collections. Security of closed data is ensured by data encryption using GOST-based algorithms.
- Only the creator of the collection can control access to the collection.
- When an existing collection of a new member is added to the access list, previously published data becomes available to him automatically.
- When a member is removed from the access list, new published data will not be available to him.
- The platform supports the structuring of data in the collection in JSON format and the validation of the document format in it according to the JSON scheme.
- The platform provides the API, isolating the user from the details of the implementation of the blockchain itself and allowing it to work with higher-level concepts (“document” and “collection”).
- The platform does not provide for deletion of data, thus, no one participant can remove a document from a collection accessible to other participants.
- When updating the document, the full history of its changes is saved, and there is the possibility of obtaining any of the versions of the document.
- The platform supports sending custom notifications about changes / updates in the collection of interest to external member systems, so that information systems of one participant can quickly respond to data updates made by information systems of another participant.
As you can see, the list is quite impressive. Of course, the system also has some flaws that we know about: for example, if we once gave someone access to the data, it can be assumed that he already copied this data and could give it to someone else, but this is out of control our system. However, any system has this kind of risk. Another drawback of the system, due to the use of the blockchain and the need for data encryption / decryption operations on the fly, is the total bandwidth of ~ 30 transactions per second, which was more than enough for a specific task, but may be a limiting factor for the use of the Platform in a number of other scripts.
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. The public key of each participant is publicly available and is published in the blockchain.
- Participant # 1 creates a new collection and determines with which of the participants of the system he would like to share its contents (Participant # 2 and # 3), then adds a document to this collection.
- The platform encrypts the document with the generated symmetric key (this means that decryption will require the same key as for encryption). Such a key has a much smaller volume than the encrypted document itself.
- The platform extracts the public keys of participants # 2 and # 3 from the blockchain and encrypts the symmetric key with them, and puts the results into the blockchain.
- Participants â„–2 and â„–3 log in and try to view the contents of the collection. The platform decrypts the private keys of participants No. 2 and No. 3 with a symmetric key, after which it decrypts the document with this key. Thus, participants â„–2 and â„–3 get access to its contents.
This is the general scheme of work. If we consider a specific implementation made for our customer, it looks like this:
- The participant is registered in the Accounting Center (hereinafter TC 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 by him, putting it all into the blockchain.
- When a participant enters the state procurement site (hereinafter referred to as Site 1), it retrieves its registration data from the Collection created by Training Center No. 1.
- There may be a situation when the site does not have enough of this data and it asks for additional or wants to store other information (for example, the history of participation in tenders) for a specific customer in order to share it with another friendly platform. In this case, it creates a new collection in the blockchain with this additional data.
- When a Participant decides to register at Site 2, she also takes his registration data from the CA number 1 collection or from the collection created by Site 1.
Total
At the moment, our solution is implemented and is working successfully. If you have questions or comments - write in the comments, we will be happy to answer or discuss.