Megafon-Raiffeisenbank-ロシア初のブロックチェーン証券取引

2017年9月末、私とgelbplanetenは 、 ブロックチェーン技術を使用したロシア初の証券取引の準備と実施に参加することができました。



このプロジェクトは、アレクサンダーヤコブレフの指導の下でNSDが実施し、ソフトウェアの実装はAltorosが開発し、建築家のOleg Abdrashitovが開発しました 。



カットの下で、私の話は、トランザクションの準備と実行の技術的および法的側面に関するものです。

ブロックチェーンネットワークの説明

パイロットトランザクションを実行するために、Hyperledger Fabric v.1.0に基づくブロックチェーンプラットフォームを展開しました。 The Linux FoundationがスポンサーとなっているHyperledgerプロジェクトは、さまざまなブロックチェーンプラットフォームとオープンソースサポートツールを作成するためのイニシアチブです。 このプロジェクトには、世界中の企業が散在しています：テクノロジーの巨人（IBM、Intelなど）、コンサルティング会社（Accenture、Altorosなど）、さまざまな業界の代表者（Sberbank、モスクワ取引所、CME、DTCC、Deutche Burse、Daimler、エアバスなど）およびスタートアップチーム（デジタルアセットホールディング、そらみつなど）。 このプロジェクトは2015年12月に開始され、現在5つのブロックチェーンプラットフォームとブロックチェーンプラットフォームを操作するための4つのツールが積極的に開発されています。 Hyperledgerはすべてに対してオープンであり、そのメンバーは互いに同等であり、「クリーン」なオープンソースの原則を順守しています。



Hyperledger Fabric v.1.0はBitcoinやEthereumほど広く知られていないので、このブロックチェーンネットワークのトポロジーとそこで発生するプロセスを理解しやすくするために、Hyperledger Fabric v.1.0のアーキテクチャー機能について簡単に説明します。

Hyperledger Fabric v.1.0のアーキテクチャの機能

ブロックチェーンプラットフォームHyperledger Fabric v.1.0でトランザクションがどのように実行されるかを考えてみましょう（ 2017年9月14日、日本取引所グループ、「資本市場におけるDLTの使用を探る傾向」の資料に基づいて）



BitcoinやEthereumなどのパブリックプラットフォームとは異なり、Hyperledger Fabric v.1.0には2つの特別な役割があります。

• Endorser（バリデーター）-トランザクションをチェックして実行し、結果と署名とともにクライアントに返すノード。
• 発注者（オーガナイザー）-トランザクションのシーケンスを確立し、それらをDLTネットワークの他のノードに送信するノード。

トランザクションのチェックでコンセンサスを達成するために、承認ポリシーが使用されます-これは、どのノードがバリデーターになることができるか、およびトランザクションが確認済みと見なされるのに十分なバリデーター署名の数を決定するルールのセットです。 さらに、検証ポリシーは、ブロックチェーンネットワークで作成されたスマートコントラクトごとに個別に設定されます。 たとえば、指定した3つのノードのうち2つが確認した場合にトランザクションが有効になるようにポリシーで指定できます。



トランザクションの作成および実行方法：

1. クライアントは、トランザクションをエンドーサーに送信します。
2. バリデーターはトランザクションを実行し、実行結果とその署名とともにクライアントに返します。
3. クライアントは必要な数のバリデータ署名を収集し、一連のバリデータ応答を含むトランザクションをOrdererに送信します。
4. Ordererは、トランザクションを一連のブロックにまとめて送信します。
5. 各ノードは、トランザクションが検証ポリシーに準拠しているかどうかをチェックし、レジストリインスタンスで「失います」。

パイロットトランザクションブロックチェーンネットワークトポロジ

ブロックチェーンネットワークの構造には3人の参加者がいました。

• NSDはトランザクションオペレーターおよびプラットフォーム管理者です。
• メガホン-取引の当事者。
• ライファイゼンバンクは取引の当事者です。

各参加者は、独自のホストをネットワークに展開し、Hyperledger Fabric v.1.0アーキテクチャによって提供される追加のコンポーネントを展開しました。

• NSDはOrdererを展開して、トランザクションの秩序あるフローを確保します。
• トランザクションオペレータの機能を提供するUIでクライアント部分をインストールしました。
• MegaFonとRaiffeisenは、トランザクション参加者の機能を提供するUIを備えたクライアントパーツをインストールしました 。

レジスタはネットワーク上で作成され、そのアクセスはHyperledgerチャネルの内部メカニズムによって制限されていました。

• 証券の登録 （すべてのネットワークメンバーが利用可能）。 ここで唯一のSecurityMasterスマートコントラクトが作成され、そのコンテキストで証券のリストが保持されました。
• すべての参加者の口座残高の統合登録 （NSDでのみ利用可能）。 ここでは、すべての参加者の口座の残高が反映されるコンテキストで、唯一のBookスマート契約が作成されました。
• Raiffeisenbank口座残高簿 （NSDおよびRaiffeisenbankでのみ利用可能）。
• Megafonアカウントバランスレジスタ （NSDおよびMegafonでのみ使用可能）。
• RaiffeisenbankとMegafonの間のトランザクションの登録 （NSD、RaiffeisenbankおよびMegafonでのみ利用可能）。 ここでは、このペアの参加者のすべてのトランザクションが登録および処理されるコンテキストで、唯一のインストラクションスマートコントラクトが作成されました。

