Symbol comes with improved extensibility through its plugin-based architecture.
プラグイン は Symbol の機能を拡張するためにプロトコルに追加できる自己完結型の機能グループです。プラグインアプローチにより開発者はコアエンジンを変更したり、他の機能を中断したりせずに、トランザクションを介してチェーンの状態を変更するさまざまな方法を導入できます。
Symbol では、各基本 トランザクションタイプ がプラグインとして分離して定義されています。この分離によって、ネットワーク要件を満たすために機能の最小サブセットのみをロードすることが可能になります。
Symbol の最も単純な形式のプラグインは C++ で記述されたファイルで PluginManager を登録し、単一のエントリポイントを公開します。 catapult-client がプラグインを動的にリンクできるように、ファイルは次の形式に一致する必要があります。
#pragma once
#include "catapult/plugins.h"
namespace catapult { namespace plugins { class PluginManager; } }
namespace catapult { namespace plugins {
/// Registers transfer support with \a manager.
PLUGIN_API
void RegisterTransferSubsystem(PluginManager& manager);
}}
プラグイン関連のすべてのファイルは plugins ディレクトリ以下の同じフォルダに保存して、コードを整頓しています。このフォルダにはプラグインのビルド方法をコンパイラに指示するファイル CMakeLists.txt も含まれます。
cmake_minimum_required(VERSION 3.14)
set(PLUGIN_BASE_NAME catapult.plugins.mosaic)
catapult_tx_plugin_src(${PLUGIN_BASE_NAME})
プラグインはコードを整理しておくために、次のサブモジュールを内部で定義する場合があります:
サブモジュール |
説明 |
|---|---|
|
バイナリとの間でモデルタイプをシリアル化および逆シリアル化するためのキャッシュタイプとルール。 |
|
キーと値のペアをセットとして定義している構成可能なパラメータ。各パラメータの値はネットワーク設定ファイル |
|
トランザクションタイプとそれらタイプ解析ルールへのマッピング。具体的には、プラグインはトランザクションを後続の処理で使用されるコンポーネント通知に変換するためのルールを定義します。 |
|
オブザーバは、ブロックおよびトランザクション処理によって生成された通知を処理します。登録されたオブザーバは、一般通知またはプラグイン定義の通知を購読し、その値に基づいてブロックチェーンの状態を更新できます。オブザーバは適用可能なすべてのバリデータが成功した後にのみ呼び出されるため、検証ロジックを必要としません。 |
|
コアエンジンがプラグインをロードするための手順。このサブモジュールには |
|
ステートレスおよびステートフルのバリデータは、ブロックおよびトランザクション処理によって生成された通知を処理します。登録されたバリデータは、一般的な通知またはプラグイン定義の通知を購読し、許可されていない値または状態の変更を拒否できます。 |
プラグインで定義したコードは、ネットワークが停止するか、すべてのネットワークノードがプラグインを無効にする新しい構成を使用することを決定しない限り、永久に実行されます。ノードのサブセットが構成変更を採用しない場合、チェーンは 2 つに分割されます。
カスタムロジックを作成する前に、開発者は Symbol がデフォルトで 提供されるトランザクション を使用して、ユースケースを解決するようにしてください。 Symbol の基本プラグインは監査済みです。プラットフォームは一般公開前に大規模なテストネット期間を実行しており、そのコードは2018 年4月からオープンソースになっています。
新しいプラグインを作成する場合、カスタムコードの脆弱性を最小限に抑えるために、本番環境でネットワークを起動する前に、コードを広範囲にテストし、外部監査人を参加させて、テストネット期間を実施することを推奨します。
