leaf

企業向けブロックチェーン（アライアンスチェーンとも呼ばれる）は、大企業、政府機関、産業連合のブロックチェーン技術のニーズに特化しており、企業向けのブロックチェーンネットワークソリューションを提供します。アライアンスチェーンの各ノードは通常、特定の実体の機関組織に対応しており、ノードの参加や退出は承認を必要とします。各機関は利害関係のある連合を形成し、ブロックチェーンネットワークの健全な運営を共同で維持します。

プライベートチェーンやパブリックチェーンとは異なり、企業向けブロックチェーンはブロックチェーン技術の実際の適用により重点を置いており、ブロックチェーンの性能、速度、安全性、メンバー認証管理、データプライバシー保護に対してより高い要求があります。さらに、企業向けブロックチェーンの研究開発は、実際のビジネスシーンと直接関連していることが多く、業界の痛点により近く、企業連合に対してより完全な統合ブロックチェーンソリューションを提供します。

図は、アライアンスチェーンプラットフォームとブロックチェーンアプリケーションの相互促進関係を示しています。一方で、アライアンスチェーンプラットフォームは、実際の業界アプリケーションの研究開発と実装に対して基盤技術の支援を提供します。もう一方で、業界アプリケーションや概念の検証と実装もアライアンスチェーンプラットフォームの継続的な発展と成熟を促進しています。

Hyperchain は、企業が既存のクラウドプラットフォームに基づいてブロックチェーンネットワークを迅速に展開、拡張、構成管理できるようにサポートし、ブロックチェーンネットワークの運用状態をリアルタイムで可視化監視することができる、中国の ChinaLedger 技術規範に準拠した国産ブロックチェーンコアシステムプラットフォームです。Hyperchain は、検証ノードの承認メカニズム、多層暗号化メカニズム、コンセンサスメカニズム、チューリング完全な高性能スマートコントラクト実行エンジンなどのコア特性を持ち、機能が充実し、性能が効率的なアライアンスチェーン基盤技術プラットフォームです。企業や産業連合のニーズに向けたアプリケーションシーンにおいて、Hyperchain は資産のデジタル化、データの証明、サプライチェーンファイナンス、デジタル票、決済清算などの多中心アプリケーションに対して高品質な基盤ブロックチェーン支援技術プラットフォームと便利で信頼性の高い統合ソリューションを提供します。

hyperchain の全体システムアーキテクチャは図の通りです。

企業向けアライアンスチェーン基盤技術プラットフォームについて、主に以下の基本特性を考慮します：

• 参加者のメンバーシップ認証許可メカニズム

• 商業取引データの安全性とプライバシー

• 高い取引スループットと低い取引遅延

• 安全で完全なスマートコントラクトエンジン

• 高ユーザーエクスペリエンスの相互運用性

参加者のメンバーシップ認証許可メカニズムに関して、プラットフォームには以下の機能があります。

• アライアンス自治 ACO。プラットフォームは、アライアンスチェーンネットワーク内にアライアンスチェーン自治メンバー組織を作成することを許可し、提案の形式でアライアンス内の状態行動（システムのアップグレード、契約のアップグレード、メンバー管理など）を提出し、組織内部で投票を行います。この方法は、ブロックチェーンアライアンスのガバナンスに対する効果的なモデルを提供します。

• メンバー管理。プラットフォームは CA システム認証の方法を通じてアライアンスメンバーの入場制御を実現し、自己構築 CA と CFCA の 2 つのモードをサポートし、チェーンレベルの管理者、ノード管理者、一般ユーザーの階層的権限管理メカニズムを提供し、異なる権限のアクセス制御を実現します。

取引データの安全性とプライバシーに関して、プラットフォームには以下の機能があります。

• 多層暗号化メカニズム。プラグイン可能な暗号化メカニズムを採用し、ビジネスの完全なライフサイクルに関与するデータ、ユーザー、通信接続などに対して異なる戦略の暗号化を行い、多層暗号化を通じてプラットフォームデータの安全性を保証し、国密アルゴリズムを完全にサポートします。

• プライバシー保護。プラットフォームは Namespace 分割コンセンサスとプライバシー取引の 2 つのメカニズムを提供し、プライバシー保護を実現します。分割コンセンサスは、敏感な取引データの保存と実行空間を隔離し、一部のブロックチェーンノードが自分の分割を作成することを許可し、分割メンバー間のデータ取引や保存は他の分割のノードには見えないようにします。一方、プライバシー取引は、送信時にその取引の関連者を指定し、その取引の明細は関連者のみに保存され、プライバシー取引のハッシュは全ネットワークのコンセンサス後に保存され、プライバシーデータの有効な隔離を保証し、プライバシー取引の真実性を検証できます。

• 信頼できるデータソース。ブロックチェーンは閉じた決定論的環境であり、チェーン上では外部の現実世界のデータを積極的に取得することができません。プラットフォームは Oracle 予言機構を導入し、外部情報をブロックチェーンに書き込むことをサポートし、ブロックチェーンと現実世界のデータの相互通信を実現します。この予言機は、第三者の信頼できる機関の署名によって信頼の裏付けを実現し、証明可能な誠実性の要件を満たします。

スループットと取引遅延に関して、プラットフォームには以下の機能があります。

• 効率的なコンセンサスアルゴリズム。プラットフォームは RBFT（Robust Byzantine Fault-Tolerant、高健全性ビザンチン耐障害アルゴリズム）コンセンサスアルゴリズムを採用し、ノードデータの強い一貫性を保証しつつ、システム全体の取引スループット能力とシステムの安定性を向上させ、TPS（毎秒処理取引数）は万単位に達し、遅延は 300 ms 以内に制御可能です。また、プラットフォームは GPU ベースの検証署名加速を使用して全体の性能をさらに向上させ、ブロックチェーン商業アプリケーションのニーズを十分に満たし、動的ノード管理と障害回復メカニズムをサポートし、コンセンサスモジュールの耐障害性と可用性を強化します。今後は、異なるビジネスシーンのニーズに適応するために、他のコンセンサスアルゴリズム（RAFT など）を統合する予定です。

