Rチェーンブロックチェーンプラットフォーム：一般的なアーキテクチャと進化

企業および企業間プロセスでの分散型プラットフォームの使用の開発をフォローしている人々にこんにちは。このトピックに関する私たちの出版物は、2018年の初めに中断されました。いいえ、Raiffeisenbankはこの方向での作業を停止していません。方法論的な計算と個々のテクノロジーの機能の習熟から、産業環境または可能な限りそれに近い特定のビジネスケースの実装に移行する時が来ました。この記事は非常に膨大であると同時に有益です。したがって、皆様のご参加をお待ちしております。チュートリアルの形式について警告してください。











2016年から2017年にかけて、分散型貿易金融プラットフォームを構築するための多くの研究プロジェクトを完了しました。基盤となる分散型台帳プラットフォームとしてテストEthereum（Rinkeby）を使用し、分散型ファイル共有ツールとしてEthereumSwarmを使用しました。分散型プラットフォームの構築に関する一般的な問題に加えて、スマートコントラクトの可能性、オラクルの使用、およびアービトレーションスマートコントラクトをテストしました。これらの結果のいくつかは





これらの研究プロジェクトに基づいて、





このかなり長い作業の結果は、軍が言うように、通常の分散型RチェーンプラットフォームのITRaiffeisenbankの「供給の受け入れ」でした。現在、さまざまな規模の企業グループ向けのカスタマーサービスの要素として提供されています。



このプラットフォームを構築する主な機能を共有し、ブロックチェーンプラットフォームや分散ファイルシステムなど、さまざまな「技術的」コンポーネントの使用の進化についても説明します。

コンテンツ

• 企業および企業間システムの機能
• 一般的なプラットフォームアーキテクチャ
  
  
  • ソフトウェアコンポーネントのアーキテクチャ
  • ワンストップビジネスプロセス
  • ワンストップビジネスプロセスを使用する利点
  • 一般的なビジネスプロセスを使用することのデメリット
  • ホストネットワークの監視
• さまざまな技術コンポーネントの使用の進化
• 企業プラットフォームの研究と運用およびそれらのさらなる開発の経験

企業および企業間システムの機能

プラットフォームの産業運用への実装がスムーズに進行し、開発者にとって予想外の過剰が発生しないようにするには、将来の参加者に提案されるプラットフォームが次の要件を満たしている必要があることを理解する必要があります。

• プラットフォームには、その機能について参加者に責任を負う法的エンティティであるオペレーターが必要です。オプション-すべての人が自分自身のために、すべてが参加者のコンセンサスによって決定されるなど、パブリックブロックチェーンプラットフォームで一般的なものは、ここでは機能しません。
• , . , - - 15 — , .
• « » , . , , , « » , .
• , , . , — .
• «» . , - — , , . , , — , .

このリストの多くは、「1秒あたりのトランザクション数」という単語やその他のパフォーマンス評価が欠落していることに驚かれることでしょう。私たちの経験によると、プラットフォームの実装を成功させるには、生産性が最も重要な条件ではありません。パフォーマンスは「十分」である必要があり、データレジスタからラテラルターボストリームまで、基盤となるプラットフォームのスループットを劇的に向上させることができる多くのデータフローアーキテクチャがあります。上記の点に注意を払わなかったためにプロジェクトが終了する可能性は、双曲線的に高くなります。

一般的なプラットフォームアーキテクチャ

ソフトウェアコンポーネントのアーキテクチャ

2016〜2017年に調査プロジェクトで使用したアプリケーションは、ダイアログインターフェイスと分散プラットフォームの「技術的」コンポーネントであるgethおよびswarmとの直接統合に基づいて作成されました。しかし、このアプローチの可能性と結果を分析した結果、ビジネスバックエンドと「技術的」コンポーネントの間に別のレイヤー（統合されたビジネスオブジェクトのアダプター）を導入する必要があるという結論に達しました。この手法は、ソフトウェアアーキテクチャを構築するためのかなり標準的なパターンに属していますが、それでもその有効性は低下しません。その結果、プラットフォームのノードのソフトウェアアーキテクチャは、次のようになり始めました







