▼はじめに
ノード運用をしていると「ノードの実行環境を変えたい」と思うことが少なからずあると思います。私もその一人で、これまで何度か引っ越しを行なってきました。その時に使った手法を用いて、今回は通常ノードからモバイルノードへの引っ越しをチャレンジしてみました。
環境引っ越しの前に
Symbolネットワーク上でノードを建てると、main, transport, remote, vrf の公開鍵、秘密鍵（以降、４つのアカウントと称します）が発行され、ネットワーク上で他のノードと区別されます。今回新たに建てたノードが誰かのノードと被ることはありません。逆に同じ４つのアカウントを用いて複数の端末で同じノードを建てることも可能です。
◎どういう状態になるの？
とても噛み砕いた表現をすると「分身の術」のような状態になります。極めて精巧な状態のもので、どちらも「本物」です。何らかのアクシデントで片方のノードが停止してしまった場合は、もう片方のノードがネットワーク上で「動作中」となります。
◎委任はどうなるの？
サーバを２台借りて同じ４つのアカウントを用いてそれぞれノードを建てた例。
・サーバＡ（125.23.45.10）→ monday.com と関連付け（同じ４つのアカウント）
・サーバＢ（124.56.77.250）→ friday.net と関連付け（同じ４つのアカウント）
ここで monday.com に対して委任すると同時に friday.net にも委任していることになります。
別の言い方をすると friday.net に委任すれば monday.com に委任していることにもなります。
サーバＡ，Ｂともに IPアドレスは違いますが、その先にある４つのアカウントが同じですので、 ネットワーク上では入り口は別で中は一緒というようなイメージになります。
今回はこの特性を活用します。
2つの環境を準備 [以下、テストネットにて実施]
・共通仕様
※ハーベスト報酬の入る beneficiaryAddressを同じアドレスとする。
※ホスト名は任意(合わせる必要なし)
※委任上限等の委任者へ影響のある設定は同じにしておく。
・通常ノード(api,peer)
→Ubuntu22.04 symbol-bootstrap にて起動。
※main, transport, remote, vrf の公開鍵、秘密鍵を確保。
※サーバのIPアドレスをドメイン「xewth.net」へ関連づけ実施。
※カスタムプリセット内のホスト名を「xewth.net」とする。
・モバイルノード(peer)
→Android11(peer)
※今回は試験のため Win11からAndroidをエミュレート起動し
モバイルノードを起動するが、用意できるならAndroid端末実機で問題ない。
※控えておいた通常ノードの transport秘密鍵を使用して起動。
※transportであることが重要です。mainではありません。
検証手順
・上記２環境を用意して同期完了を待つ。
・デスクトップウォレットからドメイン( https://xewth.net:3001 )へ委任。
ハーベストされることを確認。
・通常ノードを停止し、モバイルノード１本の運用に絞る。
ハーベストの可否と委任者情報がモバイルノード側で確認できるかを検証する。
検証過程
・「ノードURL」に https://xewth.net:3001 が表示され数回のハーベストを確認。
その後､通常ノード停止､モバイルノード１本の運用でハーベストできるかどうかを試す..。
通常ノードを止めているのでノードURLも消えている。
「ハーベスト状況」は「失敗しました」となり、検証は失敗に見えたが..。
「生成ブロック」数は増え「ハーベストされたブロック」は通常のハーベスト時と同じように追加された。徴収手数料も増えている。ここからは予測の域を出ないが、デスクトップウォレットは通常ノード(api, peer)を想定して作られており、モバイルノードのように peerノードのみの場合を考慮されていないのでは..と考えた。ともあれ、検証は成功である。
※ウォレットにはドメインで委任したが、Symbolネットワーク上で同じ transport鍵を使用したノードを建てることで通常ノード、モバイルノードの運用形態の違いがあっても同じ委任者情報となることが判明した。ここまでの内容から通常ノードからモバイルノードへ委任者を引き継ぎ環境を移行することは可能、と判断する。
※ウォレット上の「ハーベスト状況」の表示だけを見るとノードが落ちているようにも見えてしまうと思うので、環境移行を行うには事前に通達を行っている方が良い、と考える。
・モバイルノード側でも委任者情報が作成されていることを確認。
※委任者がいて初めて作られる「harvesters.dat」が作成されている。
では、逆は？
モバイルノードから通常ノードへ逆の行為を行った場合はどうなるか
・モバイルノード、通常ノードを建て、同期完了。
２機とも委任者のいない状態を作り、改めてモバイルノードへ委任。
transport公開鍵を指定して委任を行います。
ハーベスト状態が「有効化が進行中」となり..
ハーベスト状態が「有効」へと変わる。そして驚くべきことに ノードURLが https://xewth.net:3001 に変わっている。同一の鍵を用いた通常ノード(api, peer)ノードがあればそちらの【node】情報取得して変わってくれるの？ と驚いた。
キーリンクにある情報を元に、ドメイン xewth.net へ委任されているかを確認する。
「http://ドメイン:3000/node/unlockedaccount 」または
「https://ドメイン:3001/node/unlockedaccount 」にて、
委任者の公開鍵を見ることができる。
自分のキーリンク情報をもとに、
委任先の上記アドレスへアクセスすれば委任できているかを確認することができる。
そして結果は... ありました
委任されている！
※ちなみに「0：」となる先頭には４つのアカウントの内の remote の公開鍵が必ず指定される。ということは全く違うドメインであっても「0：」のアドレスが同じであれば、remote の秘密鍵を知っている人と判断できるのでノード主は同じであると想像できる。
既に委任者がいる状況でモバイルノードを新規構築した場合(2023/11/20追記)
上記までの流れでは、通常ノードとモバイルノードを建てた後の委任情報が同期されることを確認した。では、既に委任者がいる通常ノードがあり、その状態でモバイルノードを新規構築した時にはどのような動きとなるのかを再確認する。
まず、通常ノードの同期完了の後、ドメイン xewth.net へ委任を完了させる。その後、モバイルノードを全初期化し、transport秘密鍵を使って新規ノード構築を行う。
ブロック高が新しく処理されていくことを確認。
この時、テストネットのdataフォルダを見ると「harvesters.dat」は存在しないが...。
モバイルノード側も同期完了後には「harvesters.dat」が作成されていることを確認できた。ここで通常ノード側を停止し、モバイルノードのみの運用に切り替えを実施。
先の検証時と同じくモバイルノード運用のみとなるとハーベスト状況「失敗しました」となるが、ハーベストは正常に行えることを確認。今回の追加検証をもって「通常・モバイルノードの両環境構築後に委任した委任者の同期」と「モバイルノード構築前からの委任者の同期」の両方を確認できた。
以上をもって検証を終了。
この事例を応用した使用例を検討
・VPS, Allnodes等の通常ノードから委任者情報を引き継いでモバイルノードへの移行。
※モバイルノードから通常ノードへの移行も同様。
※もちろん通常ノードから通常ノードへも可能。
・main, transport, remote, vrf の公開鍵、秘密鍵を受け渡せば、
ノード運用を第３者へ移譲することが可能。
・VPS, モバイルノードを問わず、
同じ main, transport, remote, vrf の公開鍵、秘密鍵を用いることで
複数端末で同一ノードアドレスの端末を構成し、冗長運用が可能。
モバイル２機による冗長構成運用者が出てくるかもしれません。
▼おわりに
ここまでのお話は環境構築スタートから検証内容確認までストレートな流れですが、実際には色々起こりました。順風満帆にはいかなかったけれど、おかげで初めて WindowsPCから Android11 をエミュレートしてモバイルノードを建てたりと新たな可能性に出会えました。心血を注ぐ必要はありましたが、今回得られた経験は行動しなければ得られなかった..。困った際に知恵を絞り、ググってググって先人の跡を辿り次のステップへと進んでいくことはとても楽しかったです。今回ここに書かせて頂いた内容も、初めてノードを建てた人、建てた時から同じ構成で続けてきて初めての環境引っ越しを考えられている人、そんな方々の参考になればとても嬉しいです。最後まで読んで頂いてありがとうございました🙏✨