• データ分離。ブロックチェーンの台帳データは主にブロックデータと状態データの 2 つに分かれています。ブロックデータは継続的に増加し、状態データは頻繁に更新されることを考慮し、プラットフォームは Filelog ストレージエンジンを導入し、ブロックデータと状態データを分離して保存し、システムデータ量が増加しても読み書き性能に影響を与えないようにします。

安全で完全なスマートコントラクトエンジンに関して、プラットフォームには以下の機能があります。

• プラットフォームは EVM、JVM、HVM などのさまざまなスマートコントラクトエンジンをサポートします；

• Solidity、Java などのプログラミング言語をサポートします；

• 完全な契約ライフサイクル管理を提供します；

• プログラミングに優しく、契約の安全性が高く、実行が効率的な特性を持ち、変化する複雑なビジネスシーンに適応できます。

高ユーザーエクスペリエンスの相互運用性に関して、プラットフォームには以下の機能があります。

• データアーカイブ。ブロックチェーン内のブロックストレージデータの無限成長の問題を解決するために、データアーカイブの方法を通じて、古いオンラインデータの一部をアーカイブしてオフラインに転送します。また、アーカイブデータのブラウジング用に Archive Reader を提供します。

• データの可視化。ユーザーがブロックチェーン上の契約状態データをリアルタイムで確認できるように、プラットフォームはデータ可視化コンポーネント Radar を提供し、ブロックチェーンが正常に動作している間にブロックチェーン内の契約状態データをリレーショナルデータベース（MySQL など）にインポートし、契約状態を可視化、監視可能にし、商業アプリケーションのビジネス統計と分析を便利にします。

• メッセージ購読。プラットフォームは統一されたメッセージ購読インターフェースを提供し、外部システムがブロックチェーンプラットフォームの状態変化をキャッチし、リスニングできるようにし、オンチェーンとオフチェーンのメッセージの相互通信を実現します。ブロックイベント、契約イベント、取引イベント、システム異常監視などのイベントの購読をサポートします。

次に、Hyperchain を例にとって、企業向けブロックチェーンプラットフォームを構成するコア技術モジュールについて、主にコンセンサスアルゴリズム、スマートコントラクト、台帳、安全メカニズム、データ管理などの実装原理を深く分析します。

コンセンサスアルゴリズムは、ブロックチェーンプラットフォームの各ノードの台帳データの一貫性を保証するための鍵です。現在一般的な分散システムの一貫性アルゴリズムには、PoW、PoS、Paxos、Raft、PBFT などがあります。PoW は、マシンの計算能力に依存して台帳の記録権を取得し、リソース消費が高く、監視性が弱く、取引コンセンサスの達成には全ネットワークの共同計算が必要なため、アライアンスチェーンの監視および性能の要求には適していません。PoS の主な考え方は、ノードが記録権を取得する難易度がその保有する権益の数に反比例することであり、PoW よりも性能が良いですが、依然として監視性が弱い問題があります。Paxos と Raft は、従来の分散システムの一貫性の成熟した解決策であり、このタイプのアルゴリズムは性能が高く、リソース消費が低いですが、ビザンチンノードに対する耐障害性はありません。PBFT アルゴリズムは Paxos アルゴリズムの処理フローに似ており、許可投票、少数が多数に従うコンセンサスメカニズムです。このアルゴリズムはビザンチンエラーを許容する能力を持ち、強い監視ノードの参加を許可し、アルゴリズムの性能が高く、企業向けプラットフォームの開発に適しています。現在、主流の企業向けブロックチェーンソリューションである Fabric と Hyperchain は、PBFT の実装ソリューションを提供しています。しかし、ネイティブ PBFT アルゴリズムは信頼性と柔軟性の面で不十分であり、Hyperchain プラットフォームは信頼性と柔軟性を強化し、PBFT の改良アルゴリズムである RBFT を設計実装しました。

1. RBFT の概要

   Hyperchain のコンセンサスモジュールは、プラグイン可能なモジュール設計を採用しており、異なるビジネスシーンのニーズに応じて異なるコンセンサスアルゴリズムを選択して構成できます。現在、PBFT の改良アルゴリズム RBFT をサポートしています。Hyperchain は PBFT の実行プロセスを最適化し、能動的な回復と動的なノードの追加削除などのメカニズムを追加することで、従来の PBFT の信頼性と性能を大幅に向上させました。RBFT は取引の遅延を 300 ms に制御でき、毎秒数万件の取引量をサポートし、ブロックチェーンの商業アプリケーションに安定した高性能のアルゴリズム保証を提供します。以下に RBFT のコアアルゴリズムを詳細に説明します。

2. RBFT の通常プロセス

   RBFT の通常プロセスは、ブロックチェーンの各ノードがクライアントからの取引を同じ順序で処理することを保証します。RBFT は PBFT と同じ耐障害能力を持ち、少なくとも 3f+1 のノードが必要で、f個のビザンチンエラーを許容します。図 6.3 の例は、最小のクラスターのノード数であり、fの値は 1 です。図の Primary は、ブロックチェーンノードの中から動的に選出された主ノードで、クライアントメッセージの順序付けとパッケージ化を担当します。Replica ノードはバックアップノードであり、すべての Replica ノードは Primary ノードと同じ取引ロジックを実行し、Primary ノードが失敗した場合には新しい Primary ノードの選挙に参加できます。

   RBFT のコンセンサスは PBFT の元々の 3 段階処理フロー（PrePrepare、Prepare、Commit）を保持していますが、重要な取引検証の段階を挿入しています。

RBFT アルゴリズムの通常のコンセンサスプロセスは以下の通りです。

(1) クライアントが取引をブロックチェーンの任意のノードに送信します。

(2) Replica ノードは取引を受信した後、Primary ノードに転送し、Primary 自身も直接取引メッセージを受信できます。