。このアーキテクチャでは、ビジネスアプリケーションDLTコンポーネントの抽象化では直接機能しませんが、特定の条件付き「ユニバーサルビジネスプロセス」（以下、プロセスと呼びます）で機能します。プロセスを作成し、プロセスの状態を変更します。ユニバーサルプロセスのデータ構造とその操作を、DLTクライアントで使用されるデータと操作に縮小することは、「ビジネスプロセスのミラー」として指定された一連のコンポーネントによって実行されます。 「ミラー」は、DLTクライアントから受信した情報の逆変換も実行し、参加者（ノードの所有者）に関係のないプロセスによって情報をフィルタリングします。したがって、各ノードで、このノードが参加するビジネスプロセスのデータベースは、同期状態で、ビジネスアプリケーションに最も便利な形式で保持されます。ビジネスアプリケーションこのデータベース（ビジネスプロセスのデータベース）と対話し、プロセスの状態に関する情報を受信し、操作を転送してこれらの状態を変更します。

ワンストップビジネスプロセス

当然のことながら、ブロックチェーンプラットフォームの利点を最大限に活用し、ビジネスアプリケーションで使用するための柔軟性と機能を最大限に活用するために、どのプロパティにユニバーサルビジネスプロセスを付与する必要があるのか​​という疑問が生じました。追加の条件は、選択したプロパティをほとんどの一般的なDLTプラットフォームに実装できることでした。その機能は、いくつかの側面（Ethereum / Quorum / Masterchain、Hyperledger Fabric、Corda、EOS、Waves）で大幅に異なります。私たち自身や他の人のプロジェクトの経験に基づいて、私たちは次の結論に達しました。



ユニバーサルビジネスプロセスには、次の属性が必要です。

• プロセスパラメータ（プロセスタイプ、ステータス、プロセスのコンテキスト属性）
• プロセス参加者の役割リスト
• プロセス関連の電子文書のリスト
• プロセス遷移マップ

同時に、プラットフォームは、ブロックチェーンコンポーネントレベルで、ネットワーク内のプロセスの分散に次の条件を提供する必要があります。

• 情報の完全性と完全性
• プロセスの参加者のサークル外の電子文書の機密性
• プロセス遷移マップに従う制御
• プロセス状態の変更の履歴を保存する

これらの機能を実装するために、対応するプロパティとメソッドのセットを使用して「フレームワーク」スマートコントラクトが開発されました。



リストされている属性と条件のいくつかについて詳しく見ていきましょう-何を、どのように、そしてなぜ。



プロセスパラメータ-スマートコントラクトを介して直接送信されるため、条件付きでオープンです。一部のブロックチェーンプラットフォームでは、基本的にパブリック（Ethereum / Masterchain）であり、その他のプラットフォームでは、データのプライバシーを確​​保する標準的な手段（Quorum-プライベートスマートコントラクト、Hyperledger Fabric-チャネルおよびプライベートデータ）で閉じることができます。おそらく、実装におけるプロセスの「コア」のパラメーターの中で最も重要なのは「プロセスのタイプ」です。これは、セマンティックだけでなく機能的な負荷も伴うためです。「プロセスのタイプ」に応じて、DLTアダプターはこのプロセスとなるスマートコントラクトテンプレートを選択します。自己紹介をしてください。なぜこれが必要なのですか？明らかに、無数の種類のトランザクションと、それらの実装を保証する同じ多様なビジネスプロセスがあります。かなり多くの場合、ビジネスプロセスは基本的に（プラットフォームの観点から）移行マップのみが異なり、任意の移行マップをサポートする単一のスマートコントラクトで実装できます（詳細は以下を参照）。しかし、非常にユニークな瞬間を特定のビジネスプロセスに関連付けることができます。

• (, )
• (, )
• (, )

