仲介なしのブロックチェーン：分散レジストリに証券を送信した方法

すべての経済活動は、歴史的に仲介者に基づいています。 両者間の単純な取引でさえ、銀行、取引所、決済機関などのさまざまな仲介者の関与を伴います。 仲介者を除外すると、おそらく相互作用がより効率的になります。 それでは、トランザクションの参加者が直接作業できるブロックチェーンに基づいて、新しい分散型インフラストラクチャを構築してみませんか？ この投稿では、このようなインフラストラクチャへの旅を始めた方法について説明します。ブロックチェーントランザクションを開発し、最終的にレポ（証券で保護されたお金のローン）を実施しました。

短期債

ブロックチェーンでの最初のOTC金融取引は、MTSモバイルオペレーターとNational Settlement Depository（NSD）の参加による短期債券の発行でした。 これは、すべての預託機関の一種の「中央銀行」です。 預託機関は、証券所有者の記録を保持し発行するインフラストラクチャーの仲介者です。



そのトランザクションでは、MTSはスマートコントラクトの関数を呼び出すことにより、ブロックチェーンに証券をSberbankに売却する意思の表現を記録し、ブロックチェーンでトランザクションの条件との合意を確認しました。 両当事者によって署名された反対命令は、NSDによって受信され、NSDはそれらを会計システムで実行しました。 さらに、ブロックチェーンは、取引参加者の口座を証券とお金で表示しました。



そのプロジェクトでは、クローズドエンタープライズブロックチェーンソリューションを作成するために設計されたオープンソースのHyperledger Fabric 1.1プラットフォームを選択しました。 データのプライバシーを確​​保する必要があるため、パブリックブロックチェーンはここでは適していません。 Ethereumブロックチェーンに実装されたM. Videoを使用したSberbankのファクタリングパイロットでこのような制限に遭遇しました。 対照的に、Hyperledger Fabricを使用すると、すべての参加者を専用チャネルのトランザクションに配置して、必要な情報を交換し、フル機能のスマートコントラクトで処理できます。



MTS社債発行プロジェクトのソースコードは、GitHubに公開されました。 作業のアルゴリズムに入らなくても、トランザクションのライフサイクルでは、ブロックチェーンが決済注文のトランスポートとしてかなり控えめな役割を与えられたことを理解できます。 一方、これらの指示に基づいて、口座残高は変化しました。したがって、ビジネスロジックの観点から、これは単純な電子文書管理サービスよりも興味深いものでした。



ソリューションの主な利点は汎用性でした。 「2つの取引先と1つのレジストラ」スキームは、OTC市場でのほとんどすべての取引をカバーし、わずかな変更を伴います-商業取引のほとんどが一般的です。

REPO 1.0

ブロックチェーンの新しいプロジェクトで、私たちは、分散システムでの買戻し契約を実装する方法を示すことにしました-証券で担保されたお金のローン。 通常、これらおよびその他のOTCトランザクションは、仲介業者、預託機関、決済機関、ブローカーを経由します。



このプロジェクトでは、Sberbankと外国のパートナーとの間で買戻し契約を締結しました。 Hyperledger Fabricバージョン1.2を既に使用しています。 MTSボンドと比較して、2つの違いがありました。

• 取引の2者のみがブロックチェーンに接続され、その預金者であるEuroclearとClearstreamは、Sberbankとそのカウンターパーティのバックオフィスから従来のデータ伝送チャネルを介してすべての注文を受け取りました。
  
  
• スマートコントラクトでは、複雑なビジネスロジックを実装しました：ローンの担保として機能するセキュリティの毎日の見積もりがブロックチェーンにダウンロードされ、スマートコントラクトは、担保、割引、出口交換のカレンダーの変更などのパラメーターを考慮して、早期返済の必要性と金額を計算しました。 参加者間の計算アルゴリズムのこのようなP2P同期は、分散レジストリなしでは取得できません。 これは、各当事者による義務と金額の独立した計算よりもはるかに便利です。時間のかかる調整や確認は不要です。
  
  

