Megafon-Raiffeisenbank - Russia's first deal in securities on the blockchain
At the end of September 2017, gelbplaneten and I were able to participate in the preparation and conduct of the first Russian securities transaction using blockchain technology .
The project was conducted by NSD under the direction of Alexander Yakovlev, the software implementation was developed by Altoros , the architect was Oleg Abdrashitov .
Under the cut my story about the technical and some legal aspects of the preparation and conduct of the transaction.
For the pilot deal, we deployed a blockchain platform based on Hyperledger Fabric v.1.0. The Hyperledger project under the auspices of The Linux Foundation is an initiative to create various blockchain platforms and open source support tools. The project involves a whole scattering of companies from around the world: technology giants (IBM, Intel, and so on), consulting companies (Accenture, Altoros, and so on), representatives of various industries (Sberbank, Moscow Exchange, CME, DTCC, Deutche Burse, Daimler, Airbus and so on) and startup teams (Digital Asset Holding, Soramitsu and so on). The project was launched in December 2015, and now five blockchain platforms and four tools for working with blockchain platforms are actively developing. Hyperledger is open to all, its members are equal among themselves and adhere to the principles of "clean" open source.
')
Since Hyperledger Fabric v.1.0 is not as widely known as Bitcoin or Ethereum, in order to make it easier for you to understand the topology of this blockchain network and the processes occurring in it, I will briefly describe the features of the Hyperledger Fabric v.1.0 architecture.
Let's look at how transactions are performed on the Hyperledger Fabric v.1.0 blockchain platform (based on “The Trend of the DLT in Capital Market”, Japan Exchange Group, September 14, 2017 )
Unlike public platforms like Bitcoin or Ethereum, there are two special roles in Hyperledger Fabric v.1.0:
To achieve consensus when verifying transactions, endorsement policies are used - this is a set of rules that determine which of the nodes can be a validator and how many validator signatures are sufficient for the transaction to be considered confirmed. At the same time, the validation policy is set separately for each smart contract created in the blockchain network. For example, it can be stated in a policy that a transaction will be valid if it is confirmed by two of the three specified nodes.
How a transaction is created and executed:
There were three participants in the blockchain network structure:
Each participant deployed its own network node, as well as additional components provided by the Hyperledger Fabric v.1.0 architecture:
Registries were created on the network, access to which was delimited by the internal mechanism of Hyperledger channels:
Also in the balance sheets registers of Raiffeisenbank and Megaphone there was created one smart contract Position , in the context of which balances were recorded on the participant's accounts.
If the transaction was carried out and legalized only through the blockchain, then everything would happen like this:
There is an approved procedure for regulating the trading of securities, in which a transaction is considered legally significant if it is conducted through the standard securities accounting system of NSD Alameda. In order to meet this condition, special stages of forming, signing and processing instructions of the current format were added to the process of conducting a transaction, using “combat” EDS participants in the transaction. In addition, in order to transfer instructions via the blockchain as legitimate, NSD signed a license agreement with the parties to the transaction and an additional agreement to the Agreement on electronic document flow.
As a result, the transaction process began to look like this:
All project participants were primarily interested in the development of legal issues related to carrying out transactions through blockchains, and identifying technical and organizational difficulties that may arise when deploying a blockchain network in real conditions. Moreover, the organizations are different, each with its own infrastructure and network policies, rules for the interaction of external and internal networks, and so on and so forth.
We faced the first difficulties even before the launch of the platform: it turned out that Raiffeisenbank and Megafon are not ready to give direct access to their current EDS keys to “alien mysterious” software. So I had to develop a special utility for uploading / uploading order files so that they could be signed outside the platform software.
Further difficulties were related to the fact that the platform was developed and debugged in Amazon Web Services, and now it had to work instead in a sterile-homogeneous cloud environment in a harsh heterogeneous world.
Fortunately, the implementation of the platform involved the use of Docker containers, so the differences associated with the use of different operating systems by participants (RHEL and Ubuntu) did not affect the operation of network nodes.
The main problems were related to the internal features of the Hyperledger Fabric and the fact that in both companies the network infrastructure is different:
The deployment and setup of the platform took about three days (September 27-29) and 20 hours in Webex. As usual in the IT environment, it was not without the shaman tambourines - “... now we are waiting for exactly seven minutes ...”
But in the end, the first deal went without a single failure and freeze.
Below are the historical screenshots - instructions from Raiffeisenbank for the purchase of MegaFon bonds and the final balance based on the transaction results.
The project was conducted by NSD under the direction of Alexander Yakovlev, the software implementation was developed by Altoros , the architect was Oleg Abdrashitov .
Under the cut my story about the technical and some legal aspects of the preparation and conduct of the transaction.
Description of the blockchain network
For the pilot deal, we deployed a blockchain platform based on Hyperledger Fabric v.1.0. The Hyperledger project under the auspices of The Linux Foundation is an initiative to create various blockchain platforms and open source support tools. The project involves a whole scattering of companies from around the world: technology giants (IBM, Intel, and so on), consulting companies (Accenture, Altoros, and so on), representatives of various industries (Sberbank, Moscow Exchange, CME, DTCC, Deutche Burse, Daimler, Airbus and so on) and startup teams (Digital Asset Holding, Soramitsu and so on). The project was launched in December 2015, and now five blockchain platforms and four tools for working with blockchain platforms are actively developing. Hyperledger is open to all, its members are equal among themselves and adhere to the principles of "clean" open source.
')
Since Hyperledger Fabric v.1.0 is not as widely known as Bitcoin or Ethereum, in order to make it easier for you to understand the topology of this blockchain network and the processes occurring in it, I will briefly describe the features of the Hyperledger Fabric v.1.0 architecture.
Features of the Hyperledger Fabric architecture v.1.0
Let's look at how transactions are performed on the Hyperledger Fabric v.1.0 blockchain platform (based on “The Trend of the DLT in Capital Market”, Japan Exchange Group, September 14, 2017 )
Unlike public platforms like Bitcoin or Ethereum, there are two special roles in Hyperledger Fabric v.1.0:
- Endorser (validator) - the node that checks and executes the transaction, and then returns it back to the client with the results and its signature.
- Orderer is a node that establishes a sequence of transactions and sends them to other nodes of the DLT network.
To achieve consensus when verifying transactions, endorsement policies are used - this is a set of rules that determine which of the nodes can be a validator and how many validator signatures are sufficient for the transaction to be considered confirmed. At the same time, the validation policy is set separately for each smart contract created in the blockchain network. For example, it can be stated in a policy that a transaction will be valid if it is confirmed by two of the three specified nodes.
How a transaction is created and executed:
- The client directs the transaction to validators (endorsers).
- The validators execute the transaction and return it to the client along with the results of the execution and their signature.
- The client collects the required number of validator signatures and sends a transaction with a set of validator responses to Orderer.
- Orderer combines transactions into a sequence of blocks and sends them.
- Each node checks if the transaction complies with the validation policy, and “loses” it in its copy of the registry.
Topology blockchain-network pilot deal
There were three participants in the blockchain network structure:
- NSD is a transaction operator and platform administrator.
- Megaphone - party to the transaction.
- Raiffeisenbank - party to the transaction.
Each participant deployed its own network node, as well as additional components provided by the Hyperledger Fabric v.1.0 architecture:
- NSD has deployed an Orderer to form an orderly transaction flow, and
- installed the client part with the UI, which provides the functionality of the transaction operator .
- Megafon and Raiffeisen installed client parts with UI, providing the functionality of the transaction participant .
Registries were created on the network, access to which was delimited by the internal mechanism of Hyperledger channels:
- Register of securities (available to all members of the network). Here, the only SecurityMaster smart contract was created, in the context of which the list of securities was entered.
- Consolidated register of balances of accounts of all participants (only NSD is available). Here was created the only smart contract Book , in the context of which were reflected the balances on the accounts of all participants.
- Register of balance sheets of Raiffeisenbank (available only to NSD and Raiffeisenbank).
- Register of Megafon accounts balances (only NSD and Megafon are available).
- Register of transactions between Raiffeisenbank and Megaphone (available only to NSD, Raiffeisenbank and Megafon). Here, the only Instruction smart contract was created, in the context of which all transactions of a given pair of participants were recorded and processed.
Also in the balance sheets registers of Raiffeisenbank and Megaphone there was created one smart contract Position , in the context of which balances were recorded on the participant's accounts.
If the transaction was carried out and legalized only through the blockchain, then everything would happen like this:
- In the Transaction Register, both participants create purchase and sale instructions transactions, which are stored in the context of the Instruction smart contract.
- Upon receipt of the second instruction from the pair “purchase-sale” they are compared with each other in the Instruction smart contract and receive the status of “matched”.
- When a NSD client receives a comparison notice, it checks the balance on the accounts of participants in the transaction using the Consolidated Register of Balances.
- If the balance check was successful, the NSD client:
- Creates transactions in the Instruction smart contract that change the status of the corresponding instructions to “execute”.
- And then creates transactions to change the balance of accounts for the smart contract Position .
Preparation and conduct of the transaction
There is an approved procedure for regulating the trading of securities, in which a transaction is considered legally significant if it is conducted through the standard securities accounting system of NSD Alameda. In order to meet this condition, special stages of forming, signing and processing instructions of the current format were added to the process of conducting a transaction, using “combat” EDS participants in the transaction. In addition, in order to transfer instructions via the blockchain as legitimate, NSD signed a license agreement with the parties to the transaction and an additional agreement to the Agreement on electronic document flow.
As a result, the transaction process began to look like this:
- Megafon and Raiffeisenbank, each at its own site, create counter-instructions for selling and buying, respectively, and transfer them to the Instruction smart contract.
- Instruction smart contract instructions are mapped to each other.
- If the mapping was successful, then:
- NSD on its site creates and “attaches” to the instructions of each of the participants a corresponding order file for subsequent upload to Alameda.
- The registers of participants' balance sheets (smart contract Position) are sent the corresponding transactions to change the accounting of securities in the accounts.
- Participants of the transaction:
- Extract from the blockchain order files for "Alameda".
- Sign them with their “combat” EDS at the respective workplaces.
- Put back on the blockchain.
- NSD extracts the order files signed by the participants and uploads to Alameda.
- Alameda processes the transaction and creates the reporting files, which are then sent to the participants in the transaction.
How was it
All project participants were primarily interested in the development of legal issues related to carrying out transactions through blockchains, and identifying technical and organizational difficulties that may arise when deploying a blockchain network in real conditions. Moreover, the organizations are different, each with its own infrastructure and network policies, rules for the interaction of external and internal networks, and so on and so forth.
We faced the first difficulties even before the launch of the platform: it turned out that Raiffeisenbank and Megafon are not ready to give direct access to their current EDS keys to “alien mysterious” software. So I had to develop a special utility for uploading / uploading order files so that they could be signed outside the platform software.
Further difficulties were related to the fact that the platform was developed and debugged in Amazon Web Services, and now it had to work instead in a sterile-homogeneous cloud environment in a harsh heterogeneous world.
Fortunately, the implementation of the platform involved the use of Docker containers, so the differences associated with the use of different operating systems by participants (RHEL and Ubuntu) did not affect the operation of network nodes.
The main problems were related to the internal features of the Hyperledger Fabric and the fact that in both companies the network infrastructure is different:
- Because of the peculiarities of the smart contracts, Hyperledger Fabric had to completely “align” the nodes both by release (because the commit hash was used by internal algorithms) and by the OS user, under which the platform components were launched (he also participated in identifying the smart contract).
- The Raiffeisenbank site did not see itself at its external address, so some stages of the installation and configuration scripts had to be skipped by <Ctrl + C>.
- There were mysterious "sticking" of the service, which was responsible for uploading / downloading files, which could only be got rid of by restarting the service.
The deployment and setup of the platform took about three days (September 27-29) and 20 hours in Webex. As usual in the IT environment, it was not without the shaman tambourines - “... now we are waiting for exactly seven minutes ...”
But in the end, the first deal went without a single failure and freeze.
Below are the historical screenshots - instructions from Raiffeisenbank for the purchase of MegaFon bonds and the final balance based on the transaction results.
Source: https://habr.com/ru/post/341850/
All Articles