接続し直せば、また戻ってくる——それが前提です。

バビロンのファイナリティ・プロバイダは、そんな簡単に手番をスキップできません。ファイナリティ・プロバイダは、将来のブロック高に向けて、公開ランダムネスをあらかじめバッチ単位でコミットしておく必要があります。これは些細なことではなく、EOTS署名が機能するための根本そのものです。TimestampingDelayBlocks は、そのコミットがどれだけ先に到達している必要があるかを定めており、推奨値は 10,000 ブロック超です。ランダムネス自体は、ビットコインでタイムスタンプが付けられるまで使えないためです。

事前にコミットしたウィンドウより長くオフラインになるFPは、投票を逃すだけでは済みません。完全に運用の余力が尽きます。

たとえば、あるプロバイダが高さ H までのランダムネスをコミットしていたとして、その後オフラインになり、H に 100 を足した時点で復帰するとします。これは、予定していた範囲の端を越えています。単に、投票を再開するだけでは済みません。新しいコミットを提出する必要があり、そのコミットも有効化される前に、BTCのタイムスタンプに追いつくのを待たなければなりません。停止と復旧という2つの遅延が、互いに重なって積み上がるのです。

最初は逆に感じました。私の前提は、稼働時間（アップタイム）が問題のすべてだということでした——ノードをオンラインに戻せば、それで仕事に復帰できる。ですが、アップタイムと投票資格は別の時計で動いており、後者は、障害が起こるはるか前、数日あるいは数週間も前に設定されていたのです。

つまり、オペレータとしての本当の耐障害性は「どれだけ速く再起動できるか」だけではありません。「何かが起きる前にどれだけ前倒しで計画していたか」です。これは、回復すべき障害がまだ一度も起きていない時点から、コンフィグ値に組み込まれた判断です。

障害の後に再び投票できる能力が、障害が起きる前に設定しておいたある数値で決まるのだとしたら、オペレータの「信頼できるアップタイム」という評判のうち、実際には事前に立てた賭けに過ぎない部分はどれくらいで、本当にその場での耐障害性がどれくらいなのでしょうか？

@BabylonLabs_io #baby $BABY