カウンターパーティ間で、チャネル内でチャットとワークフローを編成しました。 それらのデータはブロックチェーンに保存されていました。 分散レジストリを変更するたびに、チャネルメンバーは電子メールアラートを受け取りました。



「REPO 1.0」は法的側面から解決しました。 ある大手法律事務所の助けを借りて、ロンドン高等裁判所の事件の分析が行われました。 さらに、銀行とその取引先のEDSは異なる暗号化アルゴリズムを使用しました。

REPO 1.0はどのように機能しますか？

トランザクションの各パーティには、独自のブロックチェーンノードがあります。 すべてのノードは、P2Pネットワークで互いに接続されています。 取り引きが必要だとします。 取引の当事者間でスマート契約を展開します。ここでは、金融商品が完全に記述されています。







私たちの側から契約を作成した後、トレーダーによって署名されます。 また、クライアントは契約を確認して署名します。 次に、署名が確認および検証されます。 この場合、取引は英国の法律の下で行われ、電子デジタル署名のデータはGMRA文書に入力されました。 クライアントの一部にサインオンするには、権限のある人が署名証明書に存在することの検証が必要です。 最後に、クライアントは契約を受け入れ、すべての条件に同意します。 署名済みの契約には、任意の数のドキュメントを添付できます。



その後、契約は「作業中」のステータスを受け取ります。 新しい市場価格をロードすると、「作業中」の契約が自動的に再計算されます。 契約に証券がある場合、市場価格が取得され、Loan-To-Value（LTV）が再計算されます-証券の証券の価値に対する融資額の比率。 LTVは買戻し契約の重要な条件の1つであり、その意味は契約で規定されています。 株価は急激に上昇し、LTVはGMRAで示されている価格よりも低くなっています（英国の法律に関しては）。 したがって、銀行は、新しい価格を考慮に入れて、銀行がより高いセキュリティを保持していることが判明するため、証券を顧客に（オプションの1つとして）返します。



しかし、LTVが大きくなると、プログラムは担保通知（追加のセキュリティ（株式または金銭）を作成する必要性に関するクライアントへの通知を印刷して、LTV値が最初の通知に戻るようにします。 以前は、担保通知はメールでのみ送信でき、このために個別のドキュメントが作成され、これらのドキュメントの作成中にLTVが再び変更される可能性がありました。 これで、オンラインのクライアントで同じ計算が表示され、簡単に対話できます。



さらに、プログラムは、利息を考慮して証券の買戻しの価格を毎日修正します。 クライアントが市場価格をロードするときに同意しない場合、彼は完全な再計算ログを調べます-何が、何になり、どの価格がロードされ、どこから来たのか。 そして、チャットの議論が始まります。

レポ2.0

ブロックチェーン上のREPOが、内部ロジックに基づいて実際の資産の移動を開始できるようにしたかったのです。 しかし、REPO 1.0では、西洋の預託機関の接続に関する組織上の困難のため、これをまだ達成できていません。 そこで、新しいRepo 2.0パイロットを開始しました。 彼には2つの目標がありました。

• 取引は、MTS債券プロジェクトのインフラストラクチャを最大限に活用するために、2者と預託機関の参加を得て開催する必要があります。
  
  
• 担保を再評価し、分散ネットワークに接続された預託機関が自動的に実行できるマージンコールを設定するには、ブロックチェーンを強化する必要があります。
  
  

NSDはすぐにプロジェクトに接続したいと考えました。 国内金融市場を管理する連邦法の保守的な分野でブロックチェーンで開始されたトランザクションを獲得するために、電子文書管理契約の5ページの補足契約を弁護士と協力しました。 これは、トランザクションとNSDのすべての関係者によって署名されました。



NSDは、このトランザクションでクリアリングハウスとして機能しました。 彼は、資金と証券の移動に関するすべての指示を実行しました。 この取引はロシアの法律の下で締結されました。



クライアントは電子署名を使用して契約を受け入れました。 その後、Sberbankはその署名を使用して契約を承認しました。すべてのパラメーターが必要な値に準拠しているか、クライアントから承認した人の権限を確認しました。 その後、契約が機能しました。 NSDが市場データをアップロードし、スマート契約が再計算されました。

