ノード⚓︎
ノードはブロックチェーンの中核を成し、十分な数のノードが稼働している限りネットワークが機能し続けることを保証する。
ブロック生成に参加するためには、各ノードはハーベスタの アカウント に関連付けられている必要がある。 このアカウントがノードによって生成されたブロックに署名する。 運用コストを補うために、ハーベスティング による XYM の報酬は、 ノード運営者が指定した 1 つまたは複数のアカウントに送ることができる。
Symbol ノードはいくつものソフトウェアコンポーネントで構成されており、 それぞれを個別に有効化および設定できる。 この柔軟性により、ハードウェア要件の異なる多様な構成を実現できる。
最も一般的な構成は「ロール」と呼ばれ、以下で説明する。
ノード構造⚓︎
Catapult⚓︎
Catapult クライアントは他のノードと 後述するピアツーピア通信 で直接通信する。 パフォーマンス上の理由から、 ブロックデータベース と ブロックチェーン状態データベース を分離して保持している。
また、REST ゲートウェイ からの基本的な問い合わせ （ノードの公開キー、ピアリスト、ネットワーク設定、時刻など）にも応答できる。
状態データベース⚓︎
Catapult は RocksDB というキー・バリュー型データベースを使用して、 ブロックチェーンの現在の状態を保持している。 ここにはアカウント残高、アクティブなモザイク、ネームスペースなどが含まれる。
ブロックデータベース⚓︎
すべての ブロック はプレーンファイルとしてディスク上に保存され、 レシート、未承認トランザクションプール、 そして完了待ちの ボンデッドアグリゲートトランザクション も同様に保存される。
REST ゲートウェイ⚓︎
外部クライアント（アプリやウォレットなど）がブロックチェーンとやり取りするための HTTP API を提供する。
多くの問い合わせは、ブロックや状態、未処理トランザクションを保存している 自身の フルデータベース から直接応答される。 ノード自体やネットワークに関する問い合わせは Catapult エンジンへ転送される。
REST ゲートウェイは WebSocket 接続もサポートしており、 アプリケーションが更新をポーリングする代わりに、 イベント発生時に即座に通知を受け取ることができる。
これらのイベントは ZeroMQ によりゲートウェイに送信され、 そこから購読者へ転送される。
ブローカー⚓︎
このコンポーネントは、ブロックデータベース からの更新を REST ゲートウェイ が使用する フルデータベース にコピーする。
有効化されている場合、Catapult はスプーラーを使用して、 ブロックデータベースの変更を非同期的にブローカーへ通知する。 この分離により、インデックス作成やデータベース書き込みが Catapult の時間に敏感な処理を妨げないようになっている。
変更が検出されるとすぐに、ブローカーは ZeroMQ 経由で REST ゲートウェイにも通知し、 購読中のアプリケーションがタイムリーに更新を受け取れるようにする。
Zero MQ⚓︎
ZeroMQ は、 ブローカー から REST ゲートウェイ へ、 さらに最終的には購読アプリケーションへリアルタイムでイベントや状態変化を送信するためのメッセージングシステム。
通常の HTTP リクエストとは異なり、ZeroMQ はプッシュ型通信を実現する。 これによりクライアントはポーリングすることなく、 新しいブロック、承認済みトランザクション、アカウント状態の変更などのイベントを即座に受け取れる。
フルデータベース⚓︎
Catapult の ブロックデータベース と 状態データベース は高スループットに最適化されている。
並行して、ノードはこのデータのレプリカを MongoDB に保持し、 REST ゲートウェイ が受け取る複雑な問い合わせを効率的に処理できるようにしている。
フルデータベース への書き込みを行うのは ブローカー のみであり、 ブロックチェーンの基礎データと同期を保っている。
ロール⚓︎
Symbol ノードは高度に設定可能で、有効化されるコンポーネントによってさまざまなロールを担うことができる。
各ロールでは、有効なコンポーネントに応じてハードウェア要件が異なる。
ピアノード⚓︎
- ピアノード
- ピアノードは新しいブロックを生成し、受信したトランザクションとブロックを検証して、 それらを隣接ノードへ中継することでネットワークのコンセンサスプロセスに参加する。
ピアノードは受信データを独立して検証したうえで転送し、ネットワークの整合性を保つ。
このロールでは Catapult エンジンとその関連データベースのみを実行すればよい。
ピアノードは他のノードとだけ通信し、外部 API は公開しない。 ただし API ロールも兼ねる場合は例外となる。
API ノード⚓︎
このロールでは ノード構造 で説明したすべてのコンポーネントを有効化する必要がある。 すべての API ノードはピアノードでもある。
また、ボンデッドアグリゲートトランザクション を保存し、 トランザクションが完了して処理可能になるまで連署を収集する。
投票ノード⚓︎
投票ノードはピアノードまたは API ノードのどちらでもあり得る。つまり API を公開していても公開していなくてもよい。
デュアルノード⚓︎
ライト API ノード⚓︎
- ライト API ノード
- Catapult の限定的な HTTP API が公開されているノードを「ライト API ノード」と呼ぶ。
この API はノードおよびネットワークに関する基本的な問い合わせにのみ応答でき、 フル API ノード よりもはるかに少ないリソースで動作する。
このインターフェイスを公開することで、 クライアントがノードの公開キーを取得できるようになり、 デリゲートハーベスティング が可能となる。
ライト API ノードで利用できる API エンドポイントは以下の通り：
ピアツーピア通信⚓︎
Symbol ノードは分散型のピアツーピア方式で直接通信を行う。 中央の調整者は存在せず、各ノードは他のノードの一部と接続して分散ネットワークを形成する。
ノードは既知のピアリストを共有し、 新しく接続したノードが他のノードをすばやく発見してネットワークに統合できるようにする。 この仕組みにより、個々のノードがオフラインになってもネットワーク全体の接続性と耐障害性が維持される。
起動を容易にするため、Catapult には初期ピアリストが同梱されている。 これにより新しいノードは最初の接続を確立し、他のノードを探索し始めることができる。 ただし、このリストに載っているノードが特別扱いされることはない。 一度接続されると、すべてのピアはプロトコル上平等に扱われる。
ノードの評価（レピュテーション）⚓︎
Symbol のような分散システムでは、ノードはどのピアを信頼し接続を維持するかを自律的に判断しなければならない。 固定されたホワイトリストや手動で管理された接続に依存する代わりに、 Symbol ノードは「レピュテーション」システムを使用して、観測された挙動に基づきピアを動的に評価・順位付けする。
各ノードは通信成功率、応答時間、受信データの正当性などの指標をもとに独自に評価を算出する。 正常に動作し一貫して応答するノードは高いスコアを得る。 無効なデータを送信したり、応答しなかったり、不正な挙動を示したノードは減点または一時的にブラックリスト化される。
新しい接続を確立する際、ノードは過去のやり取りに基づく評価の高いピアを優先的に選択する。
レピュテーションスコアはローカルであり、各ノードが自身の直接的な経験のみに基づいて保持する点に注意。
ノードのローテーション
孤立したり停滞したノード群の形成を防ぐため、 Symbol ノードは定期的に最も長く接続されている一部のピアとの接続を切断する。 これは、そのピアが高評価であっても行われる。
この強制的な入れ替えにより、ノードは継続的に新しいピアを発見・評価し、 接続性と適応性の高いネットワークトポロジーを維持する。
レピュテーションに基づく安定性と意図的な接続更新のバランスを取ることで、 プロトコルはネットワークの分断を防ぎ、長期的な分散性を促進している。
最後に、このレピュテーションスコアはノードが他ノードへの接続可否を判断するための内部指標である。 ハーベスティング の際、アカウントは任意のノードへ残高を委任でき、 その際に考慮される評価要素は、このページで説明したスコアと一致するとは限らない。