この記事は、「コンテナ化と分散型インフラの未来」の2部構成のシリーズの第2回目です。第1回目の記事はこちらからご覧いただけます。

コンテナとSKALE EVM:SKALEネットワークチェーンの作成

バリデータノードは、ノードコアと最大128個の仮想化サブノードで構成されており、各サブノードはDockerコンテナです。新しい弾性サイドチェーンは、ネットワークへのAPIコールを介してSKALEネットワークに作成され、チェーンのサイズと様々なプロビジョニングオプションを指定し、ネットワークリソースのプロビジョニングを可能にするSKALEトークンのデポジットを提供します。各サイドチェーンには、デフォルトで16個のノードがあります。

SKALEのサイドチェーンのサイズは、スモール、ミディアム、ラージのいずれかになります。スモールチェーンにはノードリソースの1/128、ミディアムチェーンには1/8、ラージチェーンには(ノードコアとは別に)フルノードが割り当てられます。プロビジョニングの期間は6ヶ月、12ヶ月、24ヶ月のいずれかです。

トークンがネットワークにデポジットされチェーンが作成されると、SKALEマネージャはチェーンを処理するのに十分な容量を保持する利用可能なノードプールから16個のノードをランダムに選択します。このプロセスの一部として、コントラクトは各ノードにメッセージを送信し、新しいチェーンのために適切なサブノードを作成します。

この方法では、SKALEマネージャがノード内のSKALE Adminプラグインに接続し、Docker Engineに対してSKALE EVMイメージを起動してチェーンに適切な量のリソースを割り当てるように指示します。

分散型ホテル予約システムと類似

プロセスの確認方法は、ホテルチェーンの予約システムを介して複数の場所にある部屋を予約することに類似しています。予約システムは、ネットワーク全体の空室状況をグローバルに把握しているため、各ロケーションの空室状況を確認することができます。そのため、様々なリクエストに対して対応可能なロケーションを判断することができます。空室状況が確認されると、各ホテルの部屋を予約するためのリクエストを送信することができます。それは、各ホテルの責任において、チェックイン時に部屋が利用可能な状態で提供されていることを確認します。

ここでの相違は、割り当てと選択がEthereumメインネット上で実行されるスマートコントラクトを介してノードプール全体にわたってランダムに実行されることです。さらに、サブノードのプロビジョニングは、各ノード(SKALE Admin経由)への呼び出しを介して行われ、サブノードコンテナを作成し、それを適切なサイズでプロビジョニングします。

SCALE EVMイメージ

仮想化されたサブノードは、基本的にノードサイズ(スモール - 1/128、ミディアム - 1/8、ラージ - 1/1)に応じてノードリソースの特定の割り当てで動作するSKALE Ethereum仮想マシン(EVM)で構成されています。SKALEネットワークが使用しているEVMの実装はETH1 EVMバージョン(Github)です(以前は、cpp-ethereumプロジェクトと呼ばれていた点に注意)。
“Ethereumクライアント「ethereum/aleth」をはじめとするEthereum用のC++ライブラリやツールを集めたものです”

SKALE EVMと標準ETH1 EVMの唯一の違いは、標準EVMのコンセンサスアルゴリズムがプルーフ・オブ・ワークアルゴリズムからABBAベースのプルーフ・オブ・ステークアルゴリズムに変更されたことです(ABBAはAsynchronous Binary Byzantine Agreementの略です)。

注目すべきは、EVM内の他の要素にはコンセンサスアルゴリズムが疎結合されているため、異なるアルゴリズム(ここのケースでは、より高性能なプルーフ・オブ・ステークアルゴリズム)にスワップしても、Ethereumネットワークを現在の信頼できるネットワークにしたすべてのセキュリティ及び暗号化手段を維持できるということです(SKALE設計では、ある特性を満たしていれば、他のコンセンサスアルゴリズムを含めることも可能であり、SKALEチェーンはこの分野で前例のない柔軟性と適応性を有しています)。

コンテナベースのアプローチにより、SKALEネットワークはEVMの新バージョンが利用可能になったときに、簡単かつ安全にサポートすることができます。EVMのアップデートはそれほど頻繁に行われるものではありませんが、アップデートが行われた際には、メインネットを比較的迅速に変更したいという要望が表明されています。Solidity言語はEVMにコンパイルされているため、Solidityへの変更はEVMの次回のアップグレードに反映されます。

