at the end of September, 2017 to me and gelbplaneten was succeeded to participate in preparation and carrying out the first in Russian Federation transactions on securities with use of Technologies blokcheyna .
the Project was carried out by NRD under the direction of Yakovlev Alexander, program realization was developed by company Altoros , the architect — Oleg Abdrashitov .
Under a cat my story about technical and some legal aspects of preparation and carrying out the transaction.
For carrying out the pilot transaction we developed a blokcheyn-platform on the basis of Hyperledger Fabric v.1.0. The Hyperledger project under the auspices of The Linux Foundation — is an initiative of creation of different blokcheyn-platforms and auxiliary tools with an open initial code. The whole scattering of companies participates in the project from all over the world: technological giants (IBM, Intel and so on), consulting companies (Accenture, Altoros and so on), representatives of various branches (Public joint-stock company "Sberbank Russia", Moscow exchange, CME, DTCC, Deutche Burse, Daimler, Airbus and so on) and startup team (Digital Asset Holding, Soramitsu and so on). The project started in December, 2015, and now five blokcheyn-platforms and four tools for work with blokcheyn-platforms actively develop. Hyperledger is open for all, its participants are equal among themselves and adhere to the principles of a "pure" open code.
As is not so widely known for Hyperledger Fabric v.1.0 as Bitkoin or Efirium that it was easier for you to understand topology of this blokcheyn-network and processes occurring in it, I in brief will tell about features of architecture of Hyperledger Fabric v.1.0.
we Will consider
Unlike public platforms like Bitkoin are carried out or Efirium, in Hyperledger Fabric v.1.0 is two special roles:
to reach consensus when checking transactions, are used by of policy of validation (endorsement policy) — it is a set governed, defining what of knots can be the validator, and how many signatures of validators are enough in order that transaction was considered as the confirmed. Thus the policy of validation is set separately for each smart contract created in a blokcheyn-network. For example, it is possible to register in policy that transaction will be valid if it is confirmed by two of three set knots.
As is created and executed transaction:
In structure of a blokcheyn-network was three participants:
Each participant developed at himself own knot of a network, and also the additional components provided by architecture of Hyperledger Fabric v.1.0:
In a network created registers access to which was differentiated by the internal mechanism of Hyperledger channels:
under one smart contract Position in which context account balances of the participant were reflected.
If the transaction was carried out and legalized only through Technologies blokcheyna, everything would occur so:
Are the approved order of regulation trades securities at which the transaction is considered legally significant if it is carried out through regular system of the accounting of securities of NRD "Alameda". To meet this condition, in process of carrying out the transaction added special stages of formation, signing and processing of instructions of an operating format, with use of "fighting" ETsP participants of the transaction. Besides, that transfer of instructions through Technologies blokcheyna was considered legitimate, NRD signed with participants of the transaction the license agreement and the additional agreement to Contract on electronic document flow.
as a result process of the conclusion of the transaction began to look so:
of All participants of the project first of all study of the legal issues connected with carrying out transactions through Technologies blokcheyna, and detection of technical and organizational difficulties which can arise at blokcheyn-network expansion in actual practice interested. Especially as the organizations different, everyone with the infrastructure and network policy, rules of interaction of external and internal networks, and so on and so forth.
We met the first difficulties even prior to platform expansion: it appeared that JOINT-STOCK COMPANY "RAYFFAYZENBANK" and Megafon are not ready to give direct access to the operating keys of ETsP "to the stranger mysterious" ON. So it was necessary to develop the special utility on unloading/loading of files of instructions that they could be signed out of ON platforms.
Further difficulties were connected with that the platform was developed and debugged in Amazon Web Services, and now it was necessary to work with it instead of the sterile and homogeneous environment of a cloud in the severe heterogeneous world.
Fortunately, realization of a platform assumed use of Docker-containers therefore the distinctions connected with use by participants of different OS (RHEL and Ubuntu) did not influence work of knots of a network.
the Main problems were connected with internal features of Hyperledger Fabric and that in both companies the network infrastructure is differently constructed:
On expansion and control of a platform about three days (on September 27-29) and 20 hours per Webex left. As usual in the IT environment, did not manage and without shaman tambourines — "… now we wait exactly seven minutes... " But as a result the first transaction passed
without uniform failure and lag.
are given Below historical screenshots — an assignment JOINT-STOCK COMPANY "RAYFFAYZENBANK" on purchase of bonds Megafon and total balance by results of the transaction.
the Project was carried out by NRD under the direction of Yakovlev Alexander, program realization was developed by company Altoros , the architect — Oleg Abdrashitov .
Under a cat my story about technical and some legal aspects of preparation and carrying out the transaction.
the blokcheyn-network
For carrying out the pilot transaction we developed a blokcheyn-platform on the basis of Hyperledger Fabric v.1.0. The Hyperledger project under the auspices of The Linux Foundation — is an initiative of creation of different blokcheyn-platforms and auxiliary tools with an open initial code. The whole scattering of companies participates in the project from all over the world: technological giants (IBM, Intel and so on), consulting companies (Accenture, Altoros and so on), representatives of various branches (Public joint-stock company "Sberbank Russia", Moscow exchange, CME, DTCC, Deutche Burse, Daimler, Airbus and so on) and startup team (Digital Asset Holding, Soramitsu and so on). The project started in December, 2015, and now five blokcheyn-platforms and four tools for work with blokcheyn-platforms actively develop. Hyperledger is open for all, its participants are equal among themselves and adhere to the principles of a "pure" open code.
As is not so widely known for Hyperledger Fabric v.1.0 as Bitkoin or Efirium that it was easier for you to understand topology of this blokcheyn-network and processes occurring in it, I in brief will tell about features of architecture of Hyperledger Fabric v.1.0.
we Will consider
of Feature of architecture of Hyperledger Fabric v.1.0
on the Hyperledger Fabric v.1.0 blokcheyn-platform (on materials by "The trend of exploring the use of DLT in Capital market", Japan Exchange Group, September 14, 2017 )Unlike public platforms like Bitkoin are carried out or Efirium, in Hyperledger Fabric v.1.0 is two special roles:
- of Endorser (validator) — the knot checking and executing transaction, and then returning back to her client with results and the signature.
- of Orderer (uporyadochivatel) — the knot establishing sequence of transactions and dispatching to "12" their other knots of a DLT network.
to reach consensus when checking transactions, are used by of policy of validation (endorsement policy) — it is a set governed, defining what of knots can be the validator, and how many signatures of validators are enough in order that transaction was considered as the confirmed. Thus the policy of validation is set separately for each smart contract created in a blokcheyn-network. For example, it is possible to register in policy that transaction will be valid if it is confirmed by two of three set knots.
As is created and executed transaction:
- the Client directs transaction to validators (endorsers).
- Validators execute transaction and return it to the client together with results of execution and the signature.
- the Client collects necessary number of signatures of validators and directs transaction with a set of answers of validators on Orderer.
- of Orderer are combined by transactions in sequence of blocks and dispatches them. Each of knots checks
- , whether there corresponds transaction to policy of validation, and "loses" it in the copy of the register.
Topology of a blokcheyn-network of the pilot transaction
In structure of a blokcheyn-network was three participants:
- of NRD — the operator of the transaction and the administrator of a platform.
- Megafon — the participant of the transaction.
- JOINT-STOCK COMPANY "RAYFFAYZENBANK" — the participant of the transaction.
Each participant developed at himself own knot of a network, and also the additional components provided by architecture of Hyperledger Fabric v.1.0:
- of NRD developed Orderer providing formation of the ordered stream of transactions, and to
- established client part about UI providing functionality of the operator of of the transaction. Megafon and Raiffeisen established to
- client parts about UI providing functionality of the participant of of the transaction.
In a network created registers access to which was differentiated by the internal mechanism of Hyperledger channels:
- the Register of securities (it is available to all participants of a network). Here the only smart contract SecurityMaster was created in which context the list of securities was kept.
- the Summary register of balances of accounts of all participants (NRD is available only). Here the only smart contract Book was created in which context account balances of all participants were reflected.
- the Register of balances of accounts JOINT-STOCK COMPANY "RAYFFAYZENBANK" (it is available only to NRD and JOINT-STOCK COMPANY "RAYFFAYZENBANK").
- the Register of balances of accounts of Megafon (it is available only to NRD and Megafon).
- the Register of transactions between JOINT-STOCK COMPANY "RAYFFAYZENBANK" and Megafon (NRD is available only, to JOINT-STOCK COMPANY "RAYFFAYZENBANK" and to Megafon). Here the only smart contract Instruction was created in which context all transactions of this couple of participants were registered and processed.
under one smart contract Position in which context account balances of the participant were reflected.
If the transaction was carried out and legalized only through Technologies blokcheyna, everything would occur so:
- In the Register of transactions both participants create transactions instructions of purchase and sale which remain in a smart contract Instruction . At receipt of the second instruction from purchase sale vapors they are compared to
- with each other in the smart contract Instruction and receive "matched" status.
- When the client of NRD receives the notice of comparison, according to the Summary register of balances checks balances on accounts of participants of the transaction. If check of balances took place
- successfully, the client of NRD:
- Creates in the smart contract Instruction transactions which change the status of the corresponding instructions for "execute".
- A then are created by transactions on change of balances of accounts for the smart contract Position .
Preparation and carrying out the transaction
Are the approved order of regulation trades securities at which the transaction is considered legally significant if it is carried out through regular system of the accounting of securities of NRD "Alameda". To meet this condition, in process of carrying out the transaction added special stages of formation, signing and processing of instructions of an operating format, with use of "fighting" ETsP participants of the transaction. Besides, that transfer of instructions through Technologies blokcheyna was considered legitimate, NRD signed with participants of the transaction the license agreement and the additional agreement to Contract on electronic document flow.
as a result process of the conclusion of the transaction began to look so:
- Megafon and JOINT-STOCK COMPANY "RAYFFAYZENBANK", everyone on the knot, create counter instructions on sale and purchase respectively, and transfer them to the smart contract Instruction. to
- In the smart contract Instruction of the instruction are compared with each other. If comparison took place
- successfully:
- of NRD on the knot creates and "attaches" to the instruction of each of participants the corresponding file of an assignment for the subsequent loading in "Alameda".
- the corresponding transactions go To Registers of balances of participants of the transaction (smart contract Position) about change of the accounting of papers on accounts.
- Participants of the transaction:
- Take from Technologies blokcheyna files of instructions for "Alameda".
- the "fighting" ETsP on the corresponding workplaces Sign them.
- Place back in Technologies blokcheyna.
- of NRD takes the files of instructions signed by participants and loads into "Alameda". "Alamed's"
- processes the transaction and creates reporting files which then sends to participants of the transaction.
As everything was
of All participants of the project first of all study of the legal issues connected with carrying out transactions through Technologies blokcheyna, and detection of technical and organizational difficulties which can arise at blokcheyn-network expansion in actual practice interested. Especially as the organizations different, everyone with the infrastructure and network policy, rules of interaction of external and internal networks, and so on and so forth.
We met the first difficulties even prior to platform expansion: it appeared that JOINT-STOCK COMPANY "RAYFFAYZENBANK" and Megafon are not ready to give direct access to the operating keys of ETsP "to the stranger mysterious" ON. So it was necessary to develop the special utility on unloading/loading of files of instructions that they could be signed out of ON platforms.
Further difficulties were connected with that the platform was developed and debugged in Amazon Web Services, and now it was necessary to work with it instead of the sterile and homogeneous environment of a cloud in the severe heterogeneous world.
Fortunately, realization of a platform assumed use of Docker-containers therefore the distinctions connected with use by participants of different OS (RHEL and Ubuntu) did not influence work of knots of a network.
the Main problems were connected with internal features of Hyperledger Fabric and that in both companies the network infrastructure is differently constructed:
- Because of features of the smart contracts Hyperledger Fabric was necessary "to level" completely knots as on release (because the hash kommita was used internal to algorithms), and on the user of OS under whom were started komponeny platforms (it too participated in smart contract identification).
- the Knot JOINT-STOCK COMPANY "RAYFFAYZENBANK" did not see itself to the external address therefore some stages of scripts of installation and control should be passed on.
- there were mysterious "sticking" of the service which was responsible for unloading/loading of files of which it was possible to get rid only service restart.
On expansion and control of a platform about three days (on September 27-29) and 20 hours per Webex left. As usual in the IT environment, did not manage and without shaman tambourines — "… now we wait exactly seven minutes... " But as a result the first transaction passed
without uniform failure and lag.
are given Below historical screenshots — an assignment JOINT-STOCK COMPANY "RAYFFAYZENBANK" on purchase of bonds Megafon and total balance by results of the transaction.