この潜在的な多様性をすべて形式化して「フォーマット」し、スマートコントラクトの単一のテンプレートに詰め込もうとすることは、絶対に理想的です。特定のタイプのビジネスプロセス用の独自のテンプレートの開発は、高い柔軟性と、必要なプロセス要素と重要なチェックをブロックチェーンコンポーネントの「コア」に直接「ハード」フラッシュする機能の両方を提供するはるかに効率的な方法です。これにより、個々の参加者による操作の可能性が排除されます。さらに、プラットフォーム全体として、ビジネスアプリケーションとプロセスとの相互作用のためのインターフェイスの統合と、特定の機能の実装の高いモジュール性が組み合わされます。



プロセスの「カーネル属性」には、「ステータス」と「メモ」も含まれます。最初はプロセス状態の簡単な説明（「新規」、「キャンセル」、「クローズ」、「OnApproval」）、2番目は「長い」文字列です。 「ステータス」の詳細な説明。プロセスに添付された電子文書は大量の情報（特に機密情報）を転送することを目的としているため、メモの長さを約1000文字に制限します（たとえば、「アカウントの資金が不足しています」）。



プロセス遷移マップ-特定の役割を持つ参加者がプロセスの状態を変更できるかどうか、およびどの参加者に変更できるかを説明します。遷移の許容性の制御は、ブロックチェーンコンポーネントの「コア」によって実行され、「無力な」参加者が偽造することはできません。さらに、ナビゲーションマップは、たとえば、ビジネスアプリケーションで使用して、ダイアログコンポーネントを適切に管理するために、プロセスの現在のステータスでノード所有者が実行できるアクションを決定できます。



機密データの転送。機密情報を転送するために、プロセスに添付されている電子文書が使用されます。ビジネスアプリケーションは、必要なドキュメントをローカルファイルストレージ「ミラー」にアップロードし、プロセスの状態を変更するための操作でそれらを示します。ローカルストレージからDFSに転送する前に、ドキュメントは受信者ノード（プロセスの参加者）の公開キーで暗号化されます。生成された暗号コンテナがDFSに転送された後、そのコンテナへのリンクと元のドキュメントのハッシュがプロセスのスマートコントラクトに転送されます。プロセスの状態の変化に関する情報を受信すると、ファイルの詳細がビジネスプロセスデータベースに抽出され、リンクを使用して暗号コンテナがDFSから抽出され、受信ノードのキーで復号化されます。プロセスのスマートコントラクトで指定されたドキュメントのハッシュ合計が一致することを確認するためのチェックが行われます。ドキュメントはローカルファイルストレージに配置され、ビジネスアプリケーションで使用できるようになります。したがって、ビジネスアプリケーションは、ドキュメントの「オープン」バージョンでのみ機能します。その安全な転送に関するすべての心配は、「ミラー」によって引き継がれます。



プロセス状態変更の履歴は一連の「フレーム」であり、各フレームはプロセス状態変更の1つの操作に対応します。この実装では、履歴の「フレーム」ごとに次のデータを保存します。

• 状態
• 注意
• 状態変更トランザクションの開始者の識別子

変更の履歴はスマートコントラクトレベルで記録され、監査目的で遷移のシーケンスを追跡できるだけでなく、ビジネスアプリケーションが、一度だけ到着した場合（たとえば、フリーズ、機能の中断など）でも、一連のイベントを正しく処理できます。



法的重要性の確保-非常に重要な問題であり、「企業および企業間システムの機能」のセクションで指摘されています。私たちは当初、法的な重要性はブロックチェーンプラットフォームによって提供されるべきではなく、規制上のサポートまたはプラットフォーム参加者間の適切なレベルの信頼を備えた外部PKIの使用を通じて提供されるべきであるという概念から始まりました。大まかに言えば、あなたの行動の法的根拠（支払い文書、契約、要求など）を提供し、プロセスに添付される電子文書は、「kosher」PKI（ロシアでは-GOST、たとえば海外のどこか）に基づいて署名する必要があります。 SSLまたはPGP / GPG）。ビジネスアプリケーションは「外部」署名を検証し、適切なアクションを実行します。結果に応じて、そうでないか。誰かが言うだろうこれは「福音的」ではなく、「ブロックチェーン取引の法的重要性を弁護士に納得させる必要がある」ということです。私たちはこの旅の多くのステップを経ましたが、結果は常に同じでした。しかし、ロシアの場合マスターチェーン認定は、この点で特定の機会を開きます-言われているように「ハッピーハンティング！」