dAppsが最新バージョンのEVMを利用することで利便性は高まりますが、Dockerやコンテナを使用してSKALEネットワーク内で古いバージョンのEVMを実行することも可能です(その方法に関する質問は、SKALEネットワークサポートチームにお問い合わせください)。

ランダムノード選択と頻繁なノードによるネットワークセキュリティ

従来のサイドチェーンでは、少数のバリデータノードを使用することでパフォーマンスと低レイテンシを実現していましたが、トランザクションの整合性を損なう可能性がありました(ノードのセットが小さいほど共謀や贈収賄の影響を受けやすいという理論に基づいています)。SKALEネットワークは、プールされた検証モデルを使用することで、このセキュリティリスクに対抗しています。このモデルは、ランダムなノード割り当てとバリデータセット間の頻繁なノードローテーションを組み合わせることで、多数のバリデータノードが提供するセキュリティ上の利点を活用しています。したがって、各独立したサイドチェーンは、ネットワーク全体のリソースで保護されます。

バリデータノードは、Ethereumメインネットコントラクトによって調停されるランダムなプロセスを介して弾性サイドチェーンに割り当てられます。チェーンのコンセンサスセキュリティは、頻繁なノードローテーションによってさらに保護されています。ノードは非決定性スケジュールで1つまたは複数のチェーンから削除され、新しいノードが追加されます。

コンテナの使用は、ノードのローテーションにも大きな役割を果たします。このノードのローテーションは、サイドチェーンが稼働している間に行われため、飛行中の飛行機のジェットエンジンを交換するほど複雑ではないかもしれませんが、現在のサブノードと新しいサブノードの間で計画と協力が必要になります。

SKALEマネージャによって割り当てられると、新しいノードがサブノード(すなわちSKALE EVMコンテナ)としてセットアップされます。Linuxのbtrfsスナップショットが現在のサブノードのサブボリュームストレージから取得され、新しいサブノードに送信されてマウントされます。このプロセスの間、チェーンは実行中であり、新しいブロックを作成しているため、ノードを完全に同期させるには、いくつかのキャッチアップ手順が必要になります。これが完了すると、新しいサブノードがバリデータセット内の古いノードの代わりになり、トランザクションは古いノードではなく、この新しいノードに送信されます。

ホッケーゲームでの選手交代に類似

SKALEネットワークのサイドチェーンにおけるバリデータのローテーションを確認する方法として、ホッケー試合の選手交代が類似しています。タイムアウトの代わりに、1人の選手をオフし、別の選手をオンにして交代します。ここでの違いは、新しいサブノードは置換されたサブノードの正確なクローンであるということです。さらに、この新しいサブノードは利用可能なノードのプールの中からランダムに選択されます。


コンテナ(および仮想サブノード)のケースはクリア

柔軟で仮想化されたサブノード構造を作成する方法としてコンテナを使用するという決定は、クラウドコンピューティングや従来の仮想化システムで見られる成長と結果を考慮すると、それほど驚くべきことではありません。驚くべきは、分散型ネットワーク内でコンテナが提供する多くの利点と将来の可能性です。

これらの利点は、SKALEネットワークの開発チームおよびネットワークサポートチームがサイドチェーンを次々に立ち上げ、コンポーザビリティ、アジリティ、アダプタビリティがいかに弾性サイドチェーンの構築、開発、使用を容易にしているかを確認する際に、より認知されるようになっていきました。コンテナの使用は、SKALEネットワークのロールアウトに対する深刻な問題点に対処しており、大きな問題点やオーバーヘッドを発生させることはありませんでした。これにより、新機能を追加するだけでなく、コアチームの開発と革新を迅速に行う能力が向上しました。

しかし、同様に重要なのは、コンテナを使用することで、SKALEネットワークが確立しているサービス保証を維持し、さらには上回ることができるということです。何千ものサイドチェーンをローンチし、何万もの仮想化されたサブノードを生成し、ローテーションさせた後のコンテナのケースはクリアです。これはSKALEネットワークの基盤となる重要なテクノロジーです。安全性とパフォーマンスの高いネットワークを今すぐ構築し、今後数年、数十年のうちにネットワークの機能や特徴を向上させるための手段として役立つでしょう。

参照先