Solenoid: インターネットコンピュータの分散型エッジ
- ICP Japan
- 1月5日
- 読了時間: 7分

この記事は「Solenoid: A Decentralized Edge for the Internet Computer」を引用翻訳しています。
バウンダリーノード(Boundary Nodes)は、インターネットコンピュータへのエントリーポイントです。すべてのユーザーリクエストは、ターゲットのカニスターに到達する前に、必ずバウンダリーノードを経由します。本記事では、新しいバウンダリーノードのアーキテクチャ、Solenoidマイルストーンの主要成果、そしてこの変更によって可能になる新機能について詳しく解説します。
インターネットコンピュータの郵便配達人
バウンダリーノードは、インターネットコンピュータの郵便配達人のような役割を果たします。クライアント(ユーザーやDapp)からのリクエストを受け取り、それを正しい宛先へ確実に届けるのがその仕事です。バウンダリーノードの役割を正しく理解するためには、まずインターネットコンピュータの基本構造を知ることが重要です。
インターネットコンピュータのコアは複数のサブネット(Subnets)に分割されており、それぞれのサブネットは複数のレプリカ(Replicas)で構成されています。インターネットコンピュータのスマートコントラクトであるカニスター(Canisters)は、これらのサブネット上にホストされます。クライアントがカニスターとやり取りする際、例えばICPレジャー上でトランザクションを実行する場合、リクエストは適切なサブネットのレプリカに送信される必要があります。
ここでバウンダリーノードが重要な役割を果たします。 クライアントは、どのバウンダリーノードにでもリクエストを送信できます。バウンダリーノードは、そのリクエストを適切なサブネットのレプリカへと転送し、確実に処理されるようにします。この仕組みにより、クライアントはインターネットコンピュータの内部構造を理解する必要がなくなります。
もしバウンダリーノードがなかった場合、クライアントは以下の問題に直面することになります。
どのサブネットにカニスターが存在するのかを把握する必要がある
そのサブネット内のどのレプリカが稼働しているかを特定する必要がある
リクエストを適切に処理できるレプリカを選択する必要がある
このような複雑な処理をすべてのクライアントが実装するのは現実的ではありません。バウンダリーノードがあることで、クライアントは単にバウンダリーノードにリクエストを送るだけで、適切なカニスターとやり取りできるようになります。
バウンダリーノードの機能
バウンダリーノードの役割は、単なるリクエストのルーティングにとどまりません。それ以上に、多くの重要な機能を果たしています。
パフォーマンス向上: キャッシュ機能を活用し、リクエスト処理の効率を向上させる
セキュリティ強化: 制限やセキュリティルールを適用し、インターネットコンピュータのコア部分を保護する
プロトコル変換: HTTPリクエストをインターネットコンピュータAPI(IC API)へ変換し、Webブラウザから直接カニスターへアクセスできるようにする
このブラウザからの直接アクセスは、インターネットコンピュータの特長の一つです。他のブロックチェーンでは、通常、Dappとスマートコントラクトのやり取りには追加のインフラ(中央集権的なWeb2サーバーやAPIゲートウェイ)が必要になりますが、インターネットコンピュータではカニスターがWebサーバーとして機能できるため、バウンダリーノードが直接クライアントとの橋渡しを行います。
分散化されたエッジインフラへ
これまでバウンダリーノードはDFINITY財団によって運用されていました。しかし、Solenoidロードマップのマイルストーン達成により、この構造が変わります。
インターネットコンピュータのエッジインフラは、完全に分散化されます。
この新しいエッジアーキテクチャにより、バウンダリーノードはより安全で、よりスケーラブルで、より分散化された形で運用されるようになります。これにより、インターネットコンピュータはさらにオープンで透明性のあるネットワークへと進化し、エコシステム全体の強化につながります。
従来のバウンダリーノードは単一のエンティティとして機能していましたが、新しいアーキテクチャでは以下の2つのコンポーネントに分割されました。それぞれ異なる役割を担います。
APIバウンダリーノード(API Boundary Nodes)
インターネットコンピュータの公開エッジとして機能し、IC APIエンドポイントを提供
HTTPゲートウェイ(HTTP Gateways)
APIバウンダリーノードの上位に位置し、HTTPリクエストを変換
ブラウザからのカニスターアクセスを可能にする翻訳レイヤーとして機能
また、ディスカバリーライブラリ(Discovery Library)が追加され、HTTPゲートウェイなどのICネイティブクライアントが適切なAPIバウンダリーノードを見つけ、接続できるようになりました。
APIバウンダリーノード: インターネットコンピュータの公開エッジ
APIバウンダリーノードは、クライアントのリクエストを適切なレプリカにルーティングする役割を持ちます。
このノードは、ICPのノードプロバイダーが運用するマシン上で動作し、レプリカノードと同様にNNS(ネットワーク神経系)によって完全に制御されます。ノードの追加・削除・アップグレードはすべてNNSの提案を通じて管理されるため、インターネットコンピュータの公開エッジは完全に分散化されました。
技術的詳細
APIバウンダリーノードの中核は ic-boundary サービスで構成
TLS終端、リクエスト解析、適切なレプリカへの転送を処理
クエリレスポンスのキャッシュ機能を搭載し、パフォーマンスとセキュリティを向上
レプリカノードとAPIバウンダリーノードは統一されたVMイメージを使用し、オーケストレーターが ic-replica(レプリカノード用)または ic-boundary(APIバウンダリーノード用)を起動
HTTPゲートウェイ: ブラウザアクセスの実現
HTTPゲートウェイは、HTTPリクエストをIC APIコールに変換し、APIバウンダリーノードに転送するレイヤーです。
この仕組みにより、ブラウザやその他のHTTPクライアントが直接カニスターと通信できるようになります。例えば、インターネットコンピュータの公式サイト(internetcomputer.org)は、追加ソフトウェアなしでブラウザからアクセス可能ですが、これはHTTPゲートウェイによるものです。
技術的詳細
HTTPゲートウェイの中核は ic-gateway サービスで構成
TLS終端、HTTPキャッシュ、HTTPリクエストのIC API変換、レスポンスのHTTP形式への変換を処理
さまざまなパッケージ形式で提供され、単一インスタンスとして実行することも、大規模なフリートとしてスケールすることも可能
ディスカバリーライブラリ: インターネットコンピュータへの接続を最適化
ディスカバリーライブラリは、HTTPゲートウェイのようなICネイティブクライアントが適切なAPIバウンダリーノードを発見し、接続するのを支援します。
このライブラリには、以下のようなルーティング戦略が組み込まれています。
単純な方法: ランダムにAPIバウンダリーノードを選択
高度な方法: ノードのヘルスチェックやレイテンシの監視を行い、最適なノードにルーティング
技術的詳細
ディスカバリーライブラリは agent-rs に統合されており、詳細なドキュメントが提供されている
アーキテクチャ移行の流れ
旧アーキテクチャから新アーキテクチャへの移行は、エンドユーザーにとってシームレスであることが目標です。一方で、開発者には新たなサービスを構築し、革新を進める機会を提供します。
DFINITY財団は引き続きHTTPゲートウェイを運用し、ic0.app、icp0.io、icp-api.io などのドメインを提供
開発者はディスカバリーライブラリを活用して、APIバウンダリーノードに直接接続することも可能
これにより、HTTPゲートウェイをバイパスし、新アーキテクチャの恩恵を最大限に活用できる
現在の状況
すべての主要コンポーネント(ic-boundary、ic-gateway、ディスカバリーライブラリ)は、すでに本番環境で広範囲にテストされ、稼働中です。
提案 #134902 の採択により、インターネットコンピュータの公開エッジには現在20のAPIバウンダリーノードが存在
DFINITY財団は複数のHTTPゲートウェイをテストと検証のために運用中
今後、従来のバウンダリーノードをHTTPゲートウェイへと段階的に置き換えるプロセスが進行中
この新しい分散型アーキテクチャにより、インターネットコンピュータのパフォーマンス、セキュリティ、柔軟性が向上し、完全に分散化されたエッジインフラが実現します。開発者にとっても、より効率的でスケーラブルなDapp開発が可能となり、ICPエコシステム全体の発展に寄与します。
Kommentare