(3) Primary は受信した取引をパッケージ化し、バッチを生成して検証し、不正な取引を除外します。

(4) Primary は検証を通過したバッチを構築し、PrePrepare メッセージを他のノードにブロードキャストします。ここでは、バッチ取引のハッシュ値のみをブロードキャストします。

(5) Replica は Primary からの PrePrepare メッセージを受信した後、Prepare メッセージを他の Replica ノードに送信し、そのノードが主ノードからの PrePrepare メッセージを受信し、主ノードのバッチの順序を承認したことを示します。

(6) Replica は 2f個のノードからの Prepare メッセージを受信した後、バッチのメッセージの合法性を検証し、検証が通過した後、他のノードに Commit メッセージをブロードキャストし、Primary ノードの検証結果に同意したことを示します。

(7) Replica ノードは 2f+1 の Commit を受信した後、バッチ内の取引を実行し、主ノードの実行結果と検証を行います。検証が通過すると、ローカル台帳に書き込まれ、チェックポイント（checkpoint）を通じて結果の検証が行われます。チェックポイントのルールは構成可能です。

以上の RBFT の通常プロセスから、RBFT は取引の検証プロセスをコンセンサスアルゴリズム全体のプロセスに挿入し、書き込み結果のコンセンサスを実現しています。まず、Primary ノードは取引を受信した後、最初に検証を行います。これにより、プラットフォームの計算能力が不正な取引によって消費されないことが保証され、Replica ノードは Primary ノードのビザンチン障害を効率的に処理できます。次に、Replica ノードは 2f個の Prepare メッセージを受信した後、Primary ノードの検証結果を検証します。結果が検証に通らない場合は、ViewChange メッセージがトリガーされ、再度システムの安全性が保証されます。

PBFT アルゴリズムでは、コンセンサスに参加するノードは役割に応じて主ノード（Primary）と従ノード（Replica）に分けられ、従ノードは受信した取引を主ノードに転送します。主ノードの最も重要な機能は、受信したすべての取引を一定の戦略に従ってパッケージ化し、すべてのノードがコンセンサス検証に参加することです。では、自然な疑問が生じます。主ノードがダウンしたり、システムエラーが発生したり、攻撃を受けてビザンチンノードになった場合、他の従ノードはどのようにして主ノードの異常を迅速に検出し、新しい主ノードを選出してコンセンサスを続行できるのでしょうか？これは BFT 類アルゴリズムの安定性を保証するために解決しなければならない問題です。

PBFT と RBFT では、ビュー（View）の概念が導入されており、主ノードを切り替えるたびにビューを切り替えます。ビュー変更（ViewChange）メカニズムは、全体のコンセンサスアルゴリズムの堅牢性を保証する鍵です。

現在、検出可能な主ノードのビザンチン行動には 3 つのシナリオがあります：

(1) ノードが停止し、メッセージを送信しなくなる；

(2) ノードが誤ったメッセージを送信する。誤りはメッセージの内容が不正確であったり、悪意のある取引を含むメッセージである可能性があります。ここで注意が必要なのは、メッセージのタイプはバッチである可能性もあれば、ビュー変更のための機能的メッセージである可能性もあるということです；

(3) 正常なノードを装い、正しいメッセージを送信する。

シナリオ (1) については、nullRequest メカニズムによって保証されます。行動が正しい主ノードは、取引が発生しない場合にすべての従ノードに nullRequest を送信してこの状況の真実性を説明します。従ノードが指定された時間内に主ノードからの nullRequest を受信しない場合、ビュー変更行動がトリガーされ、新しい主ノードが選出されます。

シナリオ (2) については、従ノードは主ノードからのメッセージを受信する際に、検証メカニズムを通じて内容を検証し、主ノードの取引が適切な形式に合致しない取引や悪意のある取引を含む場合、検証が通過しないと、ビュー変更を発起し、新しい主ノードを選出します。

シナリオ (3) については、考慮する必要はありません。極端な状況として、ビザンチンノードが正常なノードのように振る舞い続ける場合、それはビザンチンノードではないと見なされ、システム全体が結果の正確性を保証します。

従ノードは、主ノードに上記の異常が発生したことを検出したり、他のf+1 個のノードからのビュー変更メッセージを受信した後、全ネットワークにビュー変更メッセージをブロードキャストします。新しい主ノードがN-f個のビュー変更メッセージを受信すると、NewView メッセージを送信します。従ノードは NewView メッセージを受信した後、メッセージの検証と比較を行い、ビューの切り替え情報が同じであることを確認した後、正式にビューを切り替え、FinishVC メッセージを印刷して、全体のビュー変更プロセスを完了します。図 6.5 に示されています（ここで ViewChange はビュー変更を表し、Primary は主ノード、Replica は従ノードを表します）。

ブロックチェーンネットワークは、運用中にネットワークの揺れ、突然の停電、ディスク障害などの理由により、一部のノードの実行速度が大多数のノードに遅れたり、直接ダウンしたりする可能性があります。このようなシナリオでは、ノードは自動的に回復し、台帳を現在のブロックチェーンの最新の台帳状態に同期させる必要があります。これにより、今後の取引実行に参加できるようになります。このようなデータ回復作業を解決するために、RBFT アルゴリズムは動的データ自動回復メカニズムを提供します。

RBFT の自動回復メカニズムは、積極的にブロックとコンセンサス中のブロック情報を要求することによって、ノードのストレージをできるだけ早くシステム内の最新のストレージ状態と一致させます。自動回復メカニズムは、全体のブロックチェーンシステムの可用性を大幅に向上させます。RBFT は回復を容易にするために、実行データにチェックポイントを設定します。チェックポイントは全ネットワークのコンセンサス結果によって決定されます。これにより、各ノードのチェックポイント以前のデータがすべて一致することが保証されます。チェックポイントの他にも、一部のデータはまだコンセンサスされていないローカル実行の進捗が保存されています。このようにして、回復プロセスでは、まず本ノードのチェックポイントをブロックチェーンの他の正常なサービスノードのチェックポイントと同期させる必要があります。次に、チェックポイント以外の部分のデータを回復する必要があります。図 6.6 はチェックポイントの概念図であり、左側がチェックポイント部分、右側が現在の実行チェックポイント以外の部分です。図 6.7 は自動回復メカニズムの基本処理フローを示しています。