REPO 2.0はどのように機能しますか？

ネットワークの展開と、クライアントインターフェイスとチェーンコードの相互作用には、 Fabric Starterソリューションを使用しました。 HLFの標準grpcインターフェースの代わりに、REST APIを提供します。この場合、統合の複雑さが大幅に削減されました。







ネットワークは次のようにアップしました。 Dockerサーバーへの事前インストール後の3つの側面のそれぞれがFabric Starterを起動し、ノードのコンポーネントでコンテナーを作成しました。 これらのコンポーネントには、他の組織と対話するための外部ピア、およびノー​​ドがクライアントアプリケーションと対話するためのREST APIサービスが含まれていました。 Starterが起動すると、ブロックチェーンネットワークも構成され、endorsement-policyを使用したチェーンコードがインストールされたプライベートチャネルが作成されました。 この場合、各トランザクションには3人の参加者全員の署名が必要です。



テスト段階では、参加者のサーバー間の通信を整理するためにDocker Swarmが使用されましたが、実際の取引を行うために、参加者はDNSに切り替えました。 プラットフォーム自体がメッセージの転送を担当し、データはTLS暗号化を使用してインターネット経由で送信されます。

問題の技術面

HLFでの分散アプリケーションの開発プロセスは、データ構造とチェーンコード（実際には、ストアドプロシージャのセット）で非常に伝統的に始まります。その呼び出しは、元帳からのこれらの構造の保存、変更、読み取りにつながります。 このプラットフォームでは、ローカルストレージ用のチェーンコードとDBMSの開発にさまざまなプログラミング言語を使用できます。 それぞれGoとCouchDBを好みます。



データモデルのレポの中心的なエンティティは、契約自体とその子会社です。 これらは、マージンコールと同様に、2人のパイロットのそれぞれに対して作成されました。 このアーキテクチャは、「注文」の本質に基づいたMTS債券モデルと比較して一歩前進しました。 独立したオブジェクトも証券用に作成されたため、部分的にトークン化されました。 しかし、アカウント管理とお金の仮想トークン化を使用した実験の開発により、ソリューションの次のバージョンのいずれかに延期することにしました。



ソリューションの主な機能：

• 契約を作成します。
  
  
• EDSと契約書に署名し、契約条件への同意を確認します。
  
  
• 市場価格をダウンロードし、担保価値の再計算を開始します。 設定されたしきい値からの逸脱により、新しい証拠金請求義務が発生しました。
  
  
• 義務のステータスを反映します。
  
  

技術面では、再評価手順がここで最も興味深いです。 詳細に分析します。



ビジネスプロセスでは、Oracle（NSDによって実行された「REPO 2.0」のパイロット）が更新された証券相場をシステムにアップロードした後、手順を1日に1回起動する必要があります。

func (t *CIBContract) recalculationData(stub shim.ChaincodeStubInterface, loadData *loadDataType, curDay string) pb.Response {...}
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

手順のメインサイクルは、相場が更新されたすべての証券を通過します。

 for _, securities := range loadData.Securities {...}
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

次に、いくつかのチェックが実行されます。 たとえば、市場データを受信した取引所が今日1日休みの場合、再集計は発生しません。

 if t.checkHoliday(stub, contract.Settings.Calendars) == "yes" { hisYes := historyType{curDay, "LoadData. Calendar", "System", "LoadData. Today is holiday ! No load market data to contract !"} ... contract.History = append(contract.History, hisYes) … err = stub.PutState(contrID, contractJSONasBytes) }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

更新された債券価格を計算するために、未収クーポン利回り（NDC）が読み込まれた正味価格に追加されます。 パイロットは、NKDを計算するための30/360スキームのサポートを実装しました。

 priceIzm = float64(securities.Price + float64(securities.CouponRate)*float64((int(settlementDate.Year()) - int(dateStart.Year()))*360 + (int(settlementDate.Month()) - int(dateStart.Month()))*30 + (int(settlementDate.Day()) - int(dateStart.Day())))*100/360/100) curCurrVal = priceIzm
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

