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 の元々の三段階処理プロセス（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、view の更新の準備をします。

(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 の仮想マシンを深く再構築したものです。HyperEVM は Solidity 開発言語の互換性を保持しつつ、スマートコントラクト仮想マシンの性能を最適化し、Ethereum 仮想マシンのサンドボックスセキュリティモデルを保持し、十分な耐障害メカニズムを備え、システムレベルの最適化を行い、環境隔離と組み合わせることで、契約が限られた時間内に安全に実行されることを保証し、実行性能はバイナリネイティブコードの効率に近づきます。

• HyperJVM

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

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

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

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

  • 複雑な契約ロジックの開発と権限のあるクロス契約呼び出しをサポートします。

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

• HVM HVM（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 ツリーとハッシュテーブルのそれぞれの利点を融合させた 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層ノードと呼ばれます。隣接するいくつかの葉ノードを親ノードに要約し、生成された親ノード集合は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 は取引粒度のプライバシー保護をサポートし、取引を送信する際にその取引の関連者を指定し、その取引の明細は関連者のみに保存され、プライバシー取引のハッシュは全ネットワークのコンセンサス後に公共帳簿に保存され、プライバシーデータの有効な隔離を保証し、そのプライバシー取引の真実性を検証できます。

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

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

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

• 契約アクセス制御

  契約コーダーは、スマートコントラクトとアクセス制御戦略を通じて、データへのアクセスを制限する役割やユーザーを制御できます。つまり、契約内でノード、役割、ユーザーに対して異なる契約関数のアクセス権限をカスタマイズできます。契約コーダーは、いくつかの高権限の関数に対して権限制御を設定し、その関数が特定のアドレスの呼び出し者によってのみ呼び出されるようにすることで、アクセス権限の制御を実現します。

Hyperchain はプラグイン可能な多層暗号化メカニズムを採用し、ビジネスの完全なライフサイクルに関与するデータ、ユーザー、通信接続などに対して異なる戦略の暗号化を行い、企業ユーザーが具体的なビジネスシーンに応じて暗号化方法を選択できるようにし、同時にシステムの安全性と効率性を保障します。

1. ** ハッシュアルゴリ