ワンストップビジネスプロセスを使用する利点

このアプローチは最終的に私たちに何をもたらしましたか？

• 分散型ビジネスアプリケーションの潜在的な開発者の輪を拡大します。 «» - - , - «» , . . -, Corda, «» Ethereum, Quorum. , - «» - .
• «» . , , , , , - . , «» «» ( ), «- » . , « , ...», . «» -, «» . , «» -, . , - , . , , , , , , «» insufficient funds for gas * price + value gas required exceeds allowance or always failing transaction.
• «» -. - - , -. -, , 75-95% . , , « , » . , :
  
  
  
  >>> - DFS, , , «» -. Ethereum, «» . - (TON!), . , . … , , .
  
  
  
  >>> - . , Ethereum — , , , , , — .
• . . . , , , , , , . , , , , — .
• . , , « , ». , . — -. , - ( ) — - .

-

ここでは、おそらく、有名な曲「背後でつぶやきが聞こえます...」で歌われているように、Hyperledger FabricまたはCordaチェーンコードは、少しエレガントすぎるSolidityとは異なり、ビジネスプロセスのほぼ無限に複雑なロジックを実装できます。このアプローチはそれらの機能を冒涜します。ええ、はい、彼らは絶対に正しいでしょう。せせらぎの人たちに、ソフトウェアエンジニアリングの分野からのいくつかのよく知られたメッセージを思い出させます。

• データベースの保存されたプロシージャまたはビジネスアプリケーションのコードのどこにビジネスロジックを配置しますか？
• メインフレームと特別なコンピューターのどちらが良いですか？
• 選択したベースラインは、将来のライフアップデートにわたって互換性を維持しますか？そして、一般的に、それは次の2年間生き残るでしょうか？

次の場合、答えは簡単です。

• あなたにはたくさんのお金、時間、そして無料のブロックチェーンスペシャリストがいます
• 選択したブロックチェーンの基礎を「決して」という言葉から変更する必要がないことは間違いありません。
• プラットフォームの機能を101％「絞る」必要があります

さて、それでは-特別な計算機...ハイパーレジャーファブリックまたはコーダの意味で、チェインコードにステッチを施し、その他の「石で彫る」。そうでない場合は、自分で考えてください...

ホストネットワークの監視

おそらく一部の人にとってはそれは啓示となるでしょうが、よく組織化された監視は、企業におけるソフトウェアシステムの運用を成功させるための基礎です。そして、この概念には、サーバーの標準的なインフラストラクチャの監視だけでなく、ソフトウェアコンポーネントの機能の監視も含まれます。分散プラットフォームは正しく機能するだけでなく、正しく間違いを犯し、障害をすばやく特定、特定、修正できる十分な量の適切な情報をサポートサービスに提供する必要があります。監視システムにプロアクティブな機能があるとさらに優れています。これにより、潜在的な「悪いこと」を特定し、「発生」する前に起こりうる結果をブロックできます。



ネットワークのノードがどのような状態にあり、ノードで何が起こっているのかを常に理解していないが、「ユーザーのシグナルに従って」機能する場合は、キュー内のスペースをすぐに解放し、親愛なる顧客の時間をとらないほうがよいでしょう。



以上を踏まえ、プラットフォーム開発当初からプロアクティブなモニタリングシステムを構築してきました。その動作の原理を説明しましょう：

• プラットフォームのブロックチェーンベースで、監視データの収集と配布を担当する特別なスマートコントラクトが確立されます（簡潔にするために、このスマートコントラクトをSCMと呼びます）。
• , (), « », , . , - .
• - « », — .
• DFS- « », .
• , DFS .
• , , :
  
  >
  
  > «» -
  
  > «» DFS
  
  > - ( Ethereum- )
  
  > «»
  
  > «» — , «»
  
  > «»
  
  > «»
  
  >ビジネスアプリケーションからの監査証跡

