アライアンスチェーンはどこに向かっているのでしょうか?

碳链价值

特邀专栏作者

2020-01-03 10:42 (UTC+8)

この記事は約10518文字で、全文を読むには約16分かかります

どのアライアンスチェーン技術が強いでしょうか？オープンソースアーキテクチャ Fabric、FISCO BCOS (以下、BCOS)、CITA のテクノロジー比較。

AI要約

展開

どのアライアンスチェーン技術が強いでしょうか？オープンソースアーキテクチャ Fabric、FISCO BCOS (以下、BCOS)、CITA のテクノロジー比較。

編集者注: この記事は以下から引用しました炭素鎖値(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 つの異なる経済モデルをサポートしています