base/nodeでBaseノードをDocker運用する条件
独自の Base ノードを実行するために必要なものすべて。このリポジトリには、base-reth-node および Base-consensus を使用して Base ノードを実行するための Docker ビルドが含まれています。
ひと目でわかる
- これは何？
- Ethereum L1の接続先とNVMeを用意し、base-reth-nodeとbase-consensusを組み合わせてBase mainnetまたはSepoliaを動かす構成を読む。
- 誰に向いている？
- Baseのノード運用を自分で管理したいチームには、Docker Composeから始められる点が合います。一方、L1 RPCとビーコン接続、増加するチェーンデータを維持できない環境には向きません。
- 商用利用できる？
- できます。MIT は寛容なライセンスで、著作権表示とライセンス表示を残せば、使用・改変・販売が可能です。
- 今もメンテナンスされている？
- されていません。所有者が GitHub でリポジトリをアーカイブしており、読み取り専用で今後は更新されません。
- 何の言語で書かれている？
- 主に Shell です（GitHub の言語統計による）。
回答はプロジェクトの GitHub データ（最終同期：2026年9月15日）と当サイトの分析に基づくもので、法的助言ではありません。
オープンソース詳細解説
L1接続を先に用意する起動経路
Base nodeは単体で閉じた実行物ではありません。READMEのQuick Startは、Ethereum L1フルノードのRPCエンドポイントとビーコンエンドポイントを先に用意する順序です。mainnetなら .env.mainnet、テストネットなら .env.sepolia を選び、BASE_NODE_L1_ETH_RPC と BASE_NODE_L1_BEACON に接続先を入れます。接続先の提供者や契約条件はREADMEに書かれていないため、ここは運用側の責任になります。
起動はmainnetの既定値なら docker compose up --build、Sepoliaなら NETWORK_ENV=.env.sepolia docker compose up --build です。これはDockerイメージを作成してCompose構成を起動する入口であり、L1接続が正しいことまで保証するコマンドではありません。ログにL1 RPC、ビーコン、L2同期の失敗がないかを、ネットワーク選択ごとに分けて確認する必要があります。
実行層とコンセンサス層の組み合わせ
対応クライアントとしてREADMEが挙げるのは、実行層の base-reth-node とコンセンサス層の base-consensus です。別の実行クライアントやコンセンサスクライアントとの組み合わせは説明されていません。したがって、このリポジトリの評価対象はBaseが指定する二つのコンポーネントをDockerで動かす経路です。独自に構成を差し替える場合の互換条件は文書未説明です。
チェーンデータを扱うノードなので、コンテナが起動したかだけで判断すると不足します。base-reth-nodeが実行データを処理し、base-consensusがL1側のコンセンサス情報を扱える状態かをログとRPCで切り分けます。READMEは診断コマンドを列挙していないため、運用時はComposeのサービス名、公開ポート、ログ保存方法を実際のファイルから確認してください。
baseとbase-sepoliaの設定を揃える
必須設定は BASE_NODE_L1_ETH_RPC、BASE_NODE_L1_BEACON、BASE_NODE_NETWORK、RETH_CHAIN の四つです。mainnetでは BASE_NODE_NETWORK=base と RETH_CHAIN=base、Sepoliaでは両方を base-sepolia にします。片方だけを変更すると、接続先とチェーン識別が食い違う可能性があります。READMEにある値を .env の一つの組として扱うのが安全です。
シーケンサーURLもmainnetは https://mainnet-sequencer.base.org、Sepoliaは https://sepolia-sequencer.base.org と記載されています。ただし、そのURLが内部でどの設定に接続されるかはREADMEの説明だけでは分かりません。完全な選択肢は .env.mainnet と .env.sepolia を直接読み、未掲載の既定値を推測しないことが重要です。
Flashblocksと三つの任意機能
RETH_FB_WEBSOCKET_URL を設定すると実行クライアントはFlashblocksモードになり、未設定時はvanillaモードです。Flashblocksモードで保留ブロックを問い合わせる例として、READMEはlocalhost:8545へ eth_getBlockByNumber の pending を送るcurlを示しています。モードの導入前後で、同じRPCに対する応答と pending ブロックの有無を比較できます。
BASE_NODE_SOURCE_L2_RPC はfollow mode、RETH_PRUNING_ARGS はpruningの設定名として示されていますが、値の構文やデータ保持の影響はREADMEにありません。特にpruningはディスク使用量と参照可能な履歴に関わるため、変数名だけを見て設定を決めるべきではありません。まず.envの記述と実行クライアントのログを対応付け、変更前のデータパスを退避できる状態で確認します。
NVMe容量とスナップショットの読み方
最小要件は現代的なマルチコアCPU、RAM 32GBで、64GBが推奨されています。ストレージはNVMe SSDで、計算式は現在のチェーンサイズの2倍にスナップショットサイズと20パーセントの余裕を加える形です。現在の数値は base.org/stats とスナップショット情報サイトへのリンクに委ねられています。容量を固定値で見積もらず、導入時点のリンク先を確認してください。
本番の参考としてAWS i7i.12xlarge、全ローカルNVMeのRAID 0、ext4を使うReth archive nodeが示されています。これは本番で使っている仕様の紹介であり、全利用者への必須構成ではありません。ただしRAID 0はドライブ障害時の扱いが運用課題になります。スナップショットには同期短縮の用途がありますが、直接URLやチェックサム、取得頻度はREADMEに記載されていません。
採用前に見る具体的な境界
この節では base/node のREADMEに書かれた スナップショット復元、L1接続、ネットワーク選択 を基準にします。リポジトリの人気や説明文だけで、READMEにない性能、可用性、対応範囲を補ってはいけません。実際に確認できる入力、設定、出力を切り分けると、導入判断の根拠を追跡できます。記載がない部分は文書未説明として残します。 READMEはmainnetとtestnetをサポート対象として示し、サポート窓口としてBase Discordのnode-operatorsチャンネルとGitHub issueを案内します。ソフトウェアは現状のまま提供され、資産保護やセキュリティの保証はないという免責もあります。ノードを公開する前に、BASE_NODE_L1_ETH_RPCとBASE_NODE_L1_BEACONを秘密情報として扱い、8545の公開範囲、ディスク残量、再起動後の同期復帰を具体的に点検してください。
BASE_NODE_NETWORKとRETH_CHAINの値は同じネットワーク名になっているかを確認し、L1 RPCとビーコンの接続先をmainnet用とSepolia用で混ぜません。Flashblocksを使う場合はRETH_FB_WEBSOCKET_URLの接続先とlocalhost:8545の応答を記録し、使わない場合はvanillaモードであることをログから確認します。容量計算に使ったチェーンサイズとスナップショットサイズの日付も残します。
編集部の結論
Baseのノード運用を自分で管理したいチームには、Docker Composeから始められる点が合います。一方、L1 RPCとビーコン接続、増加するチェーンデータを維持できない環境には向きません。最初に .env の接続先、base と base-sepolia の組み合わせ、NVMe容量、スナップショット復元後の同期状態を確認してください。
コミュニティノート