インジケーターを監視するための特定の値または値の組み合わせで、ミラーは操作のキューの処理を自動的に一時停止し、潜在的な望ましくない結果の出現をブロックします（例：

• ブロックチェーンチャネルの制御ラベルに重大な遅延が発生した場合。これは、ノードがブロックチェーンネットワークから脱落したか、その機能が完全に中断したと解釈されます。
• DFSチャネルの制御ラベルに重大な遅延が発生した場合。これは、DFSネットワークからのノードの損失またはその機能の完全な中断として解釈されます。
• 操作キューにエラーが発生した場合、このビジネスオブジェクト（ユニバーサルビジネスプロセス）に関連付けられた後続のすべての操作がブロックされます

「ミラー」が使用するデータベースエラーの処理には特別な注意が払われました。このデータベースは、ビジネスアプリケーションとのインターフェイスとしてだけでなく、「ミラー」操作キューのステートマシンのステータススタックとしても使用されます。経験によれば、データベーステーブルのデータを変更するときに特定のエラーが発生すると、トランザクションの大量の再送信やその他の楽しみを伴うループ操作が発生する可能性があります。かつて、同様の間違いのために、私たちは2日間でQuorumのチェーンの半年ごとのボリュームを「作成」しました。したがって、この種のエラーが検出された場合、「ミラー」は完全にオフになり、サポートサービスからの手動応答を待ちます。



中央監視ノードは、SCMからすべてのネットワークノード（ちなみに、それ自体を含む）から情報を抽出して分析し、次のような危険または潜在的に危険な状態をタイムリーに検出できるようにします。

• - DFS-
• - DFS-
• -
• «»
• «»

次の図は、テストネットワークの1つで最も単純なモニターの例を示しています。







ビジネスアプリケーションを含む、より「高レベル」のプロアクティブな監視スキームが開発および実装されましたが、ここでは、特定の顧客の知的財産の不安定な境界に到達します。



一部のブロックチェーンネットワークでは、トラフィックの監視が総トラフィックの圧倒的多数を占めているという事実を隠さないでください。この点で、「小包の調査」の頻度に浮動タイムテーブルを使用するという考えさえありました-より頻繁に就業時間中に、より少ない頻度で非就業時間中に。でも、その価値はある。本当に。



一般に、分散型ネットワークの帯域幅が許す限り、考えられることは何でも監視します。もちろん、プログラミングの神々、そしてこの記事の著者を1、2回以上称賛するでしょう:)



マーフィーの法則の解釈の1つが言うように、「エラーは通常、誰も疑うことのない立場にあります」。

さまざまな技術コンポーネントの使用の進化

企業の分散型ネットワークの展開と運用の一般的な条件、およびR-Chainプラットフォームの構築に使用したアーキテクチャの原則を検討した後、特定のプロジェクトを実装する過程で個々の技術コンポーネントがどのように、そしてなぜ進化したのかについて説明します。



1つ目は、2018年3月から12月にかけて、パートナーがベラルーシの同僚である国際保証を発行するプロジェクトでした。



私たちは、Ethereum-Ethereum Swarm-Crypto-Pro（DLT-DFS-cryptography）構成から始めました。これは、研究プロジェクトで十分に証明されています。使用されたEthereumRinkebyパブリックテストPoAネットワークの代わりに、EthereumPoAプライベートネットワークとEthereumSwarmプライベートネットワークが作成されました。当初、技術的な問題はありませんでしたが、「暗号化」の問題が発生しました。ベラルーシの参加者の1人が、電子文書管理に関する現地の法律を参照して、提供した暗号化ツールの使用を断固として拒否しました。当時、「現時点で」高品質のソリューションを見つけることはできませんでしたが、国際的なプロジェクトの成功における暗号化の困難で重要な役割については着実に理解されていました。