アライアンスチェーンのシナリオでは、アライアンスの拡張や特定のメンバーの退出により、アライアンスチェーンはメンバーの動的な出入りサービスをサポートする必要がありますが、従来の PBFT アルゴリズムはノードの動的な追加削除をサポートしていません。RBFT は、アライアンスメンバーの入場と退出をより便利に制御できるように、PBFT に対してノードの動的な追加削除機能を追加しました。図 6.8 に示されているように、RBFT は新しいノードの追加をアルゴリズム処理フローに組み込みました。

新しいノードは、証明書発行機関から発行された証明書を取得し、アライアンス内のすべてのノードにリクエストを送信します。各ノードが同意を確認すると、アライアンス内の他のノードに全ネットワークでブロードキャストします。ノードが 2f+1 の同意を得た応答を受け取ると、新しいノードとの接続を確立します。次に、新しいノードがN-f（Nはブロックチェーンアライアンスノードの総数）個のノードと接続を確立すると、能動的回復アルゴリズムを実行し、ブロックチェーンアライアンスメンバーの最新の状態を同期します。さらに、新しいノードは主ノードに通常のコンセンサスプロセスへの参加をリクエストします。最後に、主ノードが新しいノードのリクエストを確認すると、ノードの総数Nを変更する必要があるブロック番号を定義します（新しいノードの追加が元のコンセンサスに影響を与えないことを保証するために、新しいノードの追加は全ネットワークのコンセンサスNの変更を引き起こし、fの値が変更される可能性があることを意味します）。

RBFT ノードの動的削除とノードの動的追加のプロセスは類似しており、その主な処理関数は図 6.9 に示されています。主なプロセスは以下の通りです。

(1) 退出ノードは RPC リクエストを呼び出して本ノードのハッシュ値を取得し、全ネットワークのすべてのノードに退出リクエストを送信します。

(2) 削除リクエストを受け取ったノードの管理者が同意を確認し、全ネットワークに DelNode メッセージをブロードキャストし、そのノードがブロックチェーンコンセンサスから退出するリクエストに同意したことを示します。

(3) 既存のノードが 2f+1 の DelNode メッセージを受け取ると、そのノードは接続情報を更新し、退出リクエストを行ったノードとの接続を切断します。そして、接続を切断した後、全ネットワークに AgreeUpdateN メッセージをブロードキャストし、システム全体が取引処理を一時停止することを示し、コンセンサスに参加するノードのNを更新する準備をします。

(4) ノードが 2f+1 の AgreeUpdateN メッセージを受け取ると、ノードシステムの状態を更新します。

動的ノード退出関数の呼び出し

これで、退出リクエストを行ったノードは正式にブロックチェーンシステムから退出します。

以上が Hyperchain の改良版コンセンサスアルゴリズム RBFT の主要なアルゴリズムプロセスです。RBFT は、通常のコンセンサスプロセスにおける検証ステップを追加し、ノードの自動回復メカニズムを追加し、動的ノードの追加および削除などの機能を追加することで、従来の PBFT アルゴリズムよりも安定性、柔軟性、効率性が高く、企業向けアライアンスチェーンの生産環境のニーズをよりよく満たすことができます。動的ノード退出関数の呼び出し

これで、退出リクエストを行ったノードは正式にブロックチェーンシステムから退出します。

以上が Hyperchain の改良版コンセンサスアルゴリズム RBFT の主要なアルゴリズムプロセスです。RBFT は、通常のコンセンサスプロセスにおける検証ステップを追加し、ノードの自動回復メカニズムを追加し、動的ノードの追加および削除などの機能を追加することで、従来の PBFT アルゴリズムよりも安定性、柔軟性、効率性が高く、企業向けアライアンスチェーンの生産環境のニーズをよりよく満たすことができます。

P2P ネットワークは、ノード間のコンセンサスと情報伝達の通路であり、Hyperchain のネットワーク基盤です。

ネットワーク通信モジュールは、Node、Peer、および暗号化伝送の 3 つのサブモジュールで構成されています。Node サブモジュールは、本ノードの gRPC 呼び出しサービスを提供するために使用され、サーバーとして存在します。Peer サブモジュールは、他のノードにリクエストする際のクライアントとして機能します。暗号化モジュールは ECDH 鍵協商アルゴリズムを採用し、2 つのノード間でのみ認識される鍵を生成し、その後、強化版の AES 対称暗号化を使用してノード間で伝送されるデータを暗号化し、データ伝送の安全性を保証します。

• Hyperchain の主要なアーキテクチャ設計は、Peer と Node を分離することです。Peer は上層モジュールにメッセージ送信インターフェースを提供します。一方、Node はメッセージを受信し、上層にメッセージを送信する役割を果たします。各ノードからの情報を受信し、メッセージディスパッチルーターとして機能し、さまざまなメッセージを各層にポストします。Peer と Node は gRPCManager を介して管理され、各層の通信と配信を制御し、Peer が外部に公開するインターフェースとノードの各状態を実際に制御します。P2P モジュール内でも、各モジュールが相互に分離され、1 つの制御層によって制御され、サブモジュールがそれぞれの役割を果たします。

