- 背景 -

現在、ブロックチェーンとクロスチェーンプラットフォームのアクセス方法はアーキテクチャ設計の点で大きく異なっており、アプリケーションチェーンをいかに迅速かつ便利にクロスチェーンシステムに接続するかが喫緊の課題となっている。 BitXHubのBitXHubクロスチェーンサービスプラットフォームは、リレーチェーン+ゲートウェイのクロスチェーンソリューションを採用しており、クロスチェーンゲートウェイはブロックチェーン間のトランザクションを収集および配布する役割を果たします。プラグイン メカニズムの設計により、ゲートウェイ (Pier) とアプリケーション チェーンの間で対話するモジュールが、クロスチェーン ゲートウェイのコア機能モジュールから分離されるため、さまざまな種類のアプリケーション チェーンをクロスチェーン ゲートウェイに効率的に接続できます。チェーンシステム。 Pier の実行中、プラグインを動的にロードすることで、さまざまなアプリケーション チェーンの柔軟な適応が完了します。 Pier とアプリケーション チェーン間の相互作用をより強化するために、特定のアプリケーション チェーン プラグインは、さまざまなブロックチェーンの特性に従って特定のインターフェイスを実装する必要があり、相互作用インターフェイスは次の機能を満たす必要があります。

1) アプリケーションチェーン上のクロスチェーンイベントを監視し、それらを処理のためにコアモジュールに渡します。

2) ゲートウェイ (他のアプリケーション チェーンから) からクロスチェーン リクエストを実行します。

3) アプリケーション チェーン上で受信および実行されたクロスチェーン リクエストのステータスをアクティブにクエリする機能。

プラグイン実装スキームの設計では、2 つの異なるプラグイン機構を連続して採用しましたが、ネイティブ プラグインを使用する際に遭遇した問題点と、新しいプラグイン ソリューションの利点を紹介します。

—— ネイティブプラグイン——

go言語はバージョン1.13からプラグインとしてコンパイルに対応しており、使い方は以下の通りです

• go build --buildmode=plugin -o appchain.so *.go

go プロジェクトは、コンパイル時に --buildmode を通じてプラグイン モードとして指定でき、この方法で出力はダイナミック リンク ファイルになります。このファイルは直接実行できるバイナリ ファイルではなく、他のバイナリ ランタイムに提供される動的呼び出しです。

メインバイナリで次のように使用されます。

アドバンテージ：

アドバンテージ：

1) コード モジュールのバイナリ化と同様に、ユーザー エクスペリエンスはネイティブ コードと一致します。

欠点:

欠点:

1) ネイティブ プラグインの依存ライブラリは、メイン プログラムと完全に一致している必要があります。そうでない場合は、起動時にエラーが報告され、依存関係が直接参照されているか間接参照されているかに関係なく、この問題が発生します。

—— RPC プラグインに切り替える ——

ネイティブ プラグインの厳格なバージョン制限により、プラグインやゲートウェイのメイン プログラム機能をアップグレードするときに、メイン プログラムの一部の依存関係が意図せずアップグレードされる可能性があり、プラグインも同様の適応を行う必要があります。アップグレードします。この方法はプラグインの完全な分離には役立たないため、RPC を使用する別の GO プラグイン プロジェクトに目を向けました。 (プロジェクトのGitHubアドレス: https://github.com/bashicorp/go-plugin)

Hashicorp の go プラグインは、GO のネイティブ プラグイン メカニズムが登場する前からすでに存在していましたが、GO のネイティブ プラグインが登場した後も、プロジェクトへのサポートを放棄しませんでした。非常に完璧です。シナリオによっては、go-plugin の方が便利です。

go-plugin プラグインは次のように使用します。

go-plugin プロジェクトで実装されるプラグイン方式は、簡単に言うと C/S モードを採用しており、メインプログラムが RPC クライアントとして使用され、特定のプラグインが RPC サーバーとして使用されます。クライアントもインターフェース仕様に基づいています。

具体的な利用の流れは以下の通りです。

1) 抽象化にはプラグイン インターフェイスが必要ですが、ここではネイティブ プラグインで使用されるインターフェイス定義を直接再利用できます。

2) クライアントとサーバーの両方が上記のインターフェイスを実装します。サーバー側の実装は、特定のプラグイン処理ロジックのコードです。クライアント側の実装は、gRPC の処理結果と例外情報をカプセル化するだけでよく、メイン プログラムは、プラグイン。

サーバー実装部分:

クライアント実装部分:

▲さらに次の点に注意してください。

• プラグインは、plugin.Serve を呼び出して、メイン プログラムが独自の RPC サービスを使用することを承認する必要があります。ここで注意すべき点は、メインプログラムとプラグインが通信する前に、主にプラグインのバージョン情報の確認を含むハンドシェイクが必要であることです。

• メイン プログラムは、plugin.Client オブジェクトを使用してプラグインを起動します。プラグインは別のプロセスで実行されるため、プラグインのクラッシュはメイン プログラムには影響しません。

• クライアントとサーバーは、使用中に実際にはプロセス間ソケットを介して通信します。これにより、パフォーマンスはある程度犠牲になりますが、ネイティブ プラグインの単一プロセス ソリューションにはない、依存関係の分離や多言語サポートなどの柔軟なアプリケーションが導入されます。にはありません。

- 結論 -

著者について

著者について

FunChain テクノロジー データグリッド ラボ BitXHub チーム

FunChain テクノロジー データグリッド ラボ BitXHub チーム