5年運用した自作仮想通貨とマイニングプール復旧記

はじめに

2019年4月にスタートしたこのプロジェクト。DASHをベースにした自作コイン、マイニングプール、ブロックチェーンエクスプローラー、そしてマスターノード。すべて自分で構築し、5年半もの間、ほぼノーメンテで動き続けていた。

しかし、今回のOSアップグレードで予想外のトラブルが続出。最終的にすべて解決するまでの長い1日の記録をここに残す。

プロジェクト概要

構成

• 仮想通貨：UkkeyCoin（DASHベース、マスターノード対応）
• マイニングプール：ukkey3-nomp（Node.js製）
• エクスプローラー：Iquidus Explorer
• サーバー台数：3台（プール、エクスプローラー、マスターノード）
• 稼働期間：2019年4月〜現在（5年半）
• 前回メンテ：2022年10月（3年前）

第一章：OSアップグレードの決行

基本的なアップグレード手順

まずは王道の手順で進める。

# システムを最新状態に
sudo apt update
sudo apt upgrade
sudo apt full-upgrade

# 保留パッケージの処理
sudo apt install cloud-init

# クリーンアップ
sudo apt autoremove
sudo apt autoclean

# 再起動
sudo reboot

# アップグレード開始
sudo do-release-upgrade

トラブル1：ModuleNotFoundError地獄

しかし、そう簡単には終わらなかった。

$ sudo do-release-upgrade
Traceback (most recent call last):
  File "/usr/bin/do-release-upgrade", line 8, in <module>
    from DistUpgrade.DistUpgradeVersion import VERSION
ModuleNotFoundError: No module named 'DistUpgrade'

一つずつ地道に解決していった。

# DistUpgradeモジュールを再インストール
sudo apt install --reinstall python3-distupgrade python3-update-manager

# distro_infoモジュールの問題
sudo apt purge python3-distro-info
sudo apt install python3-distro-info

# lsb_releaseモジュールの問題
sudo apt install --reinstall lsb-release

3つのエラーを解決し、ようやくアップグレードが開始した。

第二章：設定ファイルとの戦い

アップグレード中、何度も設定ファイルの上書き確認が表示される。

重要な判断ポイント

• libc6の自動再起動：「Yes」を選択（毎回確認されるのを防ぐ）
• SSH設定ファイル：「現在の設定を維持」（カスタムポート設定を保持）
• Nginx設定ファイル：「現在の設定を維持」（カスタマイズした設定を保持）

SSH接続の保険：ポート1022

SSH経由でアップグレードを実行すると、自動的にポート1022に予備のSSHデーモンが起動する。これがトラブル時の命綱となる。

# ファイアウォールでポート1022を開放
sudo ufw allow 1022/tcp

# 万が一メイン接続が切れても、こちらで再接続可能
ssh -p 1022 user@server-ip

第三章：1台目の成功、そして2台目へ

$ lsb_release -a
Distributor ID: Ubuntu
Description:    Ubuntu 22.04.5 LTS
Release:        22.04
Codename:       jammy

勢いに乗って2台目も同じ手順で進める。1台目の経験があるため、2台目はスムーズに完了。

第四章：MongoDB互換性問題との遭遇

エクスプローラーサーバー（2台目）でIquidus Explorerを起動しようとしたところ、MongoDBが起動しない。

$ sudo systemctl status mongod
× mongod.service - MongoDB Database Server
     Active: failed (Result: exit-code)

ログを確認すると、決定的なエラーメッセージが。

Failed to start up WiredTiger under any compatibility version. 
This may be due to an unsupported upgrade or downgrade.

原因：データベースファイルの互換性

Ubuntu 20.04で使用していたMongoDB 3.6のデータファイルが、新しくインストールされたMongoDB 6.0と互換性がない。アップグレード中にMongoDBが自動削除され、再インストールされた結果、古いデータファイルが読めなくなっていた。

解決方法：データベースのリセット

# MongoDBを停止
sudo systemctl stop mongod

# 古いデータをバックアップ
sudo mv /var/lib/mongodb /var/lib/mongodb.backup

# 新しいデータディレクトリを作成
sudo mkdir /var/lib/mongodb
sudo chown -R mongodb:mongodb /var/lib/mongodb

# MongoDBを起動
sudo systemctl start mongod

MongoDBは起動したが、ユーザーとデータベースが消えているため、再作成が必要だった。

# MongoDBシェルに接続
mongosh

# データベースとユーザーを再作成
use explorerdb
db.createUser({
  user: "ユーザー",
  pwd: "パスワード",
  roles: [{role: "readWrite", db: "explorerdb"}]
})

第五章：3台目、そしてマイニングプール復旧への長い道のり

トラブル2：OpenMPI依存関係エラー

3台目のアップグレード中、突如エラーが発生。

Exception during pm.DoInstall(): E:Sub-process /usr/bin/dpkg returned an error code (1)

処理中にエラーが発生しました:
 openmpi-bin
 libboost-all-dev
 (その他多数...)

`update-alternatives` の設定が壊れていた。

# 壊れたalternativesファイルを削除
sudo rm /var/lib/dpkg/alternatives/mpi

# 問題のあるパッケージを強制削除
sudo dpkg --purge --force-all openmpi-bin

# 依存関係を修復
sudo apt --fix-broken install

第六章：マイニングプール、起動せず

OSアップグレードは完了。さあ、マイニングプールを起動しよう。

$ cd ~/ukkey3-nomp
$ npm start

トラブル3：getblocktemplate地獄

