banner
leaf

leaf

It is better to manage the army than to manage the people. And the enemy.
follow
substack
tg_channel

ブロックチェーンとネットワークセキュリティに関する事実

インターネットの発展に伴い、そのユーザー規模、アプリケーション数、帯域幅が急速に増加しています。過去数年の間に、スマートデバイスという新しいユーザーキャリアがインターネットの世界に登場しました。それは多様な形態を持ち、シンプルなものから複雑なものまであり、冷蔵庫、エアコン、電子レンジのようにシンプルなものから、ドローンや自動運転車のように精密なものまであります。これらのスマートデバイスは、IoT(モノのインターネット)デバイスと総称され、実用プログラムの機能とネットワーク運用を制御するために使用されます。十分な事例があり、攻撃者が IoT デバイスを利用して、分散型サービス拒否(DDoS)攻撃と呼ばれる大規模なネットワーク攻撃を仕掛けていることが証明されています。この章では、DDoS 攻撃について学び、ブロックチェーンが企業組織がこのような大規模なネットワーク攻撃に対抗するための展開操作を支援する方法を学びます。

DDoS 攻撃は悪意のある意図を持ち、地理的に分散したシステムから大量のリクエストを送信することで、サーバーの正当なトラフィックを妨害し、正常なユーザーのアクセスを阻害します。まず、サービス拒否(DoS)攻撃の仕組みを理解しましょう。DoS 攻撃中、攻撃者は大量のリクエストでターゲットコンピュータを爆撃し、サーバーリソースを枯渇させ、正当なユーザーのリクエストを失敗させます。DoS 攻撃では、攻撃者は単一のマシンを使用して攻撃し、ターゲットサーバーのリソースを枯渇させます。それに対して、DDoS 攻撃はより強力で、数百万台のコンピュータを使用してターゲットサーバーを圧倒することができます。

ますます多くの企業組織が、自社のアプリケーションサービスを大量のインフラを持つクラウドに移行し、膨大な顧客のリアルタイムニーズに応えています。企業は自分たちの大規模なクラウドサーバーインフラを構築することも、クラウドサービスプロバイダーが提供するサーバーに移行することもできます。今日、攻撃者は DDoS 攻撃手法を使用してターゲットサービスを破壊することを好みます。なぜなら、彼らは GB や TB レベルのランダムデータを生成してターゲットの被害者を爆撃でき、ターゲットのセキュリティチームは数百万に及ぶ攻撃源を特定して阻止するのが難しいからです。

さらに、攻撃者は攻撃源のマシンを合法的に制御することは決してなく、巧妙に設計されたマルウェアを使用して世界中の数百万台のコンピュータを感染させ、完全なアクセス権を取得して大規模な DDoS 攻撃を実行します。これらの感染したコンピュータの集合体はボットネット(botnet)と呼ばれ、個々の感染したコンピュータはボット(bot)と呼ばれます。

世界で最初の DDoS 攻撃事件を明確に追跡することは難しいですが、最初の注目すべき DDoS 攻撃は 1999 年にミネソタ大学を対象に発生しました。220 以上のシステムに影響を及ぼし、ネットワーク全体の施設が数日間ダウンしました。

2016 年 10 月 21 日金曜日、世界中が Dyn(DNS ホスティングプロバイダー)に対する最も複雑な DDoS 攻撃の発生を目撃しました。Dyn は、Mirai ボットネットが悪意のある攻撃トラフィックの主要なソースであることを確認しました。この攻撃は、インターネットのセキュリティと脅威の状況に新たな関心を呼び起こしました。

DDoS 攻撃を仕掛けるために、ハッカーは自らボットネット全体を構築することも、ダークウェブからボットネットリソースを借りることもできます。攻撃者が武器を準備すると、脆弱なサイト、ホスト、またはネットワーク全体を見つけるだけです。

ロッキード・マーチン社のコンピュータ科学者は、ネットワークキルチェーンという用語を提唱しました。これは、偵察から最終的な攻撃ターゲットに至るまでのネットワーク攻撃の全段階を説明しています。これらの段階には以下が含まれます:

・偵察:攻撃者はターゲットデバイスを特定し、その脆弱性を探し始めます。

・武器化:攻撃者はリモートツールキットとマルウェア(ウイルスやワーム)を使用して脆弱性に対して攻撃を仕掛けます。

・悪意のあるコードの拡散:攻撃者はフィッシングメールの送信、秘密のダウンロード、USB デバイス、内部者の協力など、さまざまな方法で攻撃コードを被害者のネットワークに注入します。

・脆弱性の悪用:悪意のあるコードは攻撃を引き起こし、ターゲットネットワークに対して脆弱性を利用する措置を講じます。

・インストール:マルウェアは被害者のコンピュータに自動的にインストールされます。

・コマンドと制御:マルウェアはリモート攻撃者に被害者のマシンへのアクセス制御権を与えます。

DDoS の観点から各段階を理解するためには、ボットネットインフラストラクチャとその構築方法を理解することが非常に重要です。