• ノードタイプ

  Hyperchain のノードは、検証ノード（VP）と非検証ノード（NVP）の 2 種類に分けられます：

  • 検証ノードは、ブロックチェーンネットワークでコンセンサス検証に参加するノードです；

  • 非検証ノードは、ブロックチェーンネットワークでコンセンサス検証には参加せず、記録のみを行います。

  NVP は主に取引転送と災害復旧に使用され、取引を自分で処理せず、コンセンサスにも参加しないため、接続されている VP に依存して全ネットワークの状態の最終的一貫性を保証する必要があります。しかし、NVP は取引を受信し、受信した取引を接続されている VP に転送して処理させることができます。

  VP は NVP に自動的に接続しないため、VP が再起動すると、接続されている NVP はすべて切断され、自動的に再接続されることはなく、手動で接続する必要があります。一方、NVP は完全な状態回復メカニズムを持ち、起動直後や他の理由で状態が遅れた場合でも迅速に同期できます。

  VP 間は gRPC リモート呼び出しサービスを介して通信し、P2P ネットワークを構成します。gRPC サービスは protobuf3 を使用してデータのシリアル化とデシリアル化を行い、データの完全性と伝送の効率性、安全性を保証します。

• フロー制御メカニズム

  基盤プラットフォームは、ビジネスニーズに応じてブロックチェーンシステムに入るトラフィックを人為的に制御できます。システムのトラフィックが設定された上限を超えると、超過分は受け入れを拒否します。これにより、ネットワーク通信中に大量の無駄な取引リクエストがノードの処理時間を占有し、他の取引を遅延させることを防ぎ、ビジネス要件を満たしつつシステムの安全性を保証します。

契約取引および通常の取引に対して、必要に応じたトラフィック構成を構成ファイルを通じて行うことができます。構成項目および構成情報は以下の表の通りです。

スマートコントラクトは、ブロックチェーン上に展開される自動実行可能なプログラムの一部であり、広義のスマートコントラクトには、プログラミング言語、コンパイラ、仮想マシン、イベント、状態機械、耐障害メカニズムなどが含まれます。その中で、アプリケーション開発に大きな影響を与えるのはプログラミング言語とスマートコントラクトの実行エンジン、すなわち仮想マシンです。仮想マシンはサンドボックスとして封じ込められ、全体の実行環境が完全に隔離されます。仮想マシン内部で実行されるスマートコントラクトは、ネットワーク、ファイルシステム、またはシステム内の他のスレッドなどのシステムリソースにアクセスできません。契約間では限られた呼び出しのみが可能です。

現在、スマートコントラクトの作成およびその実行環境には 3 つの典型的な実装例があります：

(1) IBM の Hyperledger Fabric プロジェクトは、Docker をスマートコントラクトの実行環境として使用しています；

(2) R3 Corda プロジェクトのスマートコントラクトは、JVM を契約の基盤実行環境として使用しています；

(3) Ethereum プロジェクトのスマートコントラクトは、Solidity で作成され、内蔵型の Solidity 仮想マシンで実行されます。

1. スマートコントラクト実行エンジン

   スマートコントラクトは本質的に自動実行可能なスクリプトプログラムであり、エラーが発生する可能性があり、深刻な問題や連鎖反応を引き起こす可能性があるため、スマートコントラクト実行エンジンの安全性は企業のブロックチェーンの安全性にとって非常に重要です。

   Solidity は、高度なプログラミング言語であり、スマートコントラクトの作成のために設計されており、構文は JavaScript に似ています。その作成は非常に簡単で、チューリング完全な言語です。さらに重要なのは、Solidity は契約の論理機能を実現するためだけに使用され、システムリソースへのアクセスインターフェース（ファイルを開く、オペレーティングシステムの低レベルリソースにアクセスするなど）を提供しないため、言語レベルで Solidity で作成されたスマートコントラクトがオペレーティングシステムから独立したサンドボックス内でのみ実行され、システムリソースを操作できないことが保証されます。一方、Fabric は Docker 形式の仮想マシンに基づいており、言語に特別な制限を設けていないため、安全性を完全に保証することはできません。

   Docker や JVM と比較して、Solidity 言語とそのスマートコントラクト実行エンジンは、プログラムのサイズが小さく、リソースの制御粒度が細かく、Solidity 言語を使用することで、オープンソースコミュニティがスマートコントラクト技術と経験において蓄積したものを最大限に活用し、スマートコントラクトの再利用性を向上させることができます。したがって、Hyperchain プラットフォームはスマートコントラクトの実装に Solidity 言語を選択し、Solidity 実行をサポートする高効率スマートコントラクト実行エンジン HyperVM を設計開発しました。

   HyperVM は、Hyperchain のプラグイン可能なスマートコントラクトエンジンの汎用フレームワークであり、異なるスマートコントラクト実行エンジンの接続を許可します。現在、Solidity 言語に互換性のある HyperEVM と Java 言語をサポートするスマートコントラクトエンジン HyperJVM および HVM を実装しており、今後は WVM、JSVM などの他の仮想マシンを統合する予定です。

   • HyperEVM

   HyperEVM は、オープンソースコミュニティがスマートコントラクト技術と経験において蓄積したものを最大限に活用し、スマートコントラクトの再利用性を向上させるために、EVM の仮想マシンを深く再構築したもので、EVM 上で開発されたスマートコントラクトと完全に互換性があります。HyperEVM は、Solidity 開発言語の互換性を保持しつつ、スマートコントラクト仮想マシンの性能を最適化し、Ethereum 仮想マシンのサンドボックスセキュリティモデルを保持し、十分な耐障害メカニズムを設け、システムレベルの最適化を行い、環境の隔離と組み合わせることで、契約が限られた時間内に安全に実行されることを保証し、実行性能はバイナリネイティブコードの効率に近づきます。

   • HyperJVM

   HyperJVM は、マイクロサービスのアーキテクチャ設計と多重セキュリティチェックメカニズムを通じて、ネイティブ Java スマートコントラクト実行のための高性能で安全な実行サンドボックスを提供します。HyperJVM には以下の利点があります：

   • Java 言語でのスマートコントラクト開発をサポートし、開発のハードルを大幅に下げます；

   • 完全なスマートコントラクトライフサイクル管理をサポートし、契約の展開、アップグレード、凍結などを含みます；

   • 豊富な台帳操作をサポートし、KV インターフェース、バッチ処理、範囲クエリ、列指向データ操作を含みます；

   • 複雑な契約ロジックの開発と契約間の呼び出しの承認をサポートします；

   • 契約のカスタムイベントリスニングをサポートします。

   • HVMHVM（Hyperchain virtual machine）は、Hyperchain に統合された軽量 Java スマートコントラクト実行環境です。Java 言語で書かれたスマートコントラクトを実行するためのサンドボックス環境を提供し、さまざまな方法でその安全性を保証します。HVM では、ユーザーは効率的にシンプルで強力なスマートコントラクトを書くことができます。HVM には以下の利点があります：

   • 完全な契約ライフサイクルのサポート；

   • より安全な Java 言語スマートコントラクト実行環境；

   • より効率的な状態空間操作メカニズム；

   • よりユーザーフレンドリーなプログラミングインターフェースソリューション。

