Catapult

Catapult

Symbol の各 ノード の中核を担うソフトウェアクライアントのリファレンス実装。 トランザクション と ブロック の検証、 コンセンサス アルゴリズムの実行、新しいブロックの生成、 そしてネットワーク全体への変更の伝播を行う。

Symbol はエコシステムおよび公開ネットワークを指し、 Catapult はそのネットワークの挙動を定義するソフトウェアを指す。 Symbol のすべてのノードは Catapult を中核で実行しており、 同一の決定論的ロジックを用いてブロックチェーンの状態に合意する。

Catapult は初代 NEM（NIS1）クライアントの後継として設計され、 モノリシック構造の制約を解消した。 C++ で書かれた新しいモジュラーアーキテクチャを採用し、 パフォーマンス、柔軟性、拡張性を重視している。 NIS1 がブロックチェーンのすべてのロジックを単一の Java コードベースにまとめていたのに対し、 Catapult は モザイク、ネームスペース、 マルチシグアカウント などの各機能を独立したプラグインとして分離している。

この設計により、基盤となるコンセンサスエンジンを変更せずにプロトコルを進化させることができ、 パブリックおよびプライベートの両方のネットワークが同じ基盤を共有できる。 したがって Catapult は Symbol の技術的な中枢であり、 構成とプラグインの組み合わせによって複数のネットワークを駆動できる 汎用ブロックチェーンエンジンとして機能する。

設計原則

Catapult はモジュール性、パフォーマンス、信頼性に重点を置いて設計された。 このアーキテクチャにより、ネットワークはコンセンサスの中核を変更することなく進化でき、 すべてのノードが効率的にデータを処理できるようになっている。

設計を導く主な原則は次のとおり。

• モジュール性： モザイク から マルチシグアカウント まで、 すべての機能は独立して追加・更新できるプラグインとして実装されている。

• パフォーマンス： コアロジックは C++ で記述され、並列処理と低レイテンシ処理に最適化されている。

• 拡張性： コンセンサスロジックを再実装せずに、新しいトランザクションタイプや機能を追加できる。

• 設定可能性： ブロック時間、インフレーション、インポータンス重みなどのチェーンパラメータは 設定ファイルで定義される。

• 関心の分離： Catapult エンジンはプロトコル実行のみに集中し、 REST ゲートウェイ、SDK、 および データベース が外部アクセスとデータインデックス化を担当する。

ノード内での役割

Catapult は各 Symbol ノードの中心となるプロセスであり、 ブロックチェーンの状態を維持し、トランザクションを検証し、 プロトコルルールを適用する。 他のコンポーネントはネットワークデータの公開や新規トランザクションの受け付けのために Catapult と連携するが、 状態の変更を決定する唯一の権威は Catapult 自身である。

Catapult は以下の要素と連携する。

• REST ゲートウェイ： ブロックチェーンデータへの HTTP アクセスとトランザクション送信を提供する。

• データベース： ブロックチェーンの状態を保存し、高速なクエリを実現する。

• ピアノード： Symbol プロトコルを実装する他ノードと通信し、コンセンサス に参加する。

一般的なアプリケーションでは、Catapult と直接通信する必要はない。 通常は REST ゲートウェイ を通じて、 もしくは SDK 経由でやり取りを行う。

プラグインモデル

Catapult はチューリング完全なスマートコントラクトシステムではなく、 プラグインおよび拡張アーキテクチャを中心に設計されている。 このアプローチにより、ブロックチェーン上で実行可能な操作を定義済みの範囲に制限し、 攻撃対象領域を減らしつつ、性能の最適化を容易にしている。

Catapult では２種類の拡張メカニズムが用意されている。

• プラグイン： ネットワークがサポートするトランザクションタイプを定義する。

  同一ネットワーク上のすべてのノードは、 同一のトランザクションプラグインセットをロードし、同一の方法で処理する必要がある。 これにより、すべてのノードがブロックチェーンの状態に合意できる。

  これらのプラグインはネットワーク設定ファイルに記述されており、 セット内容を変更する場合はノード間での調整が必要となる。 差異があると フォーク が発生するためである。

  Symbol に組み込まれているすべてのトランザクションタイプ （転送トランザクション、モザイク、 ネームスペース、アグリゲートトランザクション など）は、 すべてプラグインとして実装されている。

• 拡張機能： ノードごとに異なる構成を取ることができる任意コンポーネント。

  コンセンサスに影響しない追加機能を提供し、 例えばデータベースへの保存や外部システムへのイベント通知などを行う。

  拡張機能はノード単位で設定され、ネットワーク互換性を損なうことなく ノードの動作をカスタマイズできる。

拡張性と設定

Catapult は、Symbol のパブリックブロックチェーンからプライベート・コンソーシアム型ネットワークまで、 様々なネットワークを駆動できる。 その挙動はほぼすべて設定ファイルによって定義され、 ネットワークパラメータおよびノードレベルのオプションが指定される。

• ネットワーク設定： チェーン上のすべてのノードに共通する動作を定義する。

  ブロック時間、インポータンス重み、ハーベスティング報酬、 ネットワークがサポートするトランザクションプラグインのセットなどを定義する。

  ノード同士が互換性を保つためには、同一のネットワーク設定を使用する必要がある。

• ノード設定： ノードごとに異なるオプション動作を定義する。

  読み込む拡張機能、データベースやログ設定、外部サービスとの接続などを含む。 これらの設定はコンセンサスに影響しないため、 各ノードが独自にカスタマイズできる。

この階層的な構成により、Symbol はネットワーク全体で一貫したプロトコルを維持しつつ、 各ノードが特化・最適化・外部統合を自由に行えるようになっている。

Symbol ネットワーク設定

パブリック Symbol ネットワーク（メインネット）は、Catapult の特定のデプロイメントの１つである。 ネットワークパラメータやプラグイン定義を含む設定ファイルは、 symbol/networks リポジトリで公開されている。

発展と継承

Catapult は NEM ブロックチェーンの次世代実装として開発され、 当初は NEM 2.0 と呼ばれていた。 その目的は、初代 NEM クライアント（NIS1）の モノリシックな Java ベース構造が抱えていた拡張性の課題を克服することだった。

新しい実装は C++ で記述され、コンセンサス、トランザクションロジック、 拡張機能を独立したコンポーネントとして分離するモジュラー設計を導入した。 この分離により、パフォーマンス、スケーラビリティ、保守性が向上し、 同一のコアエンジンでパブリック・プライベート両方のネットワークを支えられるようになった。

Catapult はさらに、アグリゲートトランザクション、 多層構造を持つ マルチシグアカウント、 より効率的な モザイク および ネームスペース 管理など、 プロトコルレベルでの重要な革新を導入した。 これらの機能が、Catapult エンジンを実運用に導入した最初のパブリックネットワークである Symbol の基盤となっている。