1. ボットネットの構築

DDoS 攻撃の分散型特性は、世界中の数百万台の感染したコンピュータを利用する必要があります。今日、攻撃者はダークウェブを利用して、いつでも利用可能なボットネットリソースを借りたり購入したりできます。Jumper、Dirt、Pandore などのツールは、実際に攻撃者がこれらのボットネットを構築する際の技術的障壁を低下させ、あるいは排除します。

以下の図はボットネットの全ライフサイクルを示しています:

2. 偵察

偵察を受けたターゲットシステムは、データセンター全体の大きさから、コンピュータ 1 台の小ささまで様々です。この 2 つのケースのいずれにおいても、ボットネットの構築には、マルウェアが攻撃利用できる脆弱性を持つホストを特定する必要があります。攻撃者は、ターゲットに直接または間接的に関連する情報を探し、保護された資産に不正にアクセスしようとします。攻撃者は、ファイアウォール、侵入防御システム(IPS)、Web アプリケーションファイアウォール、エンドポイント保護システムなど、既存のセキュリティシステムを回避するためのあらゆる方法を試みます。

3. 武器化

多数のオープンソースソフトウェアリソースを使用することで、攻撃者は悪意のあるコードを構築する際に直面する技術的障壁を効果的に回避できます。プログラマーが悪意のある意図を持ち、コードを開発する場合、新しいマルウェアが開発される可能性があり、セキュリティシステムは最初にこれらの新しいマルウェアを検出するのが難しいです。

以下は DDoS 攻撃に使用される一般的なツールのリストです:

・低軌道イオン砲(LOIC):これはハッカー組織 anonymous が最も好んで使用するツールの 1 つです。これは、ターゲットサーバーを混雑させるために大量の TCP、UDP、または HTTP トラフィックを生成できるシンプルな洪水ツールです。これはもともとサーバーのパフォーマンスのスループットをテストするために開発されました。しかし、anonymous 組織はこのオープンソースツールを使用して複雑な DDoS 攻撃を仕掛けます。このツールは後に IRC 機能が強化され、ユーザーが IRC を通じて接続システムを制御できるようになりました。

・高軌道イオン砲(HOIC):LOIC を数年間効果的に使用した後、

2. 偵察

偵察を受けたターゲットシステムは、データセンター全体の大きさから、コンピュータ 1 台の小ささまで様々です。この 2 つのケースのいずれにおいても、ボットネットの構築には、マルウェアが攻撃利用できる脆弱性を持つホストを特定する必要があります。攻撃者は、ターゲットに直接または間接的に関連する情報を探し、保護された資産に不正にアクセスしようとします。攻撃者は、ファイアウォール、侵入防御システム(IPS)、Web アプリケーションファイアウォール、エンドポイント保護システムなど、既存のセキュリティシステムを回避するためのあらゆる方法を試みます。

3. 武器化

多数のオープンソースソフトウェアリソースを使用することで、攻撃者は悪意のあるコードを構築する際に直面する技術的障壁を効果的に回避できます。プログラマーが悪意のある意図を持ち、コードを開発する場合、新しいマルウェアが開発される可能性があり、セキュリティシステムは最初にこれらの新しいマルウェアを検出するのが難しいです。

以下は DDoS 攻撃に使用される一般的なツールのリストです:

・低軌道イオン砲(LOIC):これはハッカー組織 anonymous が最も好んで使用するツールの 1 つです。これは、ターゲットサーバーを混雑させるために大量の TCP、UDP、または HTTP トラフィックを生成できるシンプルな洪水ツールです。これはもともとサーバーのパフォーマンスのスループットをテストするために開発されました。しかし、anonymous 組織はこのオープンソースツールを使用して複雑な DDoS 攻撃を仕掛けます。このツールは後に IRC 機能が強化され、ユーザーが IRC を通じて接続システムを制御できるようになりました。

新たに攻撃を受けた被害者のシステムにダウンロードされます。ダウンロードが完了すると、スクリプトはこの新しいボットノードで新しい攻撃プロセスを自動的に開始します。全体の攻撃メカニズムは HTTP、FTP、リモートプロシージャコール(RPC)プロトコルを使用します。この方法では、攻撃者は被害者のマシンを操作し、攻撃を受けたシステムは攻撃者の中央リポジトリに接続し、中央リポジトリから悪意のあるコードをダウンロードします。以下の図に示すように:

・逆リンク拡散:この方法では、攻撃者はツールキットを新たに感染したホストに移植します。このツールキットは、感染したシステムからのファイル転送リクエストを受け入れるように巧妙に設計されています。同時に、逆チャネルファイルコピーのプロセスは、通常のファイル転送プロトコル(TFTP)を使用してポートリスナーによって実行できます。中央ソース拡散方法とは異なり、攻撃者は脆弱性を利用し、攻撃コードを攻撃を受けたホストに一緒に転送します。以下の図に示すように。