• HyperVM 設計原理

  HyperVM の設計は図 6.11 の通りで、主なコンポーネントには契約コンパイル用のコンパイラ、コード実行最適化用の最適化器、契約バイトコード実行用のインタープリタ、契約実行エンジンの安全性制御用の安全モジュール、および仮想マシンと台帳の相互作用用の状態管理モジュールが含まれます。

HyperVM の取引実行の典型的なフローチャートは、HyperVM が 1 回の取引を実行した後、実行結果を返し、システムはそれを取引レシートと呼ばれる変数に保存します。その後、プラットフォームクライアントはこの取引のハッシュに基づいて取引結果を照会できます。

HyperVM の具体的な実行フローは以下の通りです。

(1) HyperVM は上層から渡された transaction を受信し、初期検証を行います。

(2) transaction のタイプを判断し、契約を展開する場合はステップ (3) を実行し、そうでない場合はステップ (4) を実行します。

(3) HyperVM は契約アカウントを新たに作成し、契約アドレスと契約コンパイル後のコードを保存します。

(4) HyperVM は transaction 内の取引パラメータなどの情報を解析し、実行エンジンを呼び出して対応するスマートコントラクトバイトコードを実行します。

(5) 命令の実行が完了した後、HyperVM は停止状態を判断し、未停止であればステップ (2) にジャンプし、そうでなければステップ (6) を実行します。

(6) HyperVM の停止状態が正常であれば実行を終了し、そうでなければステップ (7) を実行します。

(7) Undo 操作を行い、状態を今回の取引実行前にロールバックし、取引を終了します。

図 6.12 の実行命令セットモジュールは HyperVM 実行モジュールのコアであり、命令の実行モジュールには 2 つの実装があります。1 つはバイトコードに基づく実行であり、もう 1 つはより複雑で効率的な即時コンパイル（Just-in-time compilation、JIT）です。

バイトコード実行の方法は比較的単純で、HyperVM が実装した仮想マシンには命令実行ユニットがあります。この命令実行ユニットは、命令セットの実行を試み続け、指定された時間内に実行が完了しない場合、仮想マシンは計算ロジックを中断し、タイムアウトエラーメッセージを返します。これにより、スマートコントラクト内の悪意のあるコードの実行を防ぎます。

JIT 方式の実行は相対的に複雑で、即時コンパイルは動的コンパイルの一形態であり、プログラムの実行効率を向上させる方法です。通常、プログラムには静的コンパイルと動的直訳の 2 つの実行方式があります。前者は、プログラムが実行前にすべて機械コードに翻訳されるのに対し、後者は翻訳しながら実行されます。即時コンパイラは静的コンパイルと動的直訳を混合し、ソースコードを 1 行ずつコンパイルしますが、同時に翻訳されたコードをキャッシュします。このようにすることで、性能損失を低減できます。即時コンパイルされたコードは、静的コンパイルされたコードに比べて遅延バインディングを処理し、安全性を強化できます。JIT モードでスマートコントラクトを実行する主なステップは以下の通りです。

(1) スマートコントラクトに関連するすべての情報を契約オブジェクトに封装し、その後、コードのハッシュ値を使用してその契約オブジェクトがすでにコンパイルされているかどうかを確認します。契約オブジェクトには 4 つの一般的な状態があり、契約が不明、契約がコンパイル済み、契約が JIT 実行の準備ができている、契約エラーです。

(2) 契約の状態が契約が JIT 実行の準備ができている場合、HyperVM は JIT 実行器を選択してその契約を実行します。実行中、仮想マシンはコンパイル済みのスマートコントラクトをさらに機械コードにコンパイルし、push、jumpなどの命令を深く最適化します。

(3) 契約の状態が契約不明の場合、HyperVM はまず仮想マシンが強制的に JIT 実行を行うかどうかを確認します。もしそうであれば、順次コンパイルし、JIT 命令で実行します。そうでなければ、別のスレッドを開いてコンパイルし、現在のプログラムは通常のバイトコードコンパイルを行います。次回仮想マシンが同じエンコードの契約に再び遭遇した場合、仮想マシンは最適化された契約を直接選択します。このようにして、契約の命令セットは最適化され、契約の実行と展開の効率が大幅に向上します。

ブロックチェーンは本質的に分散型台帳システムであるため、ブロックチェーンプラットフォームの台帳システム設計は非常に重要です。Hyperchain の台帳設計は主に 3 つの部分から構成されています。まず、顧客の取引情報をブロックチェーンのこのチェーン構造を通じて保存し、顧客の取引の改ざんの難しさと追跡可能性を保証します。次に、アカウントシステムモデルを採用してブロックチェーンシステムの状態を維持します。すなわち、図 6.13 の契約状態部分です。最後に、台帳情報、取引情報などの重要な情報が存在するかどうかを迅速に判断するために、台帳は改良版の Merkle ツリーを使用して関連情報を保存します。

