#dusk $DUSK @Dusk
最初は、ノードのリカバリというのは、何かが起きた後になって初めて重要になる“退屈なインフラの細部”の一つだと思っていました。ノードがオフラインになる、再同期する、追いつくのを待つ、そして最終的にすべてが元通りになる——そんな単純な話です。

しかし、Duskのようなネットワークでリカバリがどう機能し得るのかを深掘りするほど、その前提は思ったより単純ではないと感じるようになりました。

ノードを素早くオンラインに戻すことは有用ですが、スピードだけでは本当の問題は解決しません。もしノードがスナップショットから状態を復元するなら、より重要な問いは「復元された状態は本当に信頼できるのか」という点になります。

それが、私のリカバリに対する考え方を変えました。

ブロックチェーンのノードは、単に古いデータを読み直して、何も起きていないかのように再開できる“別のアプリケーション”ではありません。ノードが返してくる状態は、その後に起こるすべての土台になります。リカバリが速くても、復元された状態を適切に検証できないのであれば、その便利さは価値が薄れて見えてしまいます。

私が興味深いのは、リカバリ時間と完全性のトレードオフです。

最近の状態があれば、通常のノードは最初からすべてを作り直す手間を避けられますが、それが必ずしも、過去のすべての詳細が同じ形で利用できることを意味するわけではありません。ある運用者にとっては、すぐにオンラインへ戻れることが十分かもしれません。ですが、特に完全な履歴データが重要なケースでは、より速い近道が、完全なリカバリ手順の代わりになるとは限りません。

この違いが納得できるのは、すべてのノードが同じ課題を解決しているわけではないからです。

考えれば考えるほど、良いインフラの本当の価値は、そもそも障害を完全に避けることにあるとは限りません。ネットワークは停止することがあり、ハードウェアは故障します。そしてデータは利用不能になることもあります。

難しいのは、その“後”に何が起きるのかです。

ネットワークは、速度・履歴・信頼のどれかを運用者に選ばせることなく、迅速に回復できるのでしょうか？

それは、単にノードがどれだけ速くオンラインに戻れるかを測るよりも、はるかに重要なインフラの試験のように思えます。