・自動拡散:このメカニズムでは、攻撃者がシステムに侵入すると、彼らのツールキットが感染したホストにコピーされます。このメカニズムは、伝送方法のレベルで異なり、攻撃ツールキットは最初に感染したホストに攻撃者によって埋め込まれます。この方法では、攻撃者は最初に脆弱性を利用した攻撃を転送し、その後、中央リポジトリからではなく、自分のコードを転送します。以下の図に示すように:

5. 脆弱性の悪用

一度悪意のあるプログラムがネットワークに入ると、未修正のソフトウェアの脆弱性、欠陥のあるソフトウェアプログラミングプラクティス、またはユーザーの不注意を含むさまざまな脆弱性を悪用し始めます。通常、ネットワークには多くの脆弱性が存在し、それらの利用可能性により、脆弱性自体がより致命的になります。

6. インストール

インストール段階では、悪意のあるソフトウェアがターゲットシステムに固定され、リモート攻撃者がそれにアクセスできるようになります。インストール中、悪意のあるソフトウェアはシステムのユーザースペースまたはカーネルスペースに埋め込まれることがあります。ユーザースペースにインストールされた悪意のあるソフトウェアは検出されやすいですが、カーネルスペース内の悪意のあるソフトウェアは、セキュリティシステム(エンドポイント保護、エンドポイント検出および応答プラットフォームなど)によってほとんど検出されません。

7. コマンドと制御(C2)

侵入ツールが成功裏にインストールされた後、ターゲットホストは攻撃者のリモート中央システムによって完全に制御されます。これらの侵入されたデバイスのネットワークはボットネットと呼ばれ、攻撃者によって自由に操作されます。しかし、ボットネットノードは攻撃者によってアクティブ化されるまで休眠状態を維持します。公共のピアツーピアネットワーク上では、暗号化されたボットホスト間の通信も存在します。

8. ターゲットに対する行動

C2 チャネルが確立されると、攻撃者はターゲットに対して DDoS 攻撃を仕掛けることができます。この段階では、攻撃者はスクリプトを実行して、全ボットネット内のすべてのボットホストをアクティブ化します。攻撃者はまた、ボットネットを構成し、生成する必要のある攻撃トラフィックの種類を知る必要があります。

ブロックチェーンは、独立した当事者が第三者の介入なしに通信できる分散型ネットワークです。DDoS 攻撃からネットワークを保護するために、企業サービスは複数のサーバーノードに分散され、高い弾力性を提供し、単一障害点を排除します。ブロックチェーンを使用する主な利点は以下の通りです:

・ブロックチェーン技術は、ブラックリストに載った IP を保存するための分散型台帳を展開するために使用できます。

・ブロックチェーン技術は、単一障害点のリスクを排除します。

ブロックチェーンの DDoS 防御プラットフォームは、まず Ethereum ブロックチェーンの Node.js と Truffle を使用してテスト環境を準備する必要があります。DDoS 攻撃からネットワークを保護するために、既存のブロックチェーンプロジェクトを使用します。このプロジェクトは、リンクhttps://github.com/gladiusio/gladius-contracts で見つけることができます。

Gladius プロジェクトのインフラストラクチャを準備するために、以下の手順に従う必要があります:

1)まず、システム環境に Node.js をインストールします。リンクはhttps://nodejs.org/uk/download/package-manager/#arch-linux です。

2)テスト環境に truffle をインストールする必要があります:

3)コマンドラインで次のコマンドを実行します:

4)次に、コマンドラインで次のコマンドを実行してテストネットワークを起動します:

以下のスクリーンショットは、上記のコマンドを実行した際の出力内容を示しています:

5)このターミナルウィンドウでは、テストブロックチェーンネットワーク内のすべてのトランザクションを見ることができます。次に、新しいターミナルウィンドウを開き、作業ディレクトリに移動する必要があります。

プロジェクトの構成を行うには、以下の指示に従ってください:

1)https://github.com/gladiusio/gladius-contracts のウェブページで.zip ファイルを見つけてダウンロードし、指定したパスに解凍します。

2)truffle.js のコードを以下のコードに置き換えます:

3)gladius-contracts-master という名前のフォルダに入り、以下のコマンドで契約をコンパイルします:

以下のスクリーンショットは、上記のコマンドを実行した際の出力内容を示しています:

4)次に、以下のコマンドを実行して契約を ganache-cli のローカルブロックチェーンにデプロイします:

以下のスクリーンショットは、上記のコマンドを実行した際の出力内容を示しています:

5)次に、truffle test コマンドを使用してユニットテストを開始し、スマートコントラクトが正常に動作することを確認する必要があります:

6)https://github.com/gladiusio/gladius-control-daemon のウェブページから.zip ファイルをダウンロードし、gladius-contracts と同じフォルダに解凍します。

7)次に、ターミナルで gladius-control-daemon-master フォルダを見つけ、契約アプリケーションバイナリインターフェース(ABI)をリンクします。ABI は、2 つのプログラムモジュール間のインターフェースであり、1 つのプログラムモジュールはマシンコードレベルにあります:

以下のスクリーンショットは、上記のコマンドを実行した際の出力内容を示しています:

