アライアンスチェーンはどこに向かっているのでしょうか?
編集者注: この記事は以下から引用しました炭素鎖値(ID:cc-value), 著者：カーボンチェーンバリュー研究所、Odailyによる許可を得て転載。
まとめ
副題
まとめ
第46回世界経済フォーラム・ダボス年次会議では、「第4次産業革命」におけるブロックチェーン、人工知能、自動運転などが取り上げられた。 「エコノミスト」は、2015 年 10 月の表紙記事「Trust Machine」でブロックチェーンを紹介しました。「ビットコインの背後にあるテクノロジーには、経済の仕組みを変える可能性がある」。
ブロックチェーンが信頼できるマシンと呼ばれる理由は、分散性と非改ざん性という 2 つの主要な特性に由来しており、これは従来のデータベースとは異なるブロックチェーンの主要な特性でもあります。ここでの「分散」には 2 つの意味が含まれています: 1 つは従来の分散ストレージ、もう 1 つはブロックチェーンの基盤となるプロトコルによってもたらされるコラボレーションですが、ここでは分散コラボレーション機能のことを指します。
ブロックチェーンでは、その「信頼できるコラボレーション」は主にコンセンサスアルゴリズム、スマートコントラクト、ガバナンス、クロスチェーン、プライバシーなどを通じて実現されるため、この記事ではこれらの側面から基盤となるテクノロジーの違いを分析し、エンタープライズアプリケーションのシナリオを組み合わせます。ビジネス ユーザーがより適切な選択をできるように支援します。同時に、保守性、パフォーマンス、開発ツール、拡張性、ソフトウェア プロトコルの観点から従来のエンタープライズ ソフトウェアを分析および比較します。
コンソーシアムチェーンの歴史とパブリックチェーンとの違いに関しては、初期段階では大きな違いはありませんが、市場セグメントが深化し続ける現在では、パブリックチェーンとコンソーシアムの違いが顕著になってきています。連鎖はますます明らかになっていきます。
まず第一に、パブリック チェーンは制御不能なシナリオに直面しており、セキュリティ、パフォーマンス、分散化の間のバランスを見つける必要があります。コンソーシアム チェーンのエンタープライズ サービス シナリオでは、参加者の数は比較的制御しやすく、コンソーシアム チェーンはパフォーマンスとセキュリティの面で画期的な進歩を遂げる可能性が高くなります。しかし、まさに参加者 (ノード) の制御可能性により、分散化には独自のよりユニークな設計が施されています。さらに、パブリックチェーンでは、すべての情報がオープンかつ透明で確認でき、各参加者は比較的平等です。しかし、産業界では、これは容認できません。対処する必要があるパブリック間のデータ プライバシーが大量に存在し、企業内には権限を設定する必要がある複数の組織モデルもあります。
これらの特性に基づいて、アライアンスチェーンの開発には、ノード管理、コンセンサス選択、権限制御、契約設計パラダイムが含まれますが、同時に、フレームワークが異なれば契約設計パラダイムの理解も異なります。また、ブロックチェーンはオープンソースとクローズドソースに分けられますが、ブロックチェーンが生み出す信頼はオープンソースのコードに基づいており、オープンソースでなければ本当の意味でのブロックチェーンシステムとは言えません。したがって、研究の客観性を高めるために、この記事では主にオープンソース フレームワークに焦点を当てます。現在、国内市場で広く使用されているオープンソース アーキテクチャは、Fabric、FISCO BCOS、および CITA です。
Hyperledger Fabric は、高度な機密性、柔軟性、拡張性を提供するモジュラー アーキテクチャに基づいた分散台帳ソリューション用のプラットフォームです。さまざまなコンポーネントのプラグイン可能な実装をサポートし、経済エコシステム全体に存在する複雑さに適応するように設計されています。 Fabric はもともと IBM によって設計および開発され、そのソース コードは 2015 年に Linux Foundation の Hyperledger プロジェクトに捧げられました。
FISCO BCOSは、ゴールデンチェーンアライアンスが立ち上げた2017年に誕生した国内のスタンダードなボトムレイヤーです。 Golden Chain Alliance は、深セン金融技術協会、深セン前海 WeBank、深セン証券エクスプレスを含む 20 以上の金融機関とテクノロジー企業が共同で発足し、2016 年 5 月 31 日に設立された非営利団体です。
CITA は、高い安定性、高いパフォーマンス、高いスケーラビリティを備えて設計されたオープンソースのブロックチェーン オペレーティング システム カーネルです。 CITA オープンソース プロジェクトは、2016 年に Cryptape によって開始されました。現在、Xita Technology などの CITAHub コミュニティ企業によって共同で維持されています。 CITA はマイクロサービス アーキテクチャ設計を採用し、豊富な開発ツールと柔軟なブロックチェーン ガバナンス ツールを提供し、開発者はさまざまな種類のブロックチェーン ネットワークの二次開発や構成を実行できます。
ブロックチェーンのさまざまな実装と設計アイデアを区別するには、まずブロックチェーン自体の定義を明確にすることができます。通常、ブロックチェーン自体の定義は分散型台帳であり、イベントやトランザクションを記録する不変台帳でもあります。この台帳では、不変のプロパティがコンセンサス アルゴリズムによって保証されています。この観点から、既存のコンソーシアム チェーンは、ファブリックに代表される従来のデータベースが主流の分散データベース技術と、より「ブロックチェーンの精神」に沿った FISCO BCOS および CITA の 2 つのカテゴリに分類できます。
ファブリックの特徴: IBM Fabric は、ブロックチェーンにおける分散型および改ざん不可能な変更の 2 つのポイントを保証し、分散型コンセンサス メカニズムを省略します。IBM Fabric は、フレームワーク内に実際の分散型コンセンサス メカニズムを備えていません。ファブリック アーキテクチャでは、参加者 (ノード) は、順序付けノード、承認ノード、送信ノードの 3 つの役割に分割されます。各トランザクションについて: コンセンサス状態プロセスは、クライアント、承認ノード、および送信ノードによって完了します。順序付けノードは、トランザクション注文のコンセンサスに対してのみ責任を負い、状態コンセンサス戦略には責任を負いません。並べ替えノードのコンセンサス方式は Kafka または Raft ですが、実際には既存の分散データベースのコンセンサス方式と一致しており、フォールトトレラントではありません。
CITA および FISCO BCOS の特徴: FISCO BCOS および CITA では、上記のブロックチェーンのすべての特性が保証されていますが、使用される際の設計パラダイムは従来のプロジェクトとは大きく異なります。分散型台帳として、データの改ざんが不可能であることを保証し、1/3 のフォールト トレランス率を保証する分散型コンセンサス メカニズムであるビザンチン フォールト トレランスを使用することもできます。これら 2 つのフレームワークでは、チェーンの参加者はコンセンサス ノードと読み取り専用ノードに分けられ、コンセンサス ノードは簿記権限を持つ参加者、読み取り専用ノードはすべてのデータにアクセスできる参加者です。
イーサリアムがブロックチェーンの精神を表すとすれば、CITA と FISCO BCOS はパブリック チェーンを継承します。 CITA と FISCO BCOS はシナリオや使用法の点でパブリック チェーンとは完全に異なりますが、基礎となるロジックの一部にはパブリック チェーンの継承が見られます。厳密に言えば、イーサリアムの仮想マシンを継承するということは、イーサリアムの巨大な生態系を継承することを意味します。次に、この記事では、技術実装の観点から 3 つの違いを比較します。
副題
コンセンサスとトランザクションの流れ
コンセンサス メカニズムはブロックチェーンの魂であり、パブリック チェーンであってもアライアンス チェーンであっても、コンセンサス メカニズムはブロックチェーンのトランザクション処理能力とスケーラビリティを根本的に制限し、分散コラボレーション機能の基礎でもあります。コンセンサスとは、分散システム内のノードがデータまたはネットワークの最終状態について合意に達することです。ネットワーク環境やノードの状態が制御できないため、コンセンサスメカニズムではパフォーマンス、信頼性、セキュリティなどの問題を同時に考慮する必要があります。広い観点から見ると、コンセンサス メカニズムは、ナカモト コンセンサスなどのアクセスを必要としないコンセンサス メカニズムと、PBFT などのアクセスを必要とするコンセンサス メカニズムの 2 つのカテゴリに分類できます。
ナカモトコンセンサスはパブリックチェーンで広く使用されていますが、その確率モデルは高い信頼性を提供する一方で効率を犠牲にしています。特定の商用アプリケーション環境では、ライセンスメカニズムによってノードの信頼性がある程度保証されているため、ユーザーは実行効率とファイナリティをより重視します。これが、BFT コンセンサスがアライアンス チェーンで人気がある理由です。
次に、この記事では、まず FISCO BCOS、CITA、および Fabirc コンセンサス テクノロジーの実装を紹介し、次にパフォーマンス、アプリケーション シナリオ、スケーラビリティ、セキュリティの観点から比較分析を行います。
技術的な実現
BCOS コンセンサスメカニズムの効率性は比較的伝統的です
FISCO BCOS のコンセンサスメカニズムは従来の PBFT コンセンサスを採用しており、そのコンセンサスプロセスは主に Pre-prepare、Prepare、Commit の 3 つの段階で構成されます。
1. 事前準備: リーダー ノードはブロックを実行し、署名を生成し、提案を他のコンセンサス ノードにブロードキャストします。
2. 準備: コンセンサス ノードは提案を検証し、署名をブロードキャストし、同時に他のノードの署名を収集します。ノードは 2f + 1 の署名を収集した後、コミット パッケージのブロードキャストを開始します。
3. コミット: リーダー ノードはコミット パケットを収集し、2*f + 1 個のコミット パケットを収集した後、ローカル データベースを更新して他のノードにブロードキャストし、他のノードは受信後にローカル データベースを更新します。
次の図は、標準的な PBFT プロセスを示しています。
ブロックチェーンでは、コンセンサス ノードはコミット フェーズで投票を統合する必要があるため、最終的なコミット フェーズは少し異なります。リーダー ノードは 2*f+1 コミット パッケージを受信した後、最終的なコミット パッケージを他のコンセンサス ノードにブロードキャストします。統一投票。
コンセンサスプロセス全体において、トランザクションは Pre-prepare フェーズで 1 回実行され、Prepare フェーズで 1 回検証されます。FISCO BCOS で使用される従来の PBFT プロセスは、最初に実行してから検証するモードであり、実行に 2 つの時間が含まれます。取引。
CITAは自社開発のコンセンサスプロトコルを採用
CITAは、ブロックチェーンの継続的合意の特性に従って最適化されたCITA-BFTを実装します。ブロックチェーンは継続的なコンセンサス プロセスですが、CITA ではトランザクションの実行とコンセンサスを分割して、二重実行の問題を回避します。ステート マシンのレプリケーションの原則に従って、初期状態が一貫していること、トランザクションの実行順序が一貫していること、実行プロセスが決定的であること、この 3 つの条件がすべて満たされると、最終結果の一貫性が保証されます。ブロックチェーンでは、ジェネシスブロックによって初期状態の一貫性が保証されており、仮想マシンは完全に決定的であるため、トランザクションの順序が一貫している限り、最終結果の一貫性が保証されます。ブロックチェーンでは、ブロックのプレハッシュには、前のブロックのトランザクション処理後の世界状態情報がすでに含まれています。 CITA-BFT は、現在のブロックのトランザクション順序と前のブロックの実行結果について合意します。このように、コンセンサスプロセス中にトランザクションを実行する必要はなく、コンセンサス完了後のトランザクション処理は 1 つだけで済むため、チェーン全体のスループットが大幅に向上します。 CITA-BFTは、ブロックチェーンの継続的コンセンサスの特性に合わせて最適化されており、まずコンセンサスを取得してから処理する方式を採用しているため、コンセンサスプロセスではトランザクションを実行する必要がなく、コンセンサスが成立した後にトランザクションを実行するだけで済みます。完成しました。検証後、最も単純な証券デポジットトランザクションでは、コンセンサスパフォーマンスが約 35% 向上しました。
CITA-BFT は、コンセンサス プロトコルにおけるリーダー ブロードキャストの最終ラウンドのプロセスを回避します。従来の PBFT の最終コミット ステージでは、リーダーは十分なコミット パケットを受信し、それらを他のノードにブロードキャストする必要があります。ブロックチェーンは継続的なコンセンサスプロセスです。CITA-BFTでは、ブロック内のコンセンサス投票は前のブロックの投票であるため、リーダーがコミットフェーズと次の高さの提案フェーズで最後のブロックをブロードキャストするプロセスは次のとおりです。一連のブロードキャスト プロセスの後、コミット投票情報は次の高度な提案プロセスを通じて統合されます。
CITA-BFT は提案前処理テクノロジーを使用して、コンセンサスと実行を並行して進め、システムのパフォーマンスを向上させます。ほとんどの場合、コンソーシアムチェーンのネットワーク状態は良好であり、コンセンサスは一連のコンセンサスプロセスで完了することができるため、CITAは提案前処理のテクノロジーを導入しています。つまり、事前準備段階で、ノードは提案後のトランザクションを直接処理できます。コンセンサスプロセスが完了するまで待機せずにプロポーザルを受信し、コンセンサスプロセスの完了後にトランザクションプロセッサにコンセンサス結果を通知します。従来のPBFTプロセスではトランザクション処理とコンセンサスがシリアルでしたが、プロポーザル前処理の導入後はコンセンサスの準備フェーズとコミットフェーズをトランザクション処理と並行して実行できるようになり、システム全体のスループットが大幅に向上します。テスト後、単純なトランザクション処理の場合、約 10% ～ 20% のパフォーマンス向上が見られました。
CompactBlock テクノロジーは、コンセンサス ブロックのサイズを圧縮し、ネットワーク帯域幅の使用率を向上させるために CITA で使用されています。ブロック内のトランザクションは一度だけブロードキャストされているため、コンセンサス ブロックに含める必要があるのはトランザクション ID だけであり、これによりブロック メッセージのサイズを大幅に削減できます。ネットワーク状態が良好な場合、単純なトランザクション処理のパフォーマンスが 5% ～ 10% 向上することがテストされています。
ファブリックのコンセンサスメカニズムがビジネス効率の向上を制限する
Fabric はノードの役割をソート ノード、エンドースメント ノード、サブミット ノードに分割します。クライアントは最初にトランザクション リクエストをエンドースメント ノードに送信します。エンドースメント ノードが実行された後、読み取り/書き込みセットとその署名をクライアントに返します。クライアントは十分な同一の結果を収集した後、複数のセットである読み取り/書き込みセットを構成します。署名とトランザクション要求 署名されたトランザクションは並べ替えノードに送信されます。並べ替えノードがブロックを形成した後、送信ノードにブロードキャストされます。送信ノードは、読み取り/書き込みセットと署名の数が満たされているかどうかを確認し、マークを付けます。結果を取得し、法的結果をそれぞれの台帳に保存します。
Fabric ではトランザクションの実行は非決定的であり、FISCO BCOS や CITA の設計概念とは異なります。したがって、承認ノードは最初にトランザクションを実行する必要があり、クライアントは承認ポリシーに従って結果を比較し、それから並べ替えノードに送信し、最後に送信ノードがそれぞれのデータベースを検証して更新します。これは、次のように理解できます: コンセンサスステータスのプロセスは、クライアント、承認ノード、および送信ノードの共同参加によって完了します; 順序付けノードは、トランザクション順序のコンセンサスに対してのみ責任を負い、状態のコンセンサスには責任を負いません。トランザクションステータスのコンセンサスと順序付けには、さまざまな戦略を採用できます。たとえば、トランザクション状態は同じ状態の 3/4 以上を採用でき、順序付けノードのコンセンサスは従来の Raft または Solo コンセンサスを使用し、従来の CFT コンセンサスはほとんどのシナリオを満たすことができます。ここでの問題は、トランザクションにユーザーの署名、複数の承認ノードの署名、および読み取り/書き込みセットを含める必要があるため、トランザクションが非常に大きくなるということです。
A と B の間で頻繁に送金が行われるなど、ファブリックのトランザクション ステータスに矛盾がある場合、トランザクションごとに AB のアカウントの残高が変更されるため、トランザクションの競合が発生します。競合するトランザクション ブロックごとに最大 1 つのトランザクションのみを処理できるため、ビジネス契約のシナリオが大幅に制限されます。
FISCO BCOS：
性能比較
CITAコンセンサスパフォーマンスは良好
CITA：
従来のPBFT
コンセンサスプロセス中、トランザクションは繰り返し実行され、コンセンサス効率は平均的です。
最初にコンセンサスをとり、次に実行します。実行されるトランザクションは 1 つだけなので、全体的な効率が高くなります。
コミットフェーズでのリーダーブロードキャストプロセスを最適化し、コンセンサス時間を短縮します。
Fabric：
提案事前実行テクノロジーにより、コンセンサスと実行が並行して行われ、全体的なパフォーマンスが向上します。
CompactBlock テクノロジーにより帯域幅の使用率が向上
トランザクションには複数のエンドースメント ノード署名と読み取り/書き込みセットが必要となり、非常に大規模なトランザクションが発生します。
アプリケーションシナリオ
比較すると、FISCO BCOS は従来の PBFT を採用しており、コンセンサス効率は平均的ですが、CITA は自社開発の CITA-BFT を採用しており、コンセンサスとトランザクション処理のパフォーマンスが 50% 以上向上しています。プロセス全体が実行、ソート、検証に分割され、柔軟性が向上しますが、検証と実行を分離すると、トランザクションが非常に大きくなります。
アプリケーションシナリオ
ファブリック: コンセンサスプロセスを実行、ソート、検証に分割することで柔軟性が向上しますが、結果として生じるトランザクション構造は非常に大きくなり、競合するトランザクションの各ブロックはチェーン上に 1 つのトランザクションしかアップロードできないため、ビジネス契約シーンが大幅に制限されます。たとえば、統計的投票コントラクトの場合、N 人の投票者が存在し、各投票者はトランザクションを送信することで投票します。これは、合計の投票結果が共有状態であるためです。この場合、各ブロックは 1 つのトランザクションのみを処理できます。たとえば、Randao プロジェクトの場合、参加者が送信したすべての情報を収集する必要があります。このとき、情報を保存するためのセット変数が必要です。各参加者のトランザクションはこのセット変数を変更するため、各ブロックは処理のみを行うことができます。 1 つの送信されたトランザクションとコレクション変数により、読み取り/書き込みセットが非常に大きくなります。
スケーラビリティ
安全性
スケーラビリティ
Fabricの場合、実行、ソート、サブミットノードの機能が分離されており、実行（検証）とソートは異なるコンセンサス戦略を採用できるため、セキュリティ戦略はユーザーが自由に把握でき、クライアントはステータスのコンセンサスに参加できます。そして実行。
スマートコントラクト
副題
スマートコントラクト
「スマートコントラクト」という用語はやや誤解を招きますが、インテリジェンスはしばしば人々にある程度の謎をもたらしますが、その契約機能自体には「インテリジェンス」は存在しません。ブロックチェーンが登場する前は、すべてのシステムが集中型アーキテクチャを採用していたため、規制当局やユーザーはシステム機能の正確性を検証および保証できず、データが悪意を持って変更されていないことを保証できず、データのセキュリティも保証できませんでした。 。ブロックチェーンの登場により、第三者に依存することなく取引を確実に行うことができ、取引の追跡が可能で取り消しができないようになりました。スマート コントラクトの中心的な意味は、ブロックチェーンに基づいたトラステッド コンピューティングと、ブロックチェーン プロトコルによって保証されるトレーサビリティと不可逆性を実現することです。
ビットコインでの取引は主にピアツーピアの現金支払いに使用され、イーサリアムはチューリング完全スマートコントラクトの導入によりブロックチェーン2.0と呼ばれています。理論的にはイーサリアム上のスマートコントラクトはチューリング完成ですが、取引手数料、契約手順、ブロックガスの上限、ノードの信頼性などの制限により、パブリックチェーンスマートコントラクトは既存の企業開発には適していません。
コンソーシアム チェーンはノード数が限られているため、エンタープライズ開発により適しており、ノード オペレーターは高性能のハードウェア デバイスと基盤となるプロトコル サポートを使用できます。この記事では、まず 3 つのスマート コントラクトの技術実装を紹介し、次にセキュリティ、使いやすさ、ユーザビリティの 3 つの側面から比較分析を行います。
技術的な実現
BCOS と CITA はどちらも EVM とプリコンパイルされたコントラクトをサポートしています。 Ethereum スマート コントラクトの完全なエコシステムの助けを借りて、どちらもそれに基づいてカスタマイズされており、豊富なコントラクト作成およびテスト ツールがあります。
Fabric のコントラクトは、ChainCode を通じて Docker の形でオフラインでインストールされ、トランザクションを通じてアクティブ化されます。 ChainCode コントラクトのデプロイは比較的重いですが、複数の言語をサポートしています (Go、JavaScript など) コントラクトのデプロイと更新はオフラインで更新されます コントラクト コードについてはコンセンサスがありません その入力と出力は正しく、内部ロジックの特定の実装は気にしません。
安全性
Fabric は契約書の作成に従来の言語を使用するため、開発者は新しい言語を学ぶ必要はありませんが、仮想マシンの不確実性により、ChainCode メソッドは、最初に実行し、コンセンサスと検証を行う Fabric のコンセンサス手法にのみ適しており、多用途性。
安全性
スマートコントラクトを他のプログラムと区別する主な機能はセキュリティであり、ここでいうセキュリティには確実性、検証可能性、監査可能性、追跡可能性などの機能が含まれます。
比較から、BCOS/CITA トランザクションはチェーン上で実行されるため、BCOS/CITA のスマート コントラクトはより決定的、検証可能、監査可能、不可逆的、および追跡可能であることがわかります。
使いやすさ
Fabric のコントラクトコードはエンドースメントノードごとにデプロイ、アップグレードされるため、検証可能性、監査可能性、トレーサビリティは保証できません。ただし、Fabric の設計思想では、契約実行後にクライアントがコントラクトを検証することになっており、本稿では、コントラクトの最終的な結果はクライアントとエンドースメントノードによって決定されると考えることができ、トランザクション結果がエンドースメントポリシーに準拠している限り、ユーザーの期待を満たしている場合、コード検証要件は比較的重要ではありません。
使いやすさ
BCOS/CITA は、契約の使いやすさにおいて Fabric よりわずかに優れています
可用性
BCOS/CITA/ファブリックは企業の複雑なビジネス ロジックに対応し、より複雑な契約の計算と処理をサポートできます。一方、CITA はチェーン上のタイミング タスクをサポートします。
副題
パフォーマンス
近年のブロックチェーンの基盤技術の開発により、アライアンスチェーンのパフォーマンスが主なボトルネックではなくなりました。
BCOS の公式文書にはパフォーマンス データが記載されていません。この記事は第三者から提供されたデータに基づいてのみ判断できます。比較的信頼できる情報源が 2 つ見つかりました。中国情報通信技術学院の信頼できるブロックチェーンの最新評価 (2019 年 11 月～19 日) では、BCOS シングルチェーン TPS が 20,000 を超えています。 [2019年7月末のプレスリリース](未定義) テストチームがブロックチェーンのパフォーマンスが10,000TPSに達したと発表したとき、張凱祥氏はWeChatグループの人生で最大の赤い封筒をチームに送りました。 2 つのテスト データには、テスト環境、ノード数、使用されたコンセンサス プロトコル (BCOS は Raft をサポート) などが示されていないため、テストには異なるコンセンサス方法とノード数が使用されたと推測されます。https://arxiv.org/pdf/1801.10228.pdf公式ドキュメントの CITA の最新バージョンのトランザクション パフォーマンスは 15,000+ TPS に達する可能性があります。データは CITA バージョン 0.16 (2018 年 5 月 15 日) からのものです。4 つのノードが 4 つの 32 コア、64G クラウド サーバーにデプロイされています。各サーバーの構成100Mの帯域幅。
](https://arxiv.org/pdf/1801.10228.pdf))、32コアCPU、10ノードの場合、パフォーマンスは約3400に達します。このレポートによると、エンドースメント ノードは実際にはコンセンサスに参加しないため、エンドースメント ノードの数はパフォーマンスにほとんど影響しません。
現段階では、同盟のパフォーマンスは大幅に進歩しており、着陸シナリオと比較すると、パフォーマンスが主なボトルネックではなくなりました。同時に、国内のアライアンスチェーンは、パフォーマンスの面で海外の大手ブランドに負けておらず、さらには海外を上回っています。
副題
ストレージ
コンテンツの観点から見ると、ブロックチェーン ストレージには主に、ブロックおよびトランザクション ストレージとワールド ステート ストレージの 2 つの側面が含まれます。この記事では、まずそれぞれの実装方法を紹介し、次にサポートされるデータベースの種類、ストレージ効率、スケーラビリティ、データ保守の観点から比較分析を行います。
実現方法
BCOS の状態ストレージは 2 つのストレージ モードをサポートします
ブロックの保存については、BCOS トランザクション リスト、トランザクション レシートなどはすべて従来の MPT 方式で保存されます。ワールド ステートについては、BCOS はストレージ ステートと MPT ステートの 2 つのストレージ モードを採用します。 MPT 状態は RocksDB と外部ストレージをサポートしており、MPT ストレージは履歴状態を保存しながらストレージ データを最小限に抑えます。ストレージ状態は RocksDB、MySQL、および外部をサポートします。ストレージ状態ストレージを使用すると、トレーサビリティの一部が犠牲になりますが、パフォーマンスが向上し、SQL ステートメントのクエリと統計をサポートできます。世界の状態はトランザクションを通じて常に復元できるため、パフォーマンスの向上と状態のクエリと引き換えに追跡可能性をある程度犠牲にすることは許容されます。
CITA は RocksDB と外部ストレージをサポートしています。 MPT を使用して状態を保存し、Simple Merkle Tree を使用してトランザクションとトランザクション レシートを保存します。状態ストレージとして、CITA は、履歴状態を保存し、同時にストレージ データを最小限に抑える、クラシック MPT ストレージを選択しました。トランザクションとトランザクションのレシートについては、Simple Merkle Tree ストレージを使用すると、保存されるデータの量を最適化し、ハッシュ計算を削減できます。
Fabric のブロックストレージも MPT 方式で保存されます。ワールド状態のストレージは、KV および CouchDB ストレージをサポートします。ワールド状態を保存する場合、ファブリックは履歴状態の保存をサポートしません。同時に、パフォーマンスが向上し、豊富な条件付きクエリと統計をサポートします。
比較解析
比較のために：
この論文では、トランザクション ストレージの観点から、ノードは履歴記録を保持する必要があり、世界状態の履歴ストレージについては、トランザクションを通じて復元できると考えており、この場合、BCOS/ファブリックは、より優れたクエリ機能とより高いパフォーマンスをユーザーに提供します。素晴らしいトレードオフだ。
ガバナンス
副題
ガバナンス
アライアンスチェーンとパブリックチェーンの最大の違いは、ガバナンス手法の違いにあり、パブリックチェーンはオープンシステムであるため、異なる役割間の関係を調整するために一定の経済的インセンティブが必要であり、アライアンスチェーンは、ノードはアクセスメカニズムであるため、そのガバナンス方法はパブリックチェーンとは大きく異なります。アライアンス チェーンのガバナンスには主にノード管理、アカウント権限、経済モデルが含まれます。
ノード管理
BCOS と CITA の場合、ノードは主にコンセンサス ノードと通常ノードの 2 つのカテゴリに分類されます。コンセンサスノードはコンセンサスブロックの生成を担当し、通常のノードはデータの同期とデータの検証のみが可能で、トランザクションをパッケージ化する機能はありません。
Fabric の場合、ノードは承認ノード、順序付けノード、および送信ノードに分割されます。承認ノードはトランザクションを実行して結果を返す責任を負い、並べ替えノードはトランザクションを並べ替えてブロックにパッケージ化する責任を負い、送信ノードはトランザクションを検証してステータスを更新する責任を負います。
コンセンサスノードBCOS/CITAの場合、システム契約により管理されており、ノードの追加・削除にはコンセンサスノードの合意が必要となります。ノード管理者はファブリック ノードの追加と削除をコンセンサスなしで変更できますが、新しい構成ファイルをアクティブ化するにはトランザクションとコンセンサスを送信する必要があります。
この記事では、ホワイトリスト/ブラックリストまたは CA を介してノード ID を管理することで、アライアンス チェーンのほとんどのシナリオを満たすことができ、CA はノード ID の検証においてより厳格であると考えています。
ユーザー権限の管理
コンソーシアム チェーンの場合、コンソーシアム内およびコンソーシアム内の各ロールには、より複雑な権限管理が必要となるため、さまざまなロールは、そのロールによって承認されたリソースのみにアクセスできます。
CITA/BCOS では、ユーザーのトランザクション権限は、トランザクションの送信、コントラクトの作成、コントラクト メソッドの呼び出し権限などを含む複雑な権限管理を通じて管理されます。
ファブリックは、構成ファイル (ポリシー) を通じてユーザーの権限を管理します。
BCOS/CITA の権利管理はトランザクションを通じて管理され、構成ファイルを通じて変更されたファブリックよりもブロックチェーン ベースであり、ガバナンス操作はトレースを保持します。
経済モデル
CITA は 2 つの異なる経済モデルをサポートしています
BCOS、CITA、および Fabric はすべて、ユーザーに無料サービスを提供するモデルをサポートしていますが、同時に BCOS/CITA は、システムの悪用を防止するために、システム契約を通じて単一のユーザー ブロック内のシステム リソースの使用を制御します。
また、CITA は課金モードをサポートでき、ノードはユーザーのトランザクションを正確に請求し、トークン処理料金を請求します。トークンはノードによってユーザーに無料で割り当てることも、ユーザーが有料で使用することもできるため、ユーザーはシステム リソースの使用をより細かく制御できます。
副題
クロスチェーンとプライバシー
クロスチェーンとプライバシーのソリューションには、実稼働環境からの最適化の余地がまだあります
BCOS ではグループ方式が導入されているため、ノードは異なるグループに属することができ、グループのメッセージ、トランザクション、ストレージ、実行などが完全に分離されます。
Fabric のグループ概念は BCOS と似ており、ノードは異なるグループに属することができ、異なるグループは異なる承認ポリシーを使用できます。
BCOS とファブリックでは、グループのデータと通信が分離されており、異なるコンセンサス戦略を使用できるため、マルチチェーンとみなすことができます。現在、マルチチェーンの最大の問題はチェーン間通信であり、この点に関してはどちらも十分に成熟した解決策を持っていません。
CITA ではサイドチェーン技術が導入されており、サイドチェーンとメインチェーンは相互に通信できますが、サイドチェーン技術には本番環境からの最適化の余地がまだ残されています。
CITA は、ゼロ知識証明と SGX の実装をオープンソース化しました。
準同型暗号、ゼロ知識証明、SGX などはすべて開発段階にあり、本番環境から最適化する余地がまだあります。
副題
CITA は暗号化サポートにおいてより包括的です
比較すると、BCOS/CITA はどちらも国家機密をサポートしており、国内の規制要件により適合していることがわかります。CITA は、暗号アルゴリズムのサポートという点でより包括的です。共通の Keccak/Secp256k1 のサポートに加えて、Keccak/Secp256k1 もサポートしています。これはより安全で優れています。
副題
システム構造
BCOS とファブリックはどちらも単一のシステム アーキテクチャを採用しており、ノードが単一の物理マシン上に存在する必要があります。
CITA はマイクロサービス アーキテクチャを採用しており、CITA はマイクロサービス アーキテクチャを使用した世界初のオープンソース ブロックチェーンでもあります。マイクロサービス アーキテクチャを使用すると、ノードを単一の物理マシンに制限できるだけでなく、企業ユーザーがより優れたハードウェア デバイスを使用してノードをサポートし、より優れたスケーラビリティを実現できるようになります。マイクロサービスはメッセージ サブスクリプションを通じて通信するため、企業ユーザーはカスタマイズされたサービスを簡単に置き換えたり追加したりして、機能拡張を促進できます。
副題
オープンソース契約
BCOS のオープンソース プロトコルは商用アプリケーションには十分フレンドリーではありません
ここでは、関連するオープンソース契約を簡単に紹介します。
Apache License は商用アプリケーションに優しいライセンスでもあります。ユーザーは、ニーズに合わせて必要に応じてコードを変更し、オープンソースまたは商用製品としてリリース/販売することもできます。
このことから、BCOS のオープンソース プロトコルは商用アプリケーションには十分に適していないことがわかります。
副題
言語実装
CITA は、より高いパフォーマンスとより信頼性の高いセキュリティを備えた、より現代的な言語 Rust を使用します。
Fabricc: Go 実装では、ガベージ コレクション メカニズムのパフォーマンスが C++ よりも劣ります。
要約する
CITA: Rust が実装されており、主流のブロックチェーン言語と比較して、Rust はメモリの安全性と C++ に匹敵するパフォーマンスを保証しています。