実際のネットワークインフラストラクチャで制御トランザクションを実行するプロセス（各参加者がリソースにノードを展開した）で、Ethereum Swarmの作業の失敗が特定されました。ファイルの損失は20％のレベルでした。複数のファイルを並行して送信する場合のSwarmクライアントの問題が原因で損失が発生することが示唆されています。一般に、この仮定は確認されました。実験的に、5秒で個々のファイルをSwarmに送信する間に一時停止を見つけることができました。 Raiffeisenbankインフラストラクチャで使用されるネットワークセグメンテーションの特殊性のために、トランジットスウォームノードの作成を必要とする完全な戦闘ネットワーク構成への移行中に、重大な問題が発生しました。「階層化された」アーキテクチャと優れた監視システムにより、「ガソリンの手動ポンピング」モードで保証の実際の問題を正常に実行することが可能になりましたが、EthereumSwarmの運命は封印されました。直接の送受信接続のないトポロジで動作するEthereumSwarmの宣言された機能は、DFSの技術的基盤としてEthereum Swarmを選択した主な理由のひとつであり、このモードで確実に動作できないことが多くの問題を引き起こしたと言わなければなりません。そして、このモードで確実に動作できないことは、多くの問題を引き起こしました。そして、このモードで確実に動作できないことは、多くの問題を引き起こしました。



このプロジェクトのEthereumに基づくプライベートネットワークは、その回復可能性に満足していることに注意する必要があります。プロジェクトのスケジュールは、発行された保証の終了が発行の3か月後に行われることを想定しており、この一時停止中に、一部の参加者はノードを停止しました。それにもかかわらず、1日でタンブーリンとのダンスなしでネットワークを再起動すると、それはその完全性を回復し、保証を閉じる操作は何の不満もなく進みました。



次のプロジェクトは、2018年9月のAscona Group ofCompaniesのグループ内ネットワークの作成でした。



国際保証プロジェクトの経験に基づいて、IPFS（InterPlanetary File System）がDFSの技術的基盤として選択されました。ファイルを並行して送信する場合は正常に機能し、特別なモード調整は必要ありませんでした。おそらく、IPFSの唯一の弱点は、「トランジット」トポロジで作業できないことです（指定されています！）。多数の参加者がいるネットワークを構築する場合、それぞれからそれぞれへのアクセスの「フルスター」をそれぞれが実装することは、控えめに言っても、組織的な問題です。一方、すべての参加者は、自分自身とオペレーターの「サポート」ノード間のアクセスを実装します。したがって、ファイルのスムーズな配布を整理するために、次のメカニズムが実装されました。

• 特定のビジネスプロセスのスマートコントラクトにファイルが添付されると、ファイルへのリンクを含むDeliveryFileイベントが生成されます
• DeliveryFile IPFS. IPFS , , . .
• , , , «» ,

したがって、Asconaプロジェクトは、Ethereum-IPFS-Crypto-Pro構成で開始されました。



Crypto-Proを使用してファイルを暗号化し、法的に重要なドキュメントの「外部」署名を使用することで、法的拘束力が単純になり、情報セキュリティ部門からのクレームがなくなり、銀行とAscona GroupofCompaniesの企業の当事者。一般的に、プロジェクトは正常に開発され、パイロット段階を通過した後、生産に移行するためのフィニッシュラインにありました...



...そしてここで一度に2つのプロジェクトで-条件付きで「エイリアン」ですが、専門家として参加しましたが、同様の構成で、ネットワークの一部のトランザクションが失われ、数千ブロックのメガフォークをキャッチしました。ログの分析とブロックチェーンコミュニティの解釈により、期待外れの結論が導き出されました。ノード数が少ないコンパクトなネットワーク（および企業ネットワークがここに正確に属している）でEthereum PoA（場合によってはPoW）を使用すると、そのようなモンスターのリスクが高くなります。さらに、ノードがネットワークから脱落し、ノードと同期する必要がなくなったときに、テストネットワークに不思議なバグが定期的に発生し始めました。 Ethereumを再インストールし、完全に削除した後でも。つまり、prodネットワークにはブロックチェーンベースの代替手段が必要であることが明らかになりました。そして速い。とても早い。



