ADAMANTの開発は、ノード運用者、コントリビュータ、アプリケーション開発者にとってより簡単かつ迅速になりました。公開されているADAMANT Testnetに加えて、開発者は現在、自身のマシン上で軽量なローカルADAMANTネットワークを直接実行できます。このLocalnet構成は、公開ネットワークや重いインフラを必要としない、迅速な実験、自動チェック、シナリオテスト、開発ワークフロー向けに設計されています。同時に、ADAMANT Nodeは柔軟な設定オーバーライドをサポートするようになり、運用者やテスト自動化スクリプトはconfig.jsonやtest/config.jsonを手動で編集することなく、起動時にノード設定を変更できるようになりました。
TestnetからLocalnetへ
Testnetは、開発者に実際のネットワーク条件により近い共有の公開環境を提供するため、引き続き重要です。統合のテスト、アプリケーションの動作確認、ノード互換性の検証、Mainnetへの導入前の機能実験などに有用です。しかし、すべての開発タスクが公開ネットワークを必要とするわけではありません。開発者の中には、より小規模で高速な環境が必要な場合があります。たとえば、ローカルで複数のノードを起動して、コンセンサス関連の変更をテストしたり、ピア発見や同期を確認したり、バグを再現したり、自動化されたシナリオテストを実行したり、プルリクエストを開く前にノードの動作を検証したりする場合です。このような用途にLocalnetが適しています。
ADAMANT Localnetとは？
ADAMANT Localnetは、単一のマシン上で実行される、管理されたローカルのマルチノードADAMANTネットワークです。公開Testnetノードに接続する代わりに、Localnetはローカルに複数の独立したADAMANTノードを起動します。各ノードは、独自のポート、ランタイム状態、ログ、設定、プロセスメタデータ、データベース設定を持ちます。
基本的なワークフローはシンプルです：
npm run start:localnet -- --nodes 3
npm run status:localnet
npm run stop:localnet完全なクリーンアップが必要な場合は、npm run drop:localnetを実行するか、npm run stop:localnet -- --dropOnStopを使用して永続化されたローカルデータベースを削除できます。
Localnetは意図的に軽量です。公開サーバー、VPS、ネットワークからの長時間の同期を必要としません。ローカルで実行され、制御されたテスト設定を使用し、開発用マシンに適しています。これにより、変更を提出する前にノードの変更をテストするコントリビュータ、迅速なリリースチェックを必要とするメンテナ、ADAMANT API上にアプリケーションを構築する開発者、自動化スクリプトやCIに類似した環境にとって有用です。
Localnetが内部で作成するもの
Localnetが起動すると、各ノードの分離されたランタイムデータが生成されます。これには、ノードごとの設定ファイル、ランタイム状態、PIDファイル、マニフェスト、ローカルチェーンデータ、ノードごとのログフォルダが含まれます。ログはノードごとに分離され、たとえばlogs-localnet/node-1/、logs-localnet/node-2/などに配置されます。これは、マルチノードの問題をデバッグする際に、異なるピア間の動作を比較する必要があるため重要です。伝播の問題、再接続、ブロックの欠落、スプリットブレイン状態、フォージングの動作、ブロードハッシュコンセンサスなどでは、単一のログファイルでは不十分です。Localnetのツール群は、後でシナリオテストツールが利用可能な、機械可読なメタデータも生成します。
ステータススクリプトは、APIステータス、デリゲート数、最終フォージング時刻、nethash、ライブブロードハッシュコンセンサスなど、ノードごとの情報を報告します。ブロードハッシュコンセンサスは、起動後にローカルノードが実際に互いに一致しているかを確認するのに特に有用です。ローカルのスモークテストでは、3ノードのLocalnetを起動し、ステータスをポーリングした結果、すべてのノードでライブブロードハッシュコンセンサスが100%に達し、その後Localnetを正常に停止して削除しました。
Localnetはプロセスを単に強制終了することで停止しません。stop:localnetスクリプトは、ノードの通常のグレースフルシャットダウン経路を使用しており、不要なデータベースやランタイム状態の問題を回避し、ローカルテストを実際の運用動作に近づけます。デフォルトでは、ローカルのPostgreSQLデータベースは永続化されます。自動データベース作成は、ローカルのPostgreSQLロールがCREATEDB権限を持っているかどうかに依存します。これが利用できない場合、開発者は既存のデータベース構成またはドキュメント化されたスキップ/作成オプションを使用できます。
設定オーバーライド：手動での設定編集は不要
以前は、ADAMANT Nodeは--configで設定ファイルを選択でき、--port、--address、--peers、--log、--snapshotなどのハードコードされたCLIオーバーライドをいくつかサポートしていました。これはシンプルなケースでは機能しましたが、スケールしませんでした。運用者や自動化スクリプトは、ポート、Redis設定、データベース設定、ピアリスト、ログ設定、API設定、フォージング設定、アクティベーション高、テスト固有のパラメータなど、ネストされた設定値を変更する必要があることがよくあります。設定ファイルをコピーして手動で編集するのはエラーが発生しやすく、設定キーごとにCLIフラグを追加するのはスケーラブルではなく、設定ファイル全体を置き換えるのは、小さな環境固有の変更には重すぎることがあります。
開発者は、既存の設定オブジェクトの構造に一致するドットパスキーを使用して、起動時に個々の設定値を直接渡せるようになりました：
node app.js \
--config test/config.json \
--genesis test/genesisBlock.json \
--config-set consensusActivationHeights.fairSystem=4359465 \
--config-set redis='{ "url": "redis://127.0.0.1:6379/1", "password": null }'これにより、スクリプトは単一のネストされたスカラー値またはオブジェクト全体の値をオーバーライドできます。可能な場合は値がJSON互換の値として解析されるため、数値、ブール値、null、配列、オブジェクトをプレーンな文字列として扱うのではなく、正しく表現できます。
設定オーバーライドはファイルもサポートします。env形式のオーバーライドファイルには、次のようなエントリを含められます：
consensusActivationHeights.fairSystem=4359465
redis='{ "url": "redis://127.0.0.1:6379/1", "password": null }'この実装は、JSON形式の部分オーバーライドファイルもサポートしています。これは、ローカル環境、テスト自動化、CIに類似したワークフロー、追跡された設定ファイルを変更せずに再現可能な変更セットを必要とするメンテナにとって有用です。Localnetは、test/config.localnet.jsonを通じてデフォルトでこのメカニズムを使用し、基本設定を安定させたまま、Localnet固有の差分を同じ検証済みオーバーライドフローで適用します。
検証と安全性
最終的に解決された設定は、デフォルト、オーバーライドファイル、直接オーバーライド、レガシーCLIショートカットが解決された後も、既存のADAMANT設定スキーマに対して検証されます。無効なパス、無効な値の型、不正なJSON、安全でないキーは、起動前に失敗することが予期されており、予測不可能なランタイム動作を引き起こすことはありません。パスワード、パスフレーズ、シークレット、トークンなど、機微な値は設定オーバーライドのログから伏字化されます。レガシーの起動ショートカットは、同じ検証済みオーバーライドパイプラインを通過し、最も高いオーバーライド優先順位を保持するため、既存のワークフローは引き続き動作し、新しいワークフローはより汎用的で一貫性のある設定メカニズムを獲得します。
一部の設定値はコンセンサスに影響を与えます。consensusActivationHeights.*などのキーをオーバーライドすることは、ローカルまたはテストのシナリオでは有用ですが、間違ったチェーンに対してネットワーク非互換なアクティベーション高を使用すると、ノードがネットワークから分岐する可能性があります。設定オーバーライドは明示的で可視であることを意図しています。Localnet、Testnet、自動化、制御された運用シナリオに有用ですが、本番のMainnetノードでは注意して使用する必要があります。この機能は起動時の設定解決のみを変更するものであり、ブロックロジック、トランザクションのシリアル化、報酬ロジック、手数料ロジック、デリゲートの順序、署名チェック、コンセンサスルールを直接変更するものではありません。
LocalnetとTestnetの連携
LocalnetはTestnetを置き換えるものではなく、異なる問題を解決します。Localnetは、開発者が完全な制御、迅速な起動、分離された実験を必要とする、1台のマシンでの高速でプライベートな反復可能な開発に最適です。Testnetは、永続的な環境、公開ピア、テスト用ADMコイン、エクスプローラーアクセス、共有ネットワークに対するアプリケーションレベルのチェックを必要とする、公開の共有ネットワークレベルのテストに最適です。これらを組み合わせることで、ADAMANTのコントリビュータはより強力な開発パイプラインを手に入れます。Localnetでローカルテストを行い、公開Testnetで検証し、その後より安全なMainnetリリースを準備できます。
Localnetのライフサイクル管理は、意図的にシナリオテストの実行から分離されています。Localnetスクリプトは、ローカルネットワークの起動、停止、検査、クリーンアップを担当します。その後、シナリオリーダーは既に利用可能なLocalnetまたはTestnetをターゲットとし、レポートを生成できます。この分離により責任が明確になり、将来のツール構築が容易になります。