取引通貨が証券が提示されている通貨と異なる場合、為替換算が実行されます。

 if contract.GeneralTerms.PurchasePrice.Currency != securities.Currency { curCurrName = securities.Currency + "-" + contract.GeneralTerms.PurchasePrice.Currency               for _, currency := range loadData.Currencies {              if currency.Name == curCurrName {                           curCurrVal = priceIzm * currency.Value } } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

次に、LTVを計算する必要があります。 ストーリーの古い係数値を保持します。

 oldCurLTV := contract.MarginingTerms.CurrentLTV
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

トランザクションの存続期間中に実行されるマージンコールを考慮する必要があります。 要件は、2つの形式で両方から得られます。

• 証券。 借り手は、証券の市場価格が下落した場合に追加の証券を作成します。 債権者は、価格が上昇した場合に証券の一部を返却します。
  
  
• お金。 借り手は予定より早く、より安い担保でカバーされなくなったローンの一部を返済します。 貸し手は、担保の価値の増加に応じてローン金額を増やします。
  
  

最初のケースでは、担保の有価証券の量が単に更新されます。 そして、それらでお金を稼ぐ場合、取引の追加条件で指定された利回りを発生させることも必要です。

 for _, addCollateral := range contract.MarginingTerms.AddCollateral { currSumCollateral := addCollateral.Sum + (addCollateral.Sum*contract.MarginingTerms.RateOnCashMargin*float64(deltaColDate) / float64(contract.MarginingTerms.Basis))/100 ... allSumCollateral = allSumCollateral + currSumCollateral ... ht := historyType{curDay, System", "LoadData. Recalculation data(addCollateral) Contract " + contrID + " - currSumCollateral: " + strconv.FormatFloat(float64(currSumCollateral), 'f', 2, 64) ... }        ... contract.History = append(contract.History, ht) }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

買戻しの合計額を計算します。実際、これは利息のあるローンの額であり、返済する必要があります。

 rePurchasePriceCur := contract.GeneralTerms.PurchasePrice.Sum + (contract.GeneralTerms.PurchasePrice.Sum*contract.GeneralTerms.RepoRate*float64(deltaSigningDate)/float64(contract.MarginingTerms.Basis))/100
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

次に、LTV係数を計算します。 これを行うには、買い戻し価格から現金での証券を差し引き、結果の価値を証券内の証券の合計価値で割ります。 債権者によってクレジットされた金額は「-」でマークされ、買い戻し価格に追加されます。

 contract.MarginingTerms.CurrentLTV = (rePurchasePriceCur - allSumCollateral) * float64(100) / (float64(contract.GeneralTerms.PurchasedSecurities.Quantity) * curCurrVal)
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

最後に、コントラクトのトリガーを計算します。 LTV値が指定されたコリドーと異なる場合、同じ手順でマージンコールオーダーオブジェクトが作成されます。

 contract = t.checkTriggerEvents(stub, "LoadData", contract, curDay, securities)
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

そして、UIに表示するための情報を履歴に書き込みます。

 ht := historyType{curDay, "System", "LoadData. Recalculation data(change curLTV, ADTV) Contract " + contrID + " - oldCurLTV: " + strconv.FormatFloat(float64(oldCurLTV), 'f', 2, 64) + ", newCurLTV: " + strconv.FormatFloat(float64(contract.MarginingTerms.CurrentLTV), 'f', 2, 64)...} contract.History = append(contract.History, ht)
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

まとめると

このようなスキームは、証券や契約だけでなく、他のシナリオでも機能します。 たとえば、電力料金が異なる場合、料金も料金も接続時間も異なります。 またはファクタリング-商品の出荷のシグナルによるサプライヤーへの貸し出し。 経済学では、誰もが検証する必要のある独自のデータソースを使用する多くのユーザーケースがあります。



私たちの目標は、銀行を全国および全国の顧客と接続し、スマート契約を使用して、暗号ではなく伝統的な経済の契約である金融商品を記述するネットワークを作成することです。 このようなネットワークは安定しており、オープンであり、P2Pネットワークにあるべきであるため、ここの誰も特別なステータスを持ちません。