erpc validator と erpc rpc でバリデータと RPC ノードを動かす

ノードをデプロイする

# check the server, pin the client releases, store the node in 1Password
erpc rpc --chain ethereum -n mainnet --name eth1 init --host <address> --vault <vault id> --ssh-key ~/.ssh/id_ed25519.pub
# install, fetch a snapshot, apply the firewall, start
erpc rpc --chain ethereum -n mainnet --name eth1 deploy --ssh-key ~/.ssh/id_ed25519.pub
# both layers, sync and head
erpc rpc --chain ethereum -n mainnet --name eth1 status --ssh-key ~/.ssh/id_ed25519.pub

# check the server, pin the client releases, store the node in 1Password
erpc rpc --chain ethereum -n mainnet --name eth1 init --host <address> --vault <vault id> --ssh-key ~/.ssh/id_ed25519.pub
# install, fetch a snapshot, apply the firewall, start
erpc rpc --chain ethereum -n mainnet --name eth1 deploy --ssh-key ~/.ssh/id_ed25519.pub
# both layers, sync and head
erpc rpc --chain ethereum -n mainnet --name eth1 status --ssh-key ~/.ssh/id_ed25519.pub

チェーン、ネットワーク、ホストを選ぶ

• ノードのコマンドは、erpc validator（別名 v）、erpc rpc（別名 r）、erpc node（別名 n。Avalanche と Sui 用）で実行します。
• コマンドグループを動詞なしで実行すると（erpc validator）、その動詞の一覧が表示されます。
• ノードのコマンドでは、--json をコマンドより前に置く必要があります（erpc --json rpc …）。

どのチェーンでも使えるコマンド

対応チェーンとチェーンごとのガイド

erpc がサーバーに求めること

• erpc は、あなたの鍵で、sudo のできるユーザー（既定は ubuntu）として SSH でログインします。鍵は 1Password の SSH エージェントか SSH_AUTH_SOCK から使い、初めて接続したときにホスト鍵を固定します。
• サーバーには /usr/bin/python3 と、sudo がパスワードを求めないログインユーザーが必要です。
• /opt は、Ubuntu の初期状態と同じく、root が所有し、グループにもその他のユーザーにも書き込めない実体のディレクトリとして、あらかじめ在る必要があります。erpc はこれを作りません。/opt/erpc と、erpc がその中に作る runs と uploads のディレクトリにも同じ規則が掛かり、これらはどれもシンボリックリンクにできません。別のボリュームに置きたいときは、そのボリュームを /opt/erpc にマウントしてください。ノードの場合は、/opt/erpc を置くファイルシステムが POSIX ACL も保てる必要があり（ext4 と XFS は既定で保てます）、保てないと erpc は止まります。
• 新しい Solana のホストには、Ubuntu 24.04、systemd 255、AVX2 と SHA の CPU 機能を持つ x86-64 が必要です。ERPC が求める最小の構成は、Solana の RPC ノードで論理スレッド 32 と使えるメモリ 480 GiB、mainnet のバリデータでスレッド 24 と 300 GiB、testnet のバリデータでスレッド 24 と 120 GiB です。

erpc がノードを動かすときにすること

• ほとんどのチェーンでは、クライアントをログインできない専用のユーザーで動かし、各リリースをインストールする前に固定したチェックサムと照合し、新しい管理用の接続で確認されなければ時間で元に戻る、nftables のファイアウォールを適用します。すべてのチェーンがそうではありません。新しい Solana のノードは、固定したソースのコミットからサーバー上でビルドします。solv のバックエンドで記録された Solana のノードは、パスワードなしの sudo ができるログインユーザーで動き、一部のツールをチェックサムなしで取得します。
• erpc は、solv のバックエンドの Solana のバリデータ、Ethereum のバリデータ、Bitcoin のノードにはファイアウォールを適用しません。これらのホストの通信の制限は、ご自身で行ってください。
• ネットワークを変更する間も、ホストに届く別の経路を持っておいてください。
• 保護されたサービスの drop-in ディレクトリに別のファイル（systemctl edit で作った override.conf など）が在る間は、ファイアウォールの手順は受け付けず、何も変更しません。その drop-in をディレクトリの外に移してから、コマンドをもう一度実行してください。
• あなたのマシンから送るシークレットは、標準入力でサーバーに届き、コマンドラインには載りません。
• 新しい Solana のバリデータは、投票を無効にした別のアイデンティティで同期します。deploy --activate-validator は、公開の登録とネイティブの BLS の確認を経てから、健全なホストを元の登録済みのアイデンティティに切り替えます。--backend solv は既存の solv のホストを再開するためのもので、新しいホストは作れません。
• Ethereum のバリデータの署名者をバックアップから復元しないでください。署名者を移すときは erpc v --chain eth migrate を使います。

チェーンごとの検証の状況