8)次のステップでは、npm install コマンドを実行して必要な依存関係をインストールできます:

9)次に、node index.js コマンドを実行してスクリプトを起動できます:

10)新しいターミナルウィンドウを開き、gladius-networkd コマンドを実行します:

11)次のステップでは、もう一つ新しいターミナルを開き、gladius-controld コマンドを実行します:

12)ノードを起動するには、新しいターミナルで以下のコマンドを実行する必要があります:

以下のスクリーンショットは、上記のコマンドを実行した際の出力内容を示しています:

13)特定のプールにデータを提出し、プールの一部として受け入れるか拒否することができます:

14)ノードの作成が完了したら、管理アプリケーションを使用してその状態を確認できます。これにより、ブロックチェーン内のノード情報が表示されます:

今すぐ Gladius クライアントをコンピュータにダウンロードし、システムにアクセスしてください。

Gladius をアクティブにすると、すべてのノードが連続したリクエストの流れを処理し、ウェブサイトの接続を検証し、悪意のある活動を阻止します。Gladius は、システム内のいくつかの問題を解決し、安定したシステムを実現するために積極的に取り組んでいます。

ブロックチェーンは以下のシナリオで使用できます:

・対立状況:ブロックチェーンネットワークは、信頼できる当事者だけでなく、信頼できない当事者も接続します。したがって、対立状況に注目し、問題をシームレスに解決することが重要です。ブロックチェーンは、トランザクションを確認し、ブロックを構築するためにコンセンサスメカニズムを使用します。異なるブロックチェーンは異なるコンセンサスモデルを使用しますが、例えばプルーフ・オブ・ワーク(PoW)、プルーフ・オブ・ステーク(PoS)など、目的は同じであり、対立を回避し、トランザクションを成功させることです。

・公共データベースの共有:企業組織がその従業員(管理者または非 IT 担当者)、請負業者、または第三者間で公共データベースを共有する場合、許可されたチェーンは本当に要件を満たすことができます。集中型データベースが異なる当事者間で共有されると、特権の昇格を使用したアクセス制御のリスクが増加します。許可されたチェーンを使用する場合、提出されたピアのみがデータベースを変更する権限を持ち、トランザクションの裏書は任意の事前選択された参加者によって行うことができます。

・トランザクションビジネスルールの要件:ビジネスモデルがトランザクションを実行するためのシンプルまたは複雑なロジック戦略を必要とする場合、ブロックチェーンはそのロジック戦略を通じて良い保証を提供できます。例えば、Ethereum のスマートコントラクトや Hyperledger のチェーンコードなどです。ビジネス戦略は常にノードソフトウェア内で定義され、そのソフトウェアはノードが定義されたルールに従って動作することを強制します。

・システムの透明性の要件:組織のビジネスモデルがそのサプライチェーン全体の顧客またはサプライヤーに対して透明性を維持する必要がある場合、分散型台帳技術はサプライチェーン運営管理システムのエンドツーエンドの可視性をより良く提供できます。権限制御のないブロックチェーンネットワークでは、各ノードがブロックチェーン台帳を読み書きできるため、透明性が確保されます。しかし、権限のある環境では、企業は事前選択されたノードのみがブロックチェーン計算プロセスや台帳管理に参加することを好みます。

・データの不変性の要件:企業組織がデータの追加専用の高度に安全なデータベースを開発する必要がある場合、暗号ハッシュとデジタル署名はこの高度に安全な台帳を構築するのに役立ちます。

追加のデータベースでは、暗号ハッシュとデジタル署名がこの高度に安全な台帳を構築するのに役立ちます。各ブロックを構築する際に前のブロックのハッシュ値を使用するため、一度データベースが作成されると、それを変更したり再配置したりすることは不可能です。

ブロックチェーンは業界で見られる最も強力な技術の 1 つですが、すべての作業に常に適しているわけではありません。これにより、評価段階がすべての面で非常に重要になります。それが最も適しているビジネスを理解した後、ブロックチェーンが適していない状況をいくつか見てみましょう:

・かなり大きなデータの保存:その分散型および分散性のため、ブロックチェーンネットワーク内の各ノードとともに全データベースが保存されます(権限ベースの台帳の場合、事前選択された参加者のみがデータを読み書きできるため、データベースの複製には長い時間がかかり、速度が遅くなります)。この目的を達成するために構築されたソリューションがいくつかありますので、簡単に見てみましょう。

・トランザクションルールが頻繁に変更される:スマートコントラクト戦略が設定され、起動されると、実行パスは変更されません。ビジネスプロセスや操作が頻繁に変更される組織は、ブロックチェーンベースのアプリケーションの使用を推奨されません。ブロックチェーンネットワーク内の各サブシステムとサブプロセスは決定的である必要があります。

・ブロックチェーンが外部データソースからデータを取得する必要がある:ブロックチェーンのスマートコントラクトを構築することは、外部データソースから情報を取得するためではありません。ブロックチェーンと信頼できるデータベース間で通信するように設定しても、通常のデータベース操作として機能します。そして、この場合、ブロックチェーンのスマートコントラクトは外部データベースからエントリを抽出しません。代わりに、信頼できるデータベースがデータをブロックチェーンにプッシュする必要があります。