また、RaiffeisenbankおよびMegafonの貸借対照表登録簿では、1つのPositionスマート契約が作成され、そのコンテキストに参加者の口座の残高が反映されました。



トランザクションがブロックチェーンを通じてのみ行われ、合法化された場合、すべては次のようになります。

1. トランザクションレジスタで、両方の参加者は、 Instructionスマートコントラクトのコンテキストで保存される購入および販売指示のトランザクションを作成します。
2. ペア「purchase-sale」から2番目の指示を受け取ると、それらはInstructionスマート契約で互いに比較され、「matched」のステータスを受け取ります。
3. NSDクライアントは、決済通知を受け取ると、統合残高簿を使用して、取引の参加者の口座の残高を確認します。
4. 残高チェックが成功した場合、NSDクライアントは次のことを行います。
   
   
   • 対応する命令のステータスを「実行」に変更するトランザクションを命令スマートコントラクトに作成します。
   • そして、 Positionスマート契約の口座残高を変更するためのトランザクションを作成します。

取引の準備と実施

証券取引を規制するための承認された手順があります。NSDアラメダの標準的な証券会計システムを通じて行われる場合、取引は法的に重要と見なされます。 この条件に準拠するために、トランザクション参加者の「戦闘」デジタル署名を使用して、現在の形式の注文の形成、署名、および処理の特別な段階がトランザクションのプロセスに追加されました。 さらに、ブロックチェーンを介した注文の転送を合法と見なすために、NSDは取引の当事者とのライセンス契約および電子文書管理契約の追加契約に署名しました。



その結果、トランザクションプロセスは次のようになり始めました。

1. MegafonとRaiffeisenbankは、それぞれ独自のノードで、それぞれ販売と購入のためのカウンター命令を作成し、それらを命令スマートコントラクトに転送します。
2. 命令スマートコントラクトでは、命令は相互にマッピングされます。
3. 一致が成功した場合：
   
   
   • そのノードのNSDは、各参加者の指示に適切な注文ファイルを作成して「添付」し、その後「Alameda」にアップロードします。
   • 口座の有価証券の会計の変更に関する対応する取引は、取引参加者の残高登録簿に送信されます（位置スマート契約）
4. 取引の当事者：
   
   
   • アラメダの注文ファイルはブロックチェーンから抽出されます。
   • それぞれの職場で「戦闘」デジタル署名で署名します。
   • ブロックチェーンに戻します。
5. NSDは、参加者によって署名された注文ファイルを抽出し、Alamedaにアップロードします。
6. Alamedaはトランザクションを処理し、レポートファイルを作成してから、トランザクションの参加者に送信します。

どうでしたか

プロジェクトのすべての参加者は、ブロックチェーンを介した取引に関連する法的問題の精緻化、およびブロックチェーンネットワークを実際の条件で展開する際に発生する可能性のある技術的および組織的な問題の特定に主に興味がありました。 さらに、組織は異なり、それぞれが独自のインフラストラクチャとネットワークポリシー、外部ネットワークと内部ネットワークの相互作用のルールなどを備えています。



プラットフォームが展開される前から、最初の困難に直面していました。RaiffeisenbankとMegafonは、「奇妙な神秘的な」ソフトウェアへの現在のEDSキーに直接アクセスする準備ができていませんでした。 そのため、プラットフォームソフトウェアの外部で署名できるように、注文ファイルをアップロード/ダウンロードするための特別なユーティリティを開発する必要がありました。



プラットフォームがAmazon Web Servicesで開発およびデバッグされたという事実にさらなる困難が伴い、今では不均質なクラウド環境ではなく、厳しい異質の世界で動作する必要がありました。



幸いなことに、プラットフォームの実装にはDockerコンテナの使用が含まれていたため、異なるOS（RHELとUbuntu）の参加者による使用に関連する違いは、ネットワークノードの動作に影響しませんでした。



主な問題は、Hyperledger Fabricの内部機能と、両方の企業でネットワークインフラストラクチャが異なる方法で構築されたという事実に関連していました。

• スマートコントラクトの特性により、Hyperledger Fabricはリリース（内部アルゴリズムでコミットハッシュが使用されたため）およびプラットフォームのコンポーネントが起動されたOSのユーザー（スマートコントラクトの識別にも参加しているため）によってノードを完全に「整列」する必要がありました。
• Raiffeisenbankノードは、その外部アドレスで自身を認識しなかったため、インストールおよび構成スクリプトのいくつかの段階を<Ctrl + C>でスキップする必要がありました。
• サービスの神秘的な「固着」が発生しました。ファイルのアップロード/ダウンロードは、サービスを再起動することによってのみ除去できます。

プラットフォームの展開と構成には、Webexで約3日（9月27〜29日）および20時間かかりました。 IT環境ではいつものように、シャーマニックタンバリンがいくつかありました-「...今、私たちはちょうど7分間待っています...」



しかし、最終的には、最初の取引はグリッチとフリーズなしで完了しました。



以下は、スクリーンショット-メガフォン債を購入するライファイゼンバンクの指示と取引の最終残高です。