ブロック構造は 2 つの部分に分かれています：ブロックヘッダーと取引リスト。ブロックヘッダーには、固定サイズのブロックメタデータ情報が記録され、取引リストには、そのブロックに収録されたすべての取引情報が記録されています。ブロック内の相応する保存内容の具体的な定義は以下の表の通りです。

ブロックヘッダーは SHA256 ハッシュ計算を行い、ハッシュ値を生成します。この値は、ブロックチェーン内でそのブロックを一意に識別するデジタルフィンガープリントとして使用されます。また、ブロックヘッダー情報には、前のブロックのハッシュ値が引用されており、各ブロックにはその親ブロックのハッシュ値が含まれています。この方法により、すべてのブロックが垂直のチェーン構造に連結され、親ブロックにアクセスすることで、最終的にブロックチェーンの創世ブロック（最初のブロック）に遡ることができます。

この特別なチェーン構造設計により、親ブロックに何らかの変更があった場合、親ブロックのハッシュ値も変更され、子ブロック内の「親ブロックハッシュ値」フィールドが変更され、生成される子ブロックのハッシュ値が変更されます。Hyperchain ノード間では、チェックポイントごとに最新のブロックハッシュの比較が行われ、ローカルで維持されている最新のブロックハッシュ値がブロックチェーンネットワークで維持されている最新のブロックハッシュ値と一致する場合、ローカルで維持されているブロックチェーン情報が合法であることが確認されます。そうでない場合、ローカルノードは「ビザンチンノード」となったことを示します。

Hyperchain ブロックヘッダーの定義

取引構造の定義

Hyperchain システムは、ブロックチェーンデータを維持するだけでなく、システムの現在の状態情報も維持します。ビットコインシステムが UTXO モデルを採用しているのとは異なり、Hyperchain はアカウントモデルを採用してシステム状態を表現します。

Hyperchain ノードが「実行待ち」の取引を受け取ると、最初に実行モジュールに渡されます。取引の実行が終了すると、関連する契約アカウントの状態が変更されます。たとえば、ユーザー A が展開された契約 B を呼び出す取引を開始し、契約 B 内の変数値bが 0 から 1 に変更され、契約状態に永続化されます。

各取引の実行は、契約アカウントの状態の移転を意味し、システム台帳の状態の移転を表します。したがって、Hyperchain は状態移転システムとも見なすことができます。

Hyperchain の台帳には、チェーン上のすべての契約の状態情報が記録されます。契約状態メタデータには以下のいくつかのフィールドがあります。

上記のメタデータに加えて、契約アカウントには 2 つのデータフィールドがあります：実行可能なコードと変数ストレージスペース。実行可能なコードは、バイト配列でエンコードされた命令セットであり、各契約の呼び出しは実行可能なコードの実行を意味します。契約内で定義された変数は、契約に属するストレージスペースに保存されます。契約アカウントのストレージスペースの概念図は図の通りです。

ストレージスペースは標準のストレージ構造に似ており、論理的には連続したアドレスのストレージユニットで構成されています（ディスクストレージスペースを節約するために、空のストレージユニットはディスクに書き込まれません）。各ストレージユニットはスロットと呼ばれ、サイズは 32 バイトです。契約変数は、契約コンパイル段階でそのストレージスペース内のインデックスアドレスを取得し、内容は対応するスロットに保存されます。

簡易な契約状態データの概念図は図の通りです。

ブロックに収録された取引を順次処理した後、契約アカウントは元の状態から新しい状態に移行します。すべての契約アカウントの新しい状態を識別するためのハッシュ値を迅速に生成するために、Hyperchain システムでは Merkle ツリーを導入してハッシュ計算を行います。次に、Merkle ツリーの構造と役割について簡潔に説明します。

Merkle ツリーはハッシュバイナリツリーであり、大規模データの完全性を迅速に要約および検証するためのデータ構造です。このバイナリツリーには暗号ハッシュ値が含まれており、ビットコインネットワークでは Merkle ツリーを使用してブロック内のすべての取引を要約し、全体の取引集合のデジタルフィンガープリントを生成し、ブロックに特定の取引が存在するかどうかを検証するための効率的な手段を提供します。しかし、従来の Merkle ツリーは性能が低く、高頻度の大量データに対して計算のパフォーマンスがアライアンスチェーンの要求を満たすことができません。したがって、Hyperchain では、Merkle ツリーとハッシュテーブルの 2 つのデータ構造の利点を融合させた HyperMerkle ツリーを設計し、台帳ハッシュ計算の速度を大幅に向上させました。

従来の Merkle ツリーは、下から上に構築されます。図 6.17 に示されているように、L1、L2、L3、L4 の 4 つのデータブロックから Merkle ツリーを構築します。まず、これら 4 つのデータブロックのデータをハッシュ化し、ハッシュ値を対応する葉ノードに保存します。これらの葉ノードはそれぞれ Hash0-0、Hash0-1、Hash1-0、Hash1-1 です。

最下層の葉ノードの値を設定した後、非葉ノードの値を計算し始めます。計算方法は、隣接する葉ノードのハッシュ値を連結し、それを入力としてハッシュを計算し、得られた結果がこの対の葉ノードの親ノードのハッシュ値となります。

同様の操作を続け、最上部の 1 つのノードが残るまで繰り返します。これが Merkle ルートです。ルートノードのハッシュ値は、このバッチのデータブロックの識別子を表します。

この従来の Merkle ツリーは、ビットコインシステムのようにバッチ取引データをハッシュ化するシーンには適していますが、アライアンスチェーンにおける台帳ハッシュの迅速な計算の要求には応えられません。したがって、Hyperchain では、ハッシュテーブルの特性を組み合わせた HyperMerkle ツリーを再設計しました。

HyperMerkle ツリーは、ハッシュテーブルに基づいて構築された多分岐ツリーであり、ハッシュテーブルの各ストレージユニットは HyperMerkle ツリーの 1 つの葉ノードであり、すべての葉ノードはn層ノードと呼ばれます。隣接するいくつかの葉ノードを 1 つの親ノードに要約し、生成された親ノードの集合はn-1 層ノードと呼ばれます。上記の操作を再帰的に繰り返し、最上部の 1 つのノードが HyperMerkle ツリーのルートノードとなります。各親ノードは子ノードのハッシュ値リストを維持します。HyperMerkle ツリーの構造は図の通りです。