ブロックチェーンは、私たちに素晴らしい技術とビジネスの機会をもたらしており、異なる組織間の協力を促進しています。リーダーたちは現在、ビジネス運営におけるブロックチェーン技術の利用を体験し、探求しています。市場の変化するニーズに対応できるようにするためです。ブロックチェーン計画の実施におけるいくつかの重要な問題に焦点を当ててみましょう:

・私の業界で最も信頼できるブロックチェーン技術のリーダーは誰ですか?

・私の競合他社はブロックチェーンについてどう考えていますか?

・どのビジネス部門が最も影響を受けやすいですか?

・私たちのブロックチェーン展開は誰に最も影響を与えますか?彼らはどのように反応する可能性がありますか?

・ブロックチェーンの可能なビジネスケースは何ですか?どのようにしてより良く、持続可能なビジネスモデルを実現できますか?

・展開に関わる総コスト要因は何ですか?

・現在の規制がブロックチェーンアプリケーションに与える影響は何ですか?

・私たちはどのようにして規制当局と協力して市場にブロックチェーンアプリケーションを導入し、ウィンウィンの関係を実現できますか?

・私たちはどのようにしてブロックチェーンアプリケーションにセキュリティコントロールを適用できますか?

ブロックチェーンアプリケーションを市場に投入する前に、一連のブレインストーミングが行われることが予想されますが、プロジェクトの範囲を明確にし、適切な利害関係者と提携することをお勧めします。

怠惰と好奇心は、革新と進歩の源泉です。

ビットコイン、イーサリアムなどのパブリックブロックチェーンプラットフォームの実験は、分散型取引をサポートする上でのブロックチェーン技術の巨大な利点を十分に証明しています。

ますます多くの企業がブロックチェーン技術に注目し、複雑なビジネストランザクションの効率を向上させ、多方面の協力コストを削減するためにそれをビジネスシーンに導入しようとしています。Hyperledger Fabric プロジェクトが誕生しました。Fabric は、Hyperledger コミュニティの初期プロジェクトの 1 つとして、テクノロジー業界と金融業界からの最新の成果を集約し、アライアンスチェーンシナリオ向けの分散型台帳プラットフォームの実現を初めて提供しました。

この章では、読者がソースコードから Fabric 環境をローカルでコンパイルおよびインストールする方法、そして複数のサーバー環境で典型的な Fabric ネットワークを展開する方法を学びます。また、コンテナ方式を使用して単一の環境で完全な Fabric ネットワーク環境を迅速に起動する方法も紹介します。次に、チェーンコードとアプリケーションチャネルの関連操作および SDK サポートについて説明します。最後に、製品環境で Fabric ネットワークを展開する際の注意事項について考察します。

Fabric は 1.0 バージョンから、アーキテクチャを再設計し、ノードの役割を分離しました。同時に、セキュリティ、パフォーマンス、スケーラビリティ、プラグイン性の面でも多くの改善が行われました。トランザクションをネットワークに送信する前に、十分な数の承認ノードから承認サポートを収集し、専用の順序ノードを使用してネットワーク全体の非常に重要な順序段階を担当させる必要があります。

現在、ネットワークには以下の 4 種類の異なるサービスノードが存在し、互いに協力してブロックチェーンシステム全体の機能を完成させています。ネットワーク内のノードの役割を分離することは、Fabric 設計の大きな革新であり、アライアンスチェーンシナリオの特別な要求と環境によって決定されます:

・承認ノード(Endorser):トランザクションの提案を確認し、承認し、トランザクション実行結果を計算します。

・確認ノード(Committer):トランザクション結果を受け入れる前に再度合法性を確認し、合法的なトランザクションの台帳への変更を受け入れ、ブロックチェーン構造に書き込みます。

・順序ノード(Orderer):ネットワークに送信されるすべてのトランザクションを順序付け、順序付けられたトランザクションを設定に従ってブロックに整理し、その後確認ノードに処理のために提出します。

・証明書ノード(CA):ネットワーク内のすべての証明書を管理し、標準的な PKI サービスを提供します。

さらに、ネットワークは複数のチャネルをサポートする特性を持っています。独立したシステムチャネルがネットワーク内のさまざまな設定情報を管理し、他のアプリケーションチャネル(ユーザーがトランザクションを送信するために使用)を作成する役割を果たします。

現在、Fabric ネットワークを起動するには、以下の主要な手順に従う必要があります。

1)ネットワーク内の各種設定を準備します。これには、ネットワーク内のメンバーの組織構造と対応する ID 証明書(cryptogen ツールを使用して作成)を含みます。システムチャネルの初期設定ブロックファイルを生成し、新しいアプリケーションチャネルの設定更新トランザクションファイルおよび必要に応じてアンカーノード設定更新トランザクションファイルを作成します(configtxgen ツールを使用)。

