Ripple をフル・ヒストリー（全履歴）モードで同期してみる【挫折編】
こんにちは。フレセッツ株式会社の日向です。
今年の夏も暑いですね。我が家ではエアコンが24/365の体制で常時稼働しています。会社にいる間は切ってもいいかなと思ったのですが、帰宅すると壁とか水道とか布団とかがその熱容量をフル活用して40度程度の熱を延々と放射するため、なかなか部屋が冷えない、という観測事実を発見しまして常時稼働となっております。暑くなってからマイニングは一時撤退したのですが、エアコンのせいでマイニングしているレベルの電気代の請求が来ています m9(^Д^)ﾌﾟｷﾞｬｰ
さて、雑談はこのくらいにしておいて本題に入りましょう。今回は送金システムの「Ripple」について、フル・ヒストリーモードでノードを建ててみたというお話です。
Ripple とは？
「Ripple (リップル)」とは、アメリカに本社を置く「Ripple, Inc.」によって開発が行われている送金（支払）システムです。Ripple システム上で用いる基軸通貨として「XRP（リップル）」と呼ばれる暗号資産（仮想通貨）が使われており、時価総額では BTC, ETH に次ぐ第三位のコインとなっております（※2019年8月時点）。
Ripple が他の暗号資産系プロジェクトと異なる点としては、（国際）送金に特化したシステムとなっている、ということです。国際送金システムとしては SWIFT が有名ですが、Ripple が本格的に使われ始めると SWIFT を置き換えるようなシステムになるのではないか、ということで日本を中心に注目されているプロジェクトとなります。
フル・ヒストリーモード
Ripple はソースコードおよびコンパイル済みバイナリが公式から配布されており、誰でも自由にノードを建てることができます。Ripple では「レジャー (Ledger)」と呼ばれる、ブロックチェーンで言うところの「ブロック」に対応した機構が存在し、世界に何十台か存在する「バリデータ (Validator)」と呼ばれるサーバがこのレジャーデータに対して承認を行う（電子署名を作成する）ことで、改ざんや二重支払いの防止といった暗号資産としての基本機能を提供します。いわゆる「コンソーシアム型」のブロックチェーン（※正確にはブロックチェーンではありませんが……）ですね。
Ripple のクライアント「rippled」を起動するとこのレジャーデータが P2P ネットワークを経由してダウンロードされ、最新の状態へのキャッチアップ が行われます。しかしながら Ripple ではトランザクション量が多く、レジャー番号0番からすべてのレジャーをダウンロードするのは非現実的です。そこで rippled ではデフォルトでは直近のレジャーのみをダウンロードするようになっており、それよりも古いデータについてはダウンロードを行いません。古いデータを捨ててしまうというのは Bitcoin の pruning (剪定) モードに似ていますが、Bitcoin の場合にはブロックチェーン全体をゼロからすべてダウンロードし、データの正当性をチェックしながら捨てるようになっており、古いレジャーデータを一度もダウンロードしない rippled とは少し方針が異なっております。当然、安全性を考えると、rippled でも全レジャーデータをダウンロードしてデータの正当性をチェックすべきではあるのですが、Bitcoin のようにパブリックで誰もが自由にブロックの生成に関与できるのと違い、Ripple はコンソーシアム型であり限られたノードしかレジャーを生成できませんから、遠い過去のデータを改ざんして不正をされてしまうことはないだろう、ということで古いレジャーのダウンロードをスキップしているのではないかと思います。
……が、しかし。
生粋のビットコイナー（※ビットコインなどの暗号資産を専業としている人たちのこと）としては、「バリデータを trust するなんてありえない！全データを自分自身の手で検証してこその非中央集権・分散システムだ！」という（過激な）思考を持ちたいわけで。
という訳で、今回は rippled をフル・ヒストリー（全履歴）モードで同期するための手順をご紹介します。
インストール
以下は Ubuntu/Debian での手順を示します。Mac OS の方は公式にビルドおよびインストール方法の手順が掲載されていますので、こちらをご参照ください。
- リポジトリを更新する:
$ sudo apt -y update - ユーティリティのインストール:
$ sudo apt -y install apt-transport-https ca-certificates wget gnupg - Ripple のパッケージ署名用 GPG 鍵を、信頼された鍵として登録する:
$ wget -q -O - “https://repos.ripple.com/repos/api/gpg/key/public" | \
sudo apt-key add - - 新しく追加された鍵のフィンガープリントを検証する:
$ apt-key finger
出力には以下のような Ripple のエントリーが含まれているはず:
pub rsa3072 2019–02–14 [SC] [expires: 2021–02–13]
C001 0EC2 05B3 5A33 10DC 90DE 395F 97FF CCAF D9A2
uid [ unknown] TechOps Team at Ripple <techops+rippled@ripple.com>
sub rsa3072 2019–02–14 [E] [expires: 2021–02–13]
特に、フィンガープリントが一致するかどうかを確認してください。（上記の例ではフィンガープリントは二行目にあり、C001 で始まっています） - お使いの OS バージョンに適した Ripple のリポジトリを追加する:
$ echo “deb https://repos.ripple.com/repos/rippled-deb bionic stable” | \
sudo tee -a /etc/apt/sources.list.d/ripple.list
⇧ 上記の例は Ubuntu 18.04 (Bionic Beaver) 向けのものであり、その他の OS バージョンをお使いの方は「bionic」と書かれているところを書き換えてください。 - リポジトリの更新:
$ sudo apt -y update - rippled のインストール
$ sudo apt -y install rippled - rippled サービスの状態をチェックする:
$ systemctl status rippled.service
rippled サービスは自動的に起動しているはずです。もしそうでない場合には、手動で起動することができます:
$ sudo systemctl start rippled.service
ブート時に自動的に起動するように設定する:
$ sudo systemctl enable rippled.service
インストール手順は以上となります。ビルド済みバイナリを含むリポジトリを用意してくれているので、インストールはかなり楽だと思います。
設定
さて、これで rippled のインストールができたわけですが、続いて rippled がフル・ヒストリーで同期するように設定してみましょう。手順は基本的に公式のドキュメントに従います。なお、以下で編集する設定ファイルのパスは「/etc/opt/ripple/rippled.cfg」となります。途中に「opt」が入るので、注意してください。
- rippled サーバを停止する。
$ sudo systemctl stop rippled - サーバの設定ファイル内の「[node_db]」節にある「online_delete」および「advisory_delete」の設定を消去する（かコメントアウトする）。また、「type」を NuDB に変更する。（ついでに path も変更しましょう。）
[node_db]
type=NuDB
path=/var/lib/rippled/db/nudb
open_files=2000
filter_bits=12
cache_mb=256
file_size_mb=8
file_size_mult=2
#online_delete=2000
#advisory_delete=0 - 「[ledger_history]」節を設定ファイルの末尾に作成し、「full」を指定する:
[ledger_history]
full - 「[ips_fixed]」節を設定ファイル末尾に追加する。
[ips_fixed]
169.55.164.20:51235
50.22.123.215:51235 - サーバ上の既存のデータベースファイルを削除する。
rm -r /var/lib/rippled/db/* - rippled サーバを起動する
$ sudo systemctl start rippled
モニタリング
上記の手順を正しく踏めば、rippled がフル・ヒストリーモードで起動し、P2P ネットワークを介して全レジャーデータがダウンロードされます。現在の同期状況を確認するためには、
$ rippled server_info
コマンドを実行します。正しく実行されるとやたら長い JSON 文字列が帰ってきますが、上の方にある「result.info.complete_ledgers」が現在同期済みのレジャー番号の範囲となります。試しに jq を使って取り出してみると、
$ rippled server_info | jq .result.info.complete_ledgers
Loading: “/etc/opt/ripple/rippled.cfg”
2019-Aug-21 03:41:29.063602152 HTTPClient:NFO Connecting to 127.0.0.1:5005“49184000–49487533”
なんか2個の数値データをハイフンで結合して文字列にしてるのは筋悪ですが、ともかく同期済みのレジャー番号が取得できました。
挫折
さて、上記の結果は rippled をフル・ヒストリーモードで起動してから5日間くらい放置していたマシンの状態なのですが、全体で約50Mレジャーあるのに対して、約0.3Mレジャー程が同期できている計算になります。％で表すと、0.6%……。5日で0.6%て……。このままだと約30ヶ月くらいかかりますね(ΦωΦ) 公式のドキュメントにも「Acquiring full history from the peer-to-peer network takes a long time (several months)」と「数カ月かかる」という記述があります。数ヶ月どころで済みそうにはないわけですが。
それではこの同期の遅さがどこでボトルネックになっているのかというと、サーバをモニタリングしている限りネットワーク回線（下り）を常時40〜50Mbpsほど使っているようで、ここがボトルネックになっているっぽいです。
サーバの置いてあるネットワーク環境は100Mbpsの光ファイバー (FTTH) 回線ですので、まぁまぁ回線はフルに使っているわけです。
公式のドキュメントには「2018年12月11日時点で、9TBほどのサイズになっており、このサイズは一日あたり約12GBずつ増えている」との記述があります。この事実が正しく、かつレジャーの増加量が現在も1日あたり12GBであると仮定すると、この記述がなされてから約250日が経過していますので、現在のダウンロード済みのレジャーサイズが 100GB ほど（※これは「$ du -hs /var/lib/rippled/db/」で確認できます）であることを考えると、同期完了までの日数をNとおけば、
9000GB+12GB/日×(250+N)日 = N日 × 50GB/日
が成立しますから、
N = 316日
となります。ほぼ一年ですね😱 回線速度がボトルネックとなっている以上、どうしようもなさげなんですが、どうしたらいいんですかね……。
また、そもそも頑張って同期したとしても数十TB程度のSSD（※HDDだと遅すぎてダメらしい）容量が必要なわけですが、それはどうやって用意したらいいんでしょうか……？
とりあえずこのまましばらく放置して様子を見ようと思います。何か進捗がありましたらまたこのブログで報告できればと思います。
おまけ：初期のレジャーデータが永久に失われている件
以前から噂としては聞いていたのですが、実は Ripple のメインネットのレジャーデータは初期の頃のデータが失われてしまっており、誰も復元することはできないようです。今回のこのブログ記事を書くにあたって、たまたま公式の資料にこの記述を見つけましたので、転載しておきます。
The earliest available ledger version in the production XRP Ledger’s history is ledger index 32570. The first two weeks or so of ledger history was lost due to a bug in the server at the time.
（日本語訳）本番 XRP のレジャー履歴の最も若い、入手可能なレジャーバージョンは、レジャー番号32570です。初期の約2週間のレジャー履歴は、当時のサーバのバグによって失われています。
ビットコイナー視点で見るとレジャーデータの正当性を誰も（Ripple 社の人でさえ！）100%確認する手段がない、というのはかなり致命的な気がしますが、コンソーシアムチェーンなのでそこはまぁ許されるんですかね……。
まとめ
送金（支払）システム「Ripple」の公式クライアント「rippled」をインストールし、フル・ヒストリーモードで同期をさせる手順を確認し、実行しました。しかしながら全履歴をダウンロードするには1年近い時間がかかるという試算となり、一般の方がちょっと試してみるというのはかなり難しいことが判明しました。
お知らせ
■fressetsは積極的に採用を行っています！詳細は下記のリンクからご確認下さい。
Link: https://fressets.com/careers/careers-416/
Link: https://fressets.com/careers/careers-0/
■ステーキング事業の提供を始めました！
7月からHashHubでは、Cosmos,Tezos,IOSTの3つのトークンをステーキング出来るサービス「Sanka Network」を提供し始めました。本サービスのご利用をご検討の方は、下記のWEBサイトからお問い合わせください。
Sanke Network：https://www.sanka.network/
■HashHubでは下記のポジションを積極採用中です！
・コミュニティマネージャー
・ブロックチェーン技術者・開発者
・ビジネスディベロップメント
詳細は下記Wantedlyのページをご覧ください。
Wantedly：https://www.wantedly.com/companies/hashhub/projects
■HashHubでは入居者募集中です！
HashHubは、ブロックチェーン業界で働いている人のためのコワーキングスペースを運営しています。ご利用をご検討の方は、下記のWEBサイトからお問い合わせください。また、最新情報はTwitterで発信中です。
HashHub：https://hashhub.tokyo/
Twitter：https://twitter.com/HashHub_Tokyo