解決策はクォーラムであることが判明しました-実際には、Ethereumの兄弟です。「ミラー」の改善の数は最小限でした。もちろん、ビジネスアプリケーションはまったく改善を必要としませんでした。



現時点では、クォーラムへの移行には次のような利点しかありません。

• 使用されるいかだコンセンサスはフォークを排除します
• 空のブロックがないため、チェーンのサイズが小さくなります

フォークがないため、トランザクションの潜在的なロールバックを処理しないために以前は必要だったトランザクションの条件付きファイナライズを待つ間、一時停止することなく実行でき、最大6ブロックの生成サイクルがありました。これにより、第一に、プラットフォームのパフォーマンスが自然に向上し、第二に、フォークが計算された一時停止を超え、接触する「ミラーリングされた」ビジネスオブジェクトの状態がブロックチェーンの状態と一致しなくなった場合に発生する非常に難しい問題が解消されます。



Quorumの唯一の、おそらく不快な機能は、長い一時停止後の再起動時にサイズが数メガバイトのメガブロックを生成する機能です。これは、コンテンツをアンロードしようとするとDLTアダプターを単に妨害します。しかし、厳密に言えば、サービスデスクはそれほど長く眠るべきではありません。



この劇的な進化の結果として、私たちはクォーラム-IPFS-Crypto-PRO構成に到達しました。これは、現在ロシア国内市場で使用されています。



おそらく誰かが論理的な質問をするでしょう：「まあ、あなたはこれまでクォーラムについて聞いたことがないのですか、それとも何ですか？」..。 Quorum、Hyperledger Fabric、およびEOSについて聞いたことがあります。この記事の著者は、2017年の秋にロシア語で行われた最初のCordaワークショップにも参加しました。おそらく、特にそのような質問へのインテリジェントな答えのために、ヘーゲルは彼のダイアレクティクスを発明しました。 2016年に調査を開始した小さなチームは、Windows用のインタラクティブアプリケーションの開発に優れた経験を持っており、パブリックEthereum（テスト1は理解できます）は、ブロックチェーンプラットフォームからのエントリしきい値が最低でした。また、さまざまなドッカーをいじくり回すことではなく、特にブロックチェーンのトピックに関する調査を行うことに関心があったため、「アダルト」クォーラムまたはハイパーレジャーファブリックを起動することは非現実的です（すべての仮想Windowsプラットフォームで実行できるわけではありません）。明白でした。研究結果が銀行の事業部門とそのパートナーの注目を集め始めたとき、チームの拡大、靴職人へのブーツの委託、ケーキへのパイの委託、Linuxサーバーの入手などが可能になりました。そして、当然のことながら、開発の可能性を保持している限り、開発されたソリューションを捨てることはありません。ダイアレクトと進化。

企業プラットフォームの研究と運用およびそれらのさらなる開発の経験

この記事の著者は、Raiffeisenbank、FinTech Association、およびその他の場所で、開発者として、また分散型プラットフォームの専門家として、かなりの数のブロックチェーンプロジェクトに参加しました。それらのいくつかは純粋に研究プロジェクトであり、いくつかはパイロットとして終わり、いくつかは数十ノードのかなり大規模な産業ネットワークに成長しました。



このすべての経験から引き出すことができる主な結論は何ですか？



1.特定の種類のブロックチェーンプラットフォームがあり、それらの「消費者」の品質は大きく異なります。

• 「エントリのしきい値」とネットワーク展開の容易さ
• 帯域幅
• スマートコントラクトの機能
• 情報閉鎖オプション
• 開発時間とコスト