2)システムチャネルの初期設定ブロックファイルを使用して順序ノードを起動します。順序ノードが起動すると、自動的に指定された設定に従ってシステムチャネルを作成します。

3)異なる組織が事前に設定された役割に従って Peer ノードを起動します。この時点では、ネットワークにはアプリケーションチャネルが存在せず、Peer ノードもネットワークに参加していません。

4)新しく作成されたアプリケーションチャネルの設定更新トランザクションファイルを使用して、システムチャネルにトランザクションを送信し、新しいアプリケーションチャネルを作成します。

5)対応する Peer ノードを作成したアプリケーションチャネルに参加させます。この時点で Peer ノードはネットワークに参加し、トランザクションを受信する準備が整います。

6)ユーザーはクライアントを通じてネットワークに登録されたチェーンコードをインストールします(関連定義は後の 9.5 節を参照)。チェーンコードコンテナが正常に起動すると、ユーザーはチェーンコードを呼び出し、トランザクションをネットワークに送信できます。

後続の章では、各ステップの操作順序および方法を詳細に説明します。

実践的な能力が高い読者には、ローカルでコンパイルして Hyperledger Fabric ネットワークを展開することをお勧めします。これにより、関連コンポーネントについてより深く理解できます。

Hyperledger Fabric は Go 言語で実装されており、ローカルコンパイルには Golang 1.7 以上の環境を推奨します。以下では、fabric-peer、fabric-orderer、fabric-ca などのコンポーネントのバイナリファイルをコンパイル生成する方法と、いくつかの設定および開発関連ツールをインストールする方法を説明します。

一般的な Linux ディストリビューション(Ubuntu、Redhat、CentOS など)や MacOS などは、Fabric のコンパイルと実行をネイティブにサポートしています。

オペレーティングシステムは Linux カーネル 3.10 以上のバージョンを推奨し、64 ビット環境をサポートします。また、Fabric ノードとして、物理メモリは少なくとも 2GB を推奨します。チェーンコードが多い場合は、より多くのコンテナが必要です。ブロックファイルを保存するために十分なハードディスクスペースを確保してください(一般的には 20GB 以上を推奨)。生産環境でパフォーマンスと安定性が高く要求されるシナリオでは、さらに多くの物理リソースを確保する必要があります。

以下では、Ubuntu 16.04 オペレーティングシステムを例にして操作を行います。

ヒント:Fabric ノードに必要なリソースは厳しくなく、実験として Fabric ノードは Raspberry Pi 上でも正常に動作します。

. Go 言語環境のインストール

Go 言語環境は、golang.org ウェブサイトからバイナリ圧縮パッケージをダウンロードしてインストールできます。パッケージマネージャーを通じてインストールすることは推奨されません。バージョンが古くなることが多いです。

Go 1.8 バージョンをダウンロードする場合、以下のコマンドを使用できます。

$ curl -O https://storage.googleapis.com/golang/go1.8.linux-amd64.tar.gz

ダウンロードが完了したら、ディレクトリを解凍し、適切な場所に移動します(推奨は /usr/local です):

$ tar -xvf go1.8.linux-amd64.tar.gz
$ sudo mv go /usr/local

インストールが完了したら、GOPATH 環境変数を設定することを忘れないでください:

export GOPATH=YOUR_LOCAL_GO_PATH/Go
export PATH=$PATH:/usr/local/go/bin:$GOPATH/bin

この時点で、go version コマンドを使用してインストールが成功したかどうかを確認できます:

$ go version

go version go1.8 linux/amd64

2. 依存パッケージのインストール

Fabric 関連コードをコンパイルするには、いくつかの依存パッケージが必要です。以下のコマンドを使用してインストールできます:

以下のコマンドを使用して、fabric-peer および fabric-orderer コンポーネントのコンパイルに必要なコードを取得できます。現在、両者は同じリポジトリにあります。

$ git clone http://gerrit.hyperledger.org/r/fabric

Fabric ネットワークを起動することは比較的複雑なプロセスであり、主要な手順にはトポロジーの計画、関連設定ファイルの準備、Orderer ノードの起動、Peer ノードの起動、ネットワークの操作などが含まれます。ここでは、Fabric コードに付属するサンプルを基に関連する操作手順を説明します。

起動する Fabric ネットワークには、1 つの Orderer ノードと 4 つの Peer ノードが含まれ、管理ノードが関連する起動ファイルを生成します。ネットワークが起動した後、操作クライアントとしてコマンドを実行します。

4 つの Peer ノードは、同じ管理ドメイン(example.com)に属する 2 つの組織 Org1 と Org2 に分かれています。これらの組織は、同じアプリケーションチャネル(business-channel)に参加しています。各組織の最初のノード(peer0 ノード)はアンカーノードとして他の組織と通信し、すべてのノードはドメイン名を通じて相互にアクセスでき、全体のネットワークが構成されます。