デーモンは完全に同期しているはずなのに、`getblocktemplate` RPCがエラーを返す。

$ ukkey-cli getblockchaininfo
{
  "blocks": 1932920,
  "headers": 1932920,
  "verificationprogress": 1
}

$ ukkey-cli getblocktemplate
error code: -10
error message: Ukkey Core is downloading blocks...

完全に同期しているのに「まだダウンロード中」と言われる。謎だった。

原因究明：マスターノード同期の罠

プールのソースコードを追跡していくと、`getblocktemplate` を呼び出す前に `IsInitialBlockDownload()` という関数でチェックしていることが判明。

さらに、DASHベースのコインでは、マスターノード同期も完了している必要があった。

$ ukkey-cli mnsync status
{
  "AssetName": "MASTERNODE_SYNC_INITIAL",
  "IsSynced": false
}

マスターノード同期が完了していない！

解決への試行錯誤

マスターノード同期を手動で進めてみる。

ukkey-cli mnsync reset
ukkey-cli mnsync next
ukkey-cli mnsync next
ukkey-cli mnsync next

$ ukkey-cli mnsync status
{
  "AssetName": "MASTERNODE_SYNC_FINISHED",
  "IsSynced": true
}

同期完了！これでいけるはず。

$ ukkey-cli getblocktemplate
error code: -10
error message: Ukkey Core is downloading blocks...

真の原因：最後のブロックが古すぎる

ログとソースコードを詳細に調査した結果、`IsInitialBlockDownload()` が「最後のブロック時刻が古すぎる」と判断していることが判明。

最後にマイニングされたブロックは約19時間前。誰もマイニングしていない状態が続いていたため、デーモンが「まだ初期ダウンロード中」と誤認識していた。

解決の鍵：新しいブロックのマイニング

$ ukkey-cli getblocktemplate
{
  "version": 536870912,
  "previousblockhash": "...",
  "transactions": [...],
  ...
}

ついに動いた！

第七章：プール起動、そしてブロック発見

$ cd ~/ukkey3-nomp
$ npm start

[Pool] [ukkeycoi] Stratum Pool Server Started for ukkeycoin [UKY] {yespower}
                  Network Connected:      Mainnet
                  Current Block Height:   1932924
                  Network Hash Rate:      0.07 KHash
                  Stratum Port(s):        3001

第八章：マスターノードとSentinelの復旧

プールは動いたが、マスターノードがまだ起動していない。

Sentinelの環境再構築

DASHベースのマスターノードには、監視ツール「Sentinel」が必要。Python 3.10への移行で動かなくなっていた。

cd /home/mobile/sentinel

# 古い仮想環境を削除
rm -rf venv

# Python 3.10で仮想環境を再構築
python3 -m venv venv
source venv/bin/activate

# 依存関係の問題を解決
nano requirements.txt
# peewee==2.8.3 を peewee>=3.14.0 に変更

pip install -r requirements.txt

マスターノード起動の試練

マスターノードの起動には、コントローラーウォレット（担保を持つウォレット）からのコマンド実行が必要。しかし、PCのウォレットが同期中で使えない。

暫定対応として、Sentinelのcronを停止し、PCウォレットの同期完了を待つことにした。マスターノード報酬は一時的に受け取れないが、プール運営には影響しない。

第九章：Wallet.datの肥大化問題

$ ukkey-cli dumpwallet wallet_dump.txt
{
  "keys": 410112,
  "warning": "wallet_dump.txt file contains all private keys"
}

41万個のキー！

5年半のマイニング報酬の蓄積により、大量の小さなUTXO（未使用トランザクションアウトプット）が生成されていた。

コイン統合作業

すべてのコインを新しいアドレスに送金してUTXOを統合することに。

# 新しいアドレスを作成
ukkey-cli getnewaddress "consolidated"

# 分割して送金（一度に送ると巨大すぎる）
ukkey-cli sendtoaddress "新アドレス" 23000
# 確認を待って繰り返し...

トランザクション作成に時間はかかったが、着実に統合作業が進んでいる。

最終章：5年半の軌跡

学んだこと・まとめ

技術的な学び

• DASHベースのgetblocktemplate問題：`IsInitialBlockDownload()` とマスターノード同期の両方が必要
• MongoDB互換性：メジャーバージョンアップ時はデータ移行が必要
• Python依存関係：OSアップグレード時は複数のモジュールエラーに注意
• SSH設定の保持：本番環境でのカスタム設定は必ず維持
• Wallet肥大化：定期的なUTXO統合メンテナンスが重要

運用の学び

• バックアップの重要性：すべての作業前にバックアップ必須
• 段階的アプローチ：1台ずつ確実に進める
• ログの重要性：問題解決の鍵はログにある
• コミュニティの力：別のプールでのマイニングが救世主に

ブロックチェーンの素晴らしさ

5年半、ほぼノーメンテで稼働し続けたこのシステム。ブロックチェーン技術の堅牢性と、分散型システムの強さを改めて実感した。

• 単一障害点がない設計
• 自律的な稼働
• 透明性とトレーサビリティ
• コミュニティによる相互支援

エピローグ

今後の課題

• PCウォレット同期完了後のマスターノード起動
• Wallet統合作業の完了
• 定期メンテナンススケジュールの確立
• 監視・アラートシステムの構築

長い1日だった。しかし、充実した1日でもあった。

5年半前に作ったシステムが、今日も、そしてこれからも動き続ける。それが何よりも嬉しい。

---

※ 本記事は実際の復旧作業を基にしていますが、一部時系列やエラーメッセージは読みやすさのため編集しています。