AvalancheGoはAvalancheノードを動かすGo実装
Avalanche ノードの Go 実装。 AvalancheGo をソースからビルドする予定の場合は、次のソフトウェアも必要になります。 Go バージョン >= 1.25.10 gcc g++ ソースからのビルド リポジトリのクローン AvalancheGo リポジトリのクローンを作成します。これにより、マスター ブランチがクローン作成され、チェックアウトされます。
ひと目でわかる
- これは何？
- Avalancheネットワークのメインネット、Fuji、ローカルテストネットに接続できるノード実装と、ビルド・API・コード生成の手順。
- 誰に向いている？
- Avalancheのノードを自分で運用し、Go製クライアントをビルドまたは配布物から検証したいチーム向けです。短時間で同期できるノードや、READMEだけで満たせるセキュリティ保証を探す用途には向きません。
- 商用利用できる？
- できます。BSD-3-Clause は寛容なライセンスで、著作権表示とライセンス表示を残せば、使用・改変・販売が可能です。
- 今もメンテナンスされている？
- されています。最後のコミットは 4 日前です。
- 何の言語で書かれている？
- 主に Go です（GitHub の言語統計による）。
回答はプロジェクトの GitHub データ（最終同期：2026年9月14日）と当サイトの分析に基づくもので、法的助言ではありません。
オープンソース詳細解説
ネットワークノードとしての範囲
AvalancheGoはAvalancheネットワークのノード実装です。READMEは高スループットと高速トランザクションを特徴として紹介しますが、ベンチマーク値やセキュリティ保証は示していません。実際に担う仕事は、ネットワーク状態を取得し、ブートストラップ後にコンセンサスへ参加し、APIを提供するノードプロセスを稼働させることです。
メインネット接続だけが入口ではありません。Fujiは--network-id=fujiで指定でき、ローカル検証にはavalanche-cliのavalanche network startとavalanche network statusを使います。目的ごとにネットワークを分ければ、同期の確認とアプリケーションのテストを同じ環境で混ぜずに済みます。
必要な資源とビルド環境
Mainnet接続の最低推奨値は8 AWS vCPU相当、RAM 16 GiB、ストレージ1 TiBです。OSはUbuntu 22.04/24.04またはmacOS 12以降、ネットワークは安定したIPv4またはIPv6と公開ポートが前提です。長期稼働や独自設定ではストレージが増える可能性があります。
ソースビルドにはGo 1.25.10以上、gcc、g++が必要です。git cloneでリポジトリを取得し、./scripts/run_task.sh buildを実行するとbuildディレクトリにavalanchegoができます。ここで重要なのは、CPUだけでなくデータベースIOとディスク容量を先に見積もることです。
配布物とDockerの選択
UbuntuではAPTリポジトリを追加してsudo apt updateとsudo apt install avalanchegoを実行できます。各OSとアーキテクチャ向けの最新ビルドはGitHub Releasesから取得でき、実行ファイル名はavalanchegoです。Dockerイメージを作る場合は./scripts/run_task.sh build-imageを使い、生成イメージは短縮コミットを含むavaplatform/avalanchego:xxxxxxxxというタグになります。
Docker実行例は9650と9651を公開し、イメージ内の/avalanchego/build/avalanchegoを起動します。運用時はポート、データ永続化、ログ、イメージのコミット対応を明示し、latest相当の曖昧な更新を避けるべきです。
ブートストラップを性能評価にする
新しいMainnetノードが最新状態へ追いつくブートストラップには数日かかるとREADMEは説明しています。完了するまでノードはhealthyを報告せず、API提供やコンセンサス参加の前提も満たしません。時間短縮策は開発中で、典型的なボトルネックはデータベースIOです。
評価ではプロセス起動だけで成功とせず、health APIの状態、同期完了までの時間、ストレージ増加量を測ります。CPU強化やデータベースIOPS増加が時間短縮につながるという記述もありますが、自分のディスクとネットワークで再測定します。READMEにない保証は運用手順へ持ち込まないことが重要です。
生成コードとライセンスの境界
AvalancheGoはprotobufコード生成など複数のツールを使います。proto定義を変更した場合やprotobufを更新した場合はscripts/run_task.sh generate-protobufを実行する手順が示されています。生成物の差分をレビューし、ツールのバージョンを固定できるかを確認します。
リポジトリは、graftサブプロジェクトが別途定めない限りBSD-3-Clauseです。これはノードの性能や安全性を保証する文言ではありません。導入前にリリース版とビルド版の挙動、FujiでのAPI応答、再起動後の同期継続を記録し、Mainnet切り替えの条件をチーム内で合意します。
ノードをサービス化する場合は、データディレクトリの永続化、終了時の再起動、ログのローテーション、公開ポートのファイアウォールを個別に設定します。メインネットへ向ける前にFujiで--network-id=fujiを指定し、health APIが同期完了後にhealthyを返すことを見ます。ローカルテストネットではavalanche network statusの結果とアプリケーションの接続先を照合します。リリースを更新するときは実行ファイル、設定、データ形式の対応を記録し、数日を要する再同期が発生しても戻せるディスク容量と監視時間を確保します。
AvalancheGoの評価記録には、起動時刻、ブートストラップ開始と終了、health APIの応答、ディスク使用量を残します。Mainnetへ移す判断をログから説明できる状態にします。
新規ノードでは起動成功と同期完了を別の状態として扱います。9650と9651の公開ポート設定、ログの時刻、ストレージ増加を監視し、数日単位のブートストラップに耐える容量を確認します。
AvalancheGoはAvalancheノードを動かすGo実装を受け入れる前に、README記載の入力、実行、出力を一つの記録へまとめます。成功した操作だけでなく、失敗した操作、未確認の機能、利用した版、設定値、保存したログの場所も残します。担当者が同じ環境を作り直し、同じ確認結果を再現できることを条件にします。性能や互換性について数値を扱う場合は、データ量、実行時間、エラー数、資源使用量を測定条件とともに記録します。READMEにない保証は採用理由へ加えず、未確認事項として次の検証に回します。
編集部の結論
Avalancheのノードを自分で運用し、Go製クライアントをビルドまたは配布物から検証したいチーム向けです。短時間で同期できるノードや、READMEだけで満たせるセキュリティ保証を探す用途には向きません。Ubuntu 22.04/24.04またはmacOS 12以降で、8 vCPU、16 GiB RAM、1 TiBストレージ、公開ポートを用意し、Fujiで同期とヘルス状態を先に確かめてください。
コミュニティノート