Fabric ネットワークを起動する前に、起動に必要な設定ファイルを事前に生成する必要があります。これには、MSP 関連ファイル(msp/)、TLS 関連ファイル(tls/)、システムチャネル初期ブロック(orderer.genesis.block)、新しいアプリケーションチャネルトランザクションファイル(businesschannel.tx)、アンカーノード設定更新トランザクションファイル(Org1MSPanchors.tx および Org2MSPanchors.tx)などが含まれます。各ファイルの機能については、以下の小節で説明します。

注意:この小節では、これらの起動設定ファイルを生成する方法を主に説明します。これらの設定についての詳細な説明は、後の関連章を参照してください。

1. 組織関係と ID 証明書の生成

Fabric ネットワークはアライアンスチェーンサービスを提供しており、アライアンスは複数の組織で構成されています。組織内のメンバーは、ネットワークを維持するためにノードサービスを提供し、アイデンティティを通じて権限管理を行います。

したがって、最初に各組織とメンバーの関係を計画し、それぞれに対応する ID 証明書ファイルを生成し、対応するノードにデプロイする必要があります。

ユーザーは PKI サービス(fabric-ca を使用)または OpenSSL ツールを使用して、各エンティティの証明書と秘密鍵を手動で生成できます。しかし、組織構造が複雑な場合、この手動生成方式はエラーが発生しやすく、効率が低下します。

Fabric プロジェクトは、crypto 標準ライブラリに基づく cryptogen ツールを提供して、自動生成を実現しています。このプロセスは、まず crypto-config.yaml 設定ファイルに依存します。

crypto-config.yaml 設定ファイルの構造は非常にシンプルで、2 種類(OrdererOrgs と PeerOrgs)の複数の組織を定義できます。各組織内では、複数のノード(Spec)とユーザー(User)を定義できます。

以下は、OrdererOrgs タイプの組織 Orderer(1 つのノード orderer.example.com を含む)と、PeerOrgs タイプの組織 Org1 と Org2(それぞれ 2 つのノードと 1 つの一般ユーザーを含む)を定義した例の crypto-config.yaml 設定ファイルの内容です。

OrdererOrgs:
    - Name: Orderer
        Domain: example.com
        Specs:
            - Hostname: orderer
              CommonName: orderer.example.com
PeerOrgs:
    - Name: Org1
        Domain: org1.example.com
        Template:
            Count: 2
        Users:
            Count: 1
    - Name: Org2
        Domain: org2.example.com
        Template:
            Count: 2
        Users:
            Count: 1

この設定ファイルを使用して、以下のコマンドを実行することで、Fabric ネットワークに指定されたトポロジー構造の組織とアイデンティティファイルを生成し、crypto-config ディレクトリに保存できます。

$ cryptogen generate --config=./crypto-config.yaml --output ./crypto-config

crypto-config ディレクトリ構造を確認し、例の crypto-config.yaml に基づいて生成されていることを確認します。