HyperMerkle ツリーの 1 回の計算プロセスは以下の通りです。

(1) 入力データセット内の各要素を key 値に従って異なる位置にハッシュし、ハッシュ衝突が発生した場合はチェーン法で処理します。

(2) 変更が関与する各葉ノードに対してハッシュ再計算を行い、入力は葉ノードの内容です。計算が完了したら、計算結果を対応する親ノードの子ノードハッシュリストに書き込みます。

(3) 変更が関与するn-1 層ノードに対してハッシュ再計算を行い、入力はノードの子ノードハッシュリスト（今回の計算に関与しない子ノードのハッシュ値は前回の計算値を使用）です。計算が完了したら、計算結果を対応する親ノードの子ノードハッシュリストに書き込みます。

(4) ステップ (3) を繰り返し、1 層ノードまで計算を行います。1 層ノードはルートノードとも呼ばれ、台帳の現在のハッシュ値はルートノードのハッシュ値で表されます。

(5) 今回再計算したすべてのノードの内容を永続化します。

HyperMerkle ツリーは、データのバッチを維持し、各回の変更後に変更された部分のみをハッシュ再計算することで、計算効率を大幅に向上させます。

HyperMerkle ツリーは、Hyperchain 内で具体的に 2 つの部分の内容のハッシュ計算を行います：契約アカウントのストレージスペースのハッシュ計算；契約アカウントセットのハッシュ計算。

各契約アカウントに対して、ストレージスペースの内容は HyperMerkle ツリーの入力であり、出力は契約アカウントのメタデータに保存されます。契約アカウントセットに対しては、各契約の内容が HyperMerkle ツリーの入力であり、出力はブロックに保存され、現在の契約アカウントセット状態の識別子として扱われます。

企業向けブロックチェーンプラットフォームはアライアンスチェーンです。「アライアンスチェーン」という用語には 2 つの意味があります：まず、それはブロックチェーンであり、次に、限られたメンバーの連合性を持つということです。したがって、企業のブロックチェーンの安全性メカニズムの設計では、従来のブロックチェーンが直面する各メンバー間の信頼問題を考慮する必要があるだけでなく、連合メンバーの入場と退出の安全管理メカニズムも考慮する必要があります。このため、Hyperchain プラットフォームは、暗号学に基づく多層暗号化メカニズムを提案し、取引ネットワーク、取引当事者、取引実体などの複数のレベルで安全な暗号化アルゴリズムを使用してユーザー情報を全方位で暗号化し、CA に基づく権限制御メカニズムを提案しました。さらに、企業向けブロックチェーンプラットフォームの高い拡張性、高可用性などのニーズを満たすために、データ管理、メッセージ購読などの機能を提供しています。

データの安全性とプライバシー保護を向上させ、柔軟で独立したビジネスシーンをサポートするために、Hyperchain は Namespace（名前空間）メカニズムを設計し、ブロックチェーンネットワーク内部の取引の分割コンセンサスを実現します。ユーザーは Namespace に従ってビジネス取引を区分けでき、同じ Hyperchain アライアンスチェーンネットワーク内のノードは、参加しているビジネスに基づいて Namespace 単位のサブネットワークを構成し、物理的に異なるビジネス間の隔離を実現し、各空間の取引が互いに干渉しないようにします。

単一の Hyperchain ノードは、そのビジネスニーズに応じて 1 つまたは複数の Namespace に参加することを選択できます。図 6.19 に示されているように、Node1、Node2、Node4、Node5 は namespace1 を構成し、Node2、Node3、Node5、Node6 は namespace2 を構成します。この中で、Node1 は namespace1 にのみ参加し、Node2 は 2 つの Namespace の両方に参加しています。Namespace 内では CA 認証の方法でノードの動的な参加と退出を制御します。

特定の Namespace 情報を持つ取引の検証、コンセンサス、保存、および伝送は、特定の Namespace に参加するノード間でのみ行われます。異なる Namespace 間の取引は並行して実行できます。たとえば、図 6.19 の Node1 は namespace1 内の取引の検証および対応する台帳の維持にのみ参加でき、Node2 は namespace1 と namespace2 の取引実行および台帳維持に同時に参加できますが、Node2 内の namespace1 と namespace2 の台帳は互いに隔離され、互いに見えません。

より細かいアライアンスチェーンのプライバシー保護ソリューションを提供するために、Hyperchain は主にプライバシー取引の証明、プライバシー契約の展開、呼び出し、アップグレードなどを実装しています。

Hyperchain は取引粒度のプライバシー保護をサポートし、取引を送信する際にその取引の関連者を指定し、その取引明細は関連者のみに保存され、プライバシー取引のハッシュは全ネットワークのコンセンサス後に公共台帳に保存され、プライバシーデータの有効な隔離を保証し、プライバシー取引の真実性を検証できます。

図はプライバシー取引と通常のコンセンサス取引のそれぞれのプロセスと差異を示しています。

• 暗号化上チェーン / ハッシュ上チェーン

  特に高感度の情報については、取引や台帳との強い関連性がない場合、データを明文で上チェーンする前に対称暗号化の方法で暗号化し、プライバシーデータを保護することができます。また、元のデータやファイルをオフチェーンに保存し、ハッシュの方法でそのデジタルサマリーを上に保存することで、データ容量とデータの感度の問題を解決できます。

• 契約アクセス制御

  契約コーダーは、スマートコントラクトとアクセス制御ポリシーを通じて、データへのアクセスを制限する役割とユーザーを制限できます。つまり、契約内でノード、役割、ユーザーに対して異なる契約関数のアクセス権限をカスタマイズします。契約コーダーは、契約内でいくつかの高権限の関数に対して