バビロンの最終性プロバイダーダイモンのコードを読み進める中で、私が最も驚いたのは、オフラインであること、だますこと、あるいは遅いこととは無関係なのに、それでもプロバイダーを投票セットから完全に外してしまえる失敗モードを見つけたことでした。

最終性プロバイダーが、特定のバビロン・ジェネシスブロックに対して最終性署名を送信するには、その高さに対応するEOTSのランダムネス・ペアの公開側（public half）を、すでにコミットしている必要があります。そしてそのコミットは、ビットコイン上でタイムスタンプされ、最終化されたエポックの一部である必要があります。プロバイダーは事前にこれらのランダムネス・リストを生成し、バッチとして提出します。つまり、将来の投票能力を事前に予約しているのです。プロバイダーのオペレーターが、チェーンがブロックを生成している速さと、自分がコミットしたランダムネスがどこまで先に延びているかの関係を誤って見積もると、使えるコミットが尽きてしまい、ノードが完全にオンラインで正直に振る舞っていても、新しい高さに対して投票できなくなることがあります。

これは委任者として価格に織り込むには妙な種類のリスクです。エクイボケーションではなく、従来のダウンタイムでもなく、むしろ暗号的なコミットメントの仕組みの中に埋もれたスケジューリングの失敗に近いものです。多くの人がプロバイダーを選ぶ際に、その監査までは思い至りません。プロバイダーは稼働率ダッシュボード上ではまったく信頼できるように見えながら、静かにランダムネス枯渇へ近づいていくことがあります。

この特定の運用規律が、プロバイダーを比較する委任者に対してどれほど可視化されているのか気になります。見えてくるのは、すでに見逃し投票が発生した後、つまりそれが原因で初めて明らかになるものなのでしょうか。

$BABY @BabylonLabs_io #baby
#bank $KOMA $BANK #AppleChipShortageHurtsSalesForecast #KospiJumpsRecord15%