したがって、どのプラットフォームも絶対的に支配的であるとは言えないと思います。それぞれに潜在的なユーザーとタスクの独自のサークルがあり、その使用は最も合理的で費用効果が高いです。これは、Ethereum、Quorum、Hyperledger Fabric、およびCordaに適用されます。ここでは、プログラミング言語と同様に、それぞれ1つの言語を知っているVasyaとPetyaだけが、「プラス」または「ヒキガエル」のどちらが優れているかについて愚かな点について議論します。-そして、それらのダースを知っセミヨンペトロヴィッチとアルバートイワは、平和的に話をするとき、「プラス」は優れている、とするとき- 「ヒキガエル」。



2.一部のDLTプラットフォーム（Hyperledger FabricやCordaなど）が大きなデータ項目を転送する機能を提供しているにもかかわらず、実際には、ファイル、おそらくスマートコントラクトメカニズムを備えたブロックチェーンベースとファイル転送機能は分離されたままになります。これは、次の点によるものです。

• , DLT-. . Hyperledger Fabric Corda 2M « », , IPFS 100M. - - pdf (, ), 50M — , .
• - , ( + ), , .
• , , S3. , , « », , DFS. .
• , , -, «» .

3.現在、分散型プラットフォームの技術サポートサービスのスペシャリストが慢性的に不足しています。より正確には、それらは単に存在しません。絶対に。私が知っているほとんどのプロジェクトでは、技術サポート作業の大部分は、これらのプラットフォームを作成した開発者または研究エンジニアによって行われていますが、これはもちろん良くありません。これは、方向性の若さによるものだと思います。サポートサービスの効率的な作業を整理するために必要な技術的な指示、応答テンプレート、監視スキーム、およびその他の方法論的資料の開発が徐々に進んでいます。ここでの問題の1つは、特定のブロックチェーンプラットフォームでロシア語の優れた概要コースがないことです。すべてが手から手へと渡されなければなりません。しかし、エンタープライズサポートスペシャリストは開発者ではなく、他の問題に焦点を当てています。エラーの診断、事故後のシステムの信頼性と回復の保証（事故はないと思いますか？はい、もちろんです）。そして、率直に言って、不十分なサポートのために企業プロジェクトが死ぬ可能性は、不十分な開発品質のためよりも大幅に高くなります。したがって、エンタープライズシステムのサポートと運用の経験を持つ質の高いスペシャリストを引き付けることは、プロジェクトが長期間存続し、発展し、数人の創設者の父親がプロジェクトを離れても衰えることはないという事実において、最も重要な要素ではないにしても重要です。したがって、エンタープライズシステムのサポートと運用の経験を持つ質の高いスペシャリストを引き付けることは、プロジェクトが長期間存続し、発展し、数人の創設者の父親がプロジェクトを離れても衰えることはないという事実において、最も重要な要素ではないにしても重要です。したがって、エンタープライズシステムのサポートと運用の経験を持つ質の高いスペシャリストを引き付けることは、プロジェクトが長期間存続し、発展し、数人の創設者の父親がプロジェクトを離れても衰えることはないという事実において、最も重要な要素ではないにしても重要です。



4.最も曖昧な法的領域の1つは、オペレーターとネットワーク参加者の間の関係の形式化です。これは、一方ではオペレーターがネットワークとそのリソースの所有者ではなく、他方ではその機能を保証する義務があるという事実によって悪化します。この措置は、個々の参加者の利益と矛盾しています。運営者の権利と義務のバランス、ネットワーク参加者への「影響力の手段」、運営者の経済的責任-これらすべてが今や非常に困難な論争の対象となっています。最も簡単な質問：単純に見えるにもかかわらず、すべてのネットワーク参加者による重要なソフトウェアの同期交換を確実にする方法は、非常に白熱した議論になりますか？すでに製品化されているプラ​​ットフォームの経験に基づいた、オペレーターとネットワーク参加者の立場の法的な形式化の例の出現は、企業および企業間の関係の重要な要素としての分散型ネットワークの導入を大幅に加速します。



最後に到達した場合は、ボーナスもあります。分散型企業プラットフォームの現在の状態と開発パスに関する質問の一部は、この記事の作成者がブロックチェーンリソースの1つとして作成した資料に反映されています（この資料は幅広い読者向けに設計されています）。