$ tree -L 4 crypto-config
crypto-config
|-- ordererOrganizations
|   `-- example.com
|       |-- ca
|       |   |-- 293def0fc6d07aab625308a3499cd97f8ffccbf9e9769bf4107d6781f5e8072b_sk
|       |   `-- ca.example.com-cert.pem
|       |-- msp
|       |   |-- admincerts
|       |   |-- cacerts
|       |   `-- tlscacerts
|       |-- orderers
|       |   `-- orderer.example.com
|       |-- tlsca
|       |   |-- 2be5353baec06ca695f7c3b04ca0932912601a4411939bfcfd44af18274d5a65_sk
|       |   `-- tlsca.example.com-cert.pem
|       `-- users
|           `-- [email protected]
`-- peerOrganizations
    |-- org1.example.com
    |   |-- ca
    |   |   |-- 501c5f828f58dfa3f7ee844ea4cdd26318256c9b66369727afe8437c08370aee_sk
    |   |   `-- ca.org1.example.com-cert.pem
    |   |-- msp
    |   |   |-- admincerts
    |   |   |-- cacerts
    |   |   `-- tlscacerts
    |   |-- peers
    |   |   |-- peer0.org1.example.com
    |   |   `-- peer1.org1.example.com
    |   |-- tlsca
    |   |   |-- 592a08f84c99d6f083b3c5b9898b2ca4eb5fbb9d1e255f67df1fa14c123e4368_sk
    |   |   `-- tlsca.org1.example.com-cert.pem
    |   `-- users
    |       |-- [email protected]
    |       `-- [email protected]
    `-- org2.example.com
        |-- ca
        |   |-- 86d97f9eb601868611eab5dc7df88b1f6e91e129160651e683162b958a728162_sk
        |   `-- ca.org2.example.com-cert.pem
        |-- msp
        |   |-- admincerts
        |   |-- cacerts
        |   `-- tlscacerts
        |-- peers
        |   |-- peer0.org2.example.com
        |   `-- peer1.org2.example.com
        |-- tlsca
        |   |-- 4b87c416978970948dffadd0639a64a2b03bc89f910cb6d087583f210fb2929d_sk
        |   `-- tlsca.org2.example.com-cert.pem
        `-- users
            |-- [email protected]
            `-- [email protected]

crypto-config.yaml に基づいて生成された crypto-config ディレクトリには、多層のディレクトリ構造が含まれています。ordererOrganizations には Orderer 組織(1 つの Orderer ノード)のアイデンティティ情報が含まれ、peerOrganizations にはすべての Peer ノード組織(2 つの組織、4 つのノード)の関連アイデンティティ情報が含まれています。最も重要なのは、msp ディレクトリであり、エンティティのアイデンティティ情報を表します。

Orderer ノードの場合、crypto-config/ordererOrganizations/example.com/orderers/orderer.example.com ディレクトリ内の内容(msp および tls の 2 つのサブディレクトリを含む)を Orderer ノードの /etc/hyperledger/fabric パス(Orderer 自身の設定と一致)にコピーする必要があります。

Peer ノードの場合は、peerOrganizations 内の対応する ID 証明書ファイルをコピーする必要があります。org1 の peer0 を例にとると、crypto-config/peerOrganizations/org1.example.com/peers/peer0.org1.example.com ディレクトリ内の内容(msp および tls を含む)を Peer0 ノードの /etc/hyperledger/fabric(Peer 自身の設定と一致)パスにコピーする必要があります。

クライアントノードの場合、操作を簡単にするために、完全な crypto-config ディレクトリを /etc/hyperledger/fabric(configtx.yaml で設定したとおり)パスにコピーすることができます。

注意:現在、組織構造が一度生成されると、変更するには手動で証明書を調整する必要があるため、アライアンスの計画を事前に行う必要があります。将来的には、組織構造とノードのアイデンティティを動的にオンラインで調整することがサポートされる予定です。

2. Ordering サービスの初期ブロックの生成

Orderer ノードは起動時に、事前に生成された初期ブロックファイルをシステムチャネルの初期設定として使用するように指定できます。初期ブロックには Ordering サービスの関連設定情報とアライアンス情報が含まれています。初期ブロックは configtxgen ツールを使用して生成できます。生成プロセスは、/etc/hyperledger/fabric/configtx.yaml ファイルに依存します。configtx.yaml 設定ファイルは、ネットワーク全体の関連設定とトポロジー構造情報を定義しています。

configtx.yaml 設定ファイルの作成は、Fabric コード内のサンプル(examples/e2e_cli パスまたは sampleconfig パス)を参考にできます。ここでは、以下の内容を使用して生成します:

Profiles:
    TwoOrgsOrdererGenesis:
        Orderer:
            <<: *OrdererDefaults
            Organizations:
                - *OrdererOrg
        Consortiums:
            SampleConsortium:
                Organizations:
                    - *Org1
                    - *Org2
    TwoOrgsChannel:
        Consortium: SampleConsortium
        Application:
            <<: *ApplicationDefaults
            Organizations:
                - *Org1
                - *Org2
Organizations:
    - &OrdererOrg
        Name: OrdererOrg
        ID: OrdererMSP
        MSPDir: crypto-config/ordererOrganizations/example.com/msp
        BCCSP:
            Default: SW
            SW:
                Hash: SHA2
                Security: 256
                FileKeyStore:
                    KeyStore:
    - &Org1
        Name: Org1MSP
        ID: Org1MSP
        MSPDir: crypto-config/peerOrganizations/org1.example.com/msp
        BCCSP:
            Default: SW
            SW:
                Hash: SHA2
                Security: 256
                FileKeyStore:
                    KeyStore:
        AnchorPeers:
            - Host: peer0.org1.example.com
              Port: 7051
    - &Org2
        Name: Org2MSP
        ID: Org2MSP
        MSPDir: crypto-config/peerOrganizations/org2.example.com/msp
        BCCSP:
            Default: SW
            SW:
                Hash: SHA2
                Security: 256
                FileKeyStore:
                    KeyStore:
        AnchorPeers:
            - Host: peer0.org2.example.com
              Port: 7051
Orderer: &OrdererDefaults
    OrdererType: solo
    Addresses:
        - orderer.example.com:7050
    BatchTimeout: 2s
    BatchSize:
        MaxMessageCount: 10
        AbsoluteMaxBytes: 99 MB
        PreferredMaxBytes: 512 KB
    Kafka:
        Brokers:
            - 127.0.0.1:9092
    Organizations:
Application: &ApplicationDefaults
    Organizations:

この設定ファイルは、2 つのテンプレート(TwoOrgsOrdererGenesis と TwoOrgsChannel)を定義しており、前者は Ordering サービスの初期ブロックファイルを生成するために使用できます。以下のコマンドを使用して、configtx.yaml ファイルで定義された TwoOrgsOrdererGenesis テンプレートを指定し、Ordering サービスのシステムチャネルの初期ブロックファイルを生成します。ここでは、順序サービスのタイプとしてシンプルなソロモードを採用しています。生産環境では、Kafka クラスタサービスを使用できます。

読み込み中...
文章は、創作者によって署名され、ブロックチェーンに安全に保存されています。