メインコンテンツまでスキップ

BOT Chain ノード構成: ベスト プラクティス

ハードウェア仕様​

最適なパフォーマンスと信頼性を確保するには、BOT Chain での取引処理と状態クエリの特定の要件に基づいて、適切なノード タイプを選択することが重要です。

アーカイブおよび完全なノード展開ガイド​

  1. リポジトリのクローンを作成し、ディレクトリに入ります

  2. bash

git clone https://github.com/bl-BOHR/node-deploy.git && cd node-deploy

  1. 実行権限を付与します (Linux では初回のみ必要)

  2. bash

chmod +x BOHR_full_node.sh BOHR_archive_node.sh bin/geth*

  1. ノードの初期化と起動

    • フルノード:

    • bash

    ./BOHR_full_node.sh reset

    • アーカイブノード:

    • bash

    ./BOHR_archive_node.sh reset

  2. ログを表示 ノードログは、.local/fullnode/node/BOHR-node.log にあります。 軽量モードで最新のワールド状態にアクセスする必要があるユーザーにとって、高速ノードは理想的な選択肢です。システムの CPU とディスク容量の要求が少なくなります。

推奨構成​

BOTメインネットの歴史的世界状態全体に包括的にアクセスするには、アーカイブ ノードのデプロイを検討してください。詳細な手順は、BOT Chain GitHub リポジトリで参照できます。（ここでは、リポジトリへの外部リンクが必要です。）

  • プロセッサ: 少なくとも 2 コアの CPU。

  • メモリ: 少なくとも 4 GB の RAM。

  • ストレージ: 最小容量128GBのソリッドステート ドライブ (SSD)。

  • ネットワーク: 安定した高速インターネット接続 (最低 1 MBps)。

アーカイブノード​

最新の世界状態を取得して状態の有効性を検証したり、データ証明を生成するには、標準のフルノードが適しています。

  • プロセッサ: 4 コア以上の CPU。

  • メモリ: 8 GB 以上の RAM。

  • ストレージ: SSD、最小容量 1TB (最適なパフォーマンスを得るには NVME SSD を使用することを推奨します)。

  • ネットワーク: 安定した高速インターネット接続 (最低 2 MBps)。

フルノード​

バリデーターの最も価値のある資産は 2 つのキーです。1 つは取引の署名用で、もう 1 つはブロックの署名用です。

  • プロセッサ: 4 コア以上の CPU。

  • メモリ: 8 GB 以上の RAM。

  • ストレージ: 最小容量 1TB のソリッド ステート ドライブ (SSD)。

  • ネットワーク: 安定した高速インターネット接続 (最低 2 MBps)。

ピア構成​

メインネット​

  • 静的ノードを指定する必要はありません。メインネットにはコード内で既に構成されているブートノードのみが必要です。また、必ず最新リリースの config.toml ファイルを使用してください。

テストネット​

  • テストネットは依然として StaticNodes を手動で設定する必要があるため、StaticNodes リストは最新リリースの config.toml に含まれています。

テストネットにピアがない場合のトラブルシューティング​

  • 間違ったチェーン ID、間違った構成ファイル/ディレクトリなどの構成の問題を確認してください。

  • 最新リリースに従って config.toml ファイルを更新してください

  • テストネットではブートノードを使用しないでください。必須ではありません。

  • geth/nodes および geth/nodekey ファイル/ディレクトリを削除すると解決する可能性があります

  • スナップショットを再度ダウンロードして、もう一度試してください。

BOTをハードウェアウォレットに保存する​

RPC エンドポイントをパブリック ネットワークに公開しないでください。

フルノード RPC をハッカーから保護する​

BOT を保護するために、24 語を誰とも共有しないでください。彼らを知る必要があるのはあなただけです。つまり、HSM は、秘密キーを安全に生成、保存、管理するのに役立つ、手頃な価格でパフォーマンスに優れたポータブルなハードウェアです。 HSM が適切に構成されている場合、マルウェア攻撃や秘密キーのリモート抽出はより一層難しくなります。

アカウントの秘密キー​

BOT を保護するには、ソフトウェアは公式ソースからのみ直接ダウンロードし、常に最新で最も安全なバージョンを使用するようにしてください。

ソフトウェアの脆弱性​

geth を常に実行し続けることが重要です。これを実現するにはいくつかの方法がありますが、私たちが推奨する最も簡単な解決策は、geth を systemd サービスとして登録し、システムの再起動やその他のイベント時に自動的に開始されるようにすることです。

サーバーをデーモンとして実行する​

長期間実行 (同期) し、突然終了した後は、アーカイブされたノードのみが再起動時にすぐに再同期されることが期待されます。

バックアップノードのセットアップ​

  • バリデーターノードをアーカイブモードで実行する

  • ノードを正常にシャットダウンします

  • ツールによるアクティブ監視

バックアップ ノードを実行する手順​

  1. 最新バージョンの geth をインストールします

  2. 高速同期モードを使用して最新の高さに同期します。最新のスナップショットをダウンロードするか、ノードが完全に同期されたら高速同期を開始できます。

  3. ノードを正常にシャットダウンします。 kill -HUP $(pgrep geth)

  4. ノードを再起動します。

Why Node will be Offline for a While After Restart? or What will Happen If the Client is Force Killed?​

再現手順:

理由

  • ノードを一定期間同期して実行します。

  • ノードを突然強制終了します (kill -9 またはシステムクラッシュ)。

  • ノードを再起動し、1 時間前のブロックの高さからどこで再同期するかを観察してください。

Geth がクラッシュした場合 (または正常にシャットダウンされなかった場合)、メモリに保持されている最近の状態は失われるため、再生成する必要があります。状態を復元するには、 Gethが長い時間をかけます。

根本的な理由は、geth が状態トライを定期的にフラッシュすることです。この期間は、config.toml で trieTimeout として定義されます。

geth コンソールにコマンドを送信することで、新しいブロックのマイニングを停止できます

バックアップノードをアップグレードして検証ノードにするにはどうすればよいですか?​

gethattach ipc:path/to/geth.ipc を使用してバリデーターノードに接続します

次に、バックアップノードの検証を再開します。

miner.stop()

多様なセットアップによりネットワークの回復力が高まるため、各バリデーター候補者は独立して操作を実行することが推奨されます。バリデーターは多額の投資を行っているため、さまざまな DoS 攻撃や DDoS 攻撃からバリデーターを保護することが非常に重要です。このセクションでは、BOT Chain がバリデーターに採用しているセキュリティメカニズムについて説明します。

miner.start()

バリデーターの保護​

検証者は、ネットワークがサービス拒否攻撃に耐えられることを確認する責任があります。これらのリスクを軽減するために推奨される方法の 1 つは、バリデーターがいわゆるセントリーノードアーキテクチャでネットワークトポロジを慎重に構築することです。セントリーノードはすぐにスピンアップしたり、IP アドレスを変更したりできます。セントリーノードへのリンクはプライベート IP 空間にあるため、インターネットベースの攻撃によってセントリーノードが直接妨害されることはありません。これにより、バリデーターが提案をブロックし、投票が常にネットワークの残りの部分に届くようになります。

セントリーノード (DDOS 保護)​

セントリーノードアーキテクチャをセットアップするには、次の手順に従って操作してください。

バリデーターのフルノード RPC エンドポイントをパブリックネットワークに公開しないでください。

  1. プライベートネットワークを構築し、バリデーターノードとその監視ノードの間に信頼できるプライベート接続をセットアップします。

フルノードをインストールしてください

セントリーノードのコンソールで admin.nodeInfo.enode を実行すると、次のような結果を取得するはずです。

  1. バリデーターノードのピアとしてセントリーを設定します

!!!注: [::] は localhost (127.0.0.1) として解析されます。ノードがローカル ネットワーク上にある場合は、個々のホストマシンを確認し、ifconfig を使用して IP を見つけてください。ピアがローカル ネットワーク上にない場合は、e ノード URL を構築するために (サービスを使用して) 外部 IP アドレスを知る必要があります。この値をコピーし、最初に実行したノードのコンソールで、

enode://f2da64f49c30a0038bba3391f40805d531510c473ec2bcc7c201631ba003c6f16fa09e03308e48f87d21c0fed1e4e0bc53428047f6dcf34da344d3f5bb69373b@[::]:30306?discport=0

バリデーターノードのconfig.tomlファイルを更新します

成功すると true が返されますが、これはノードが正常に追加されたことを意味するわけではありません。

# make node invisible
NoDiscovery = true
# connect only to sentry
StaticNodes = ["enode://f2da64f49c30a0038bba3391f40805d531510c473ec2bcc7c201631ba003c6f16fa09e03308e48f87d21c0fed1e4e0bc53428047f6dcf34da344d3f5bb69373b@[10.1.1.1]:30306"]

確認するには、admin.peers を実行すると、追加したばかりのノードの詳細が表示されるはずです。

そうすることで、バリデーターノードは、提供されたセントリー ノードのみとピアリングを試みます。

確認するには、admin.peers を実行すると、追加したばかりのノードの詳細が表示されるはずです。

  1. 接続を確認してください

geth は、さまざまな目的に複数の TCP ポートを使用します。

ファイアウォールの設定​

geth は、リスナー (TCP) ポートと検出 (UDP) ポートを使用します。デフォルトでは、両方とも 31000 です。

JSON-RPC を実行する必要がある場合は、TCP ポート 8545 も必要です。 JSON-RPC ポートを外部に開いてはいけないことに注意してください。そこから管理操作を実行できるからです。

If you need to run JSON-RPC, you'll also need TCP port 8545. Note that JSON-RPC port should not be opened to the outside world, because from there you can do admin operations.