スクロールを止めさせたのは、バグそのものではありませんでした。レースウィンドウは「データベースの読み取りとデータベースの書き込みの間にしか存在しない」と書かれている行でした。最初は些細な実装上の詳細に見えましたが、Babylonの実行モデルについて考え始めると、そう見えなくなっていきました。

私は攻撃者を探すのをやめて、代わりにフローを見始めました。検証パスを見比べて、状態が実際に最終化されるのはどこかをしばらく追跡しました。次にコーヒーを淹れて、もう一度そのシーケンスを読み直しました。見れば見るほど、これは単なるセキュリティ問題というより、プロトコルが許容するタイミング上のリスクの大きさについての設計上の選択に思えてきました。

ゆっくりと明らかになったのは、保護が「レースを不可能にする」ために作られているのではない、ということです。「機会（チャンス）を極端に小さくする」ために作られているのです。これは2つの別の考え方です。1つ目は条件を取り除きます。2つ目は確率を減らします。この違いは、どちらも外から見ると安全そうに見えるため、見落としやすいのです。

誰もデッキには載せないのはその部分です。Babylonは、実行上のごく小さなギャップがなお存在し得ることを受け入れつつ、バリデータとサービスが状態を予測可能な順序で処理することに依存しています。プロトコルは実質的に、「考え得るあらゆるレースをすべて取り除くための運用コストのほうが、1つの細いウィンドウを残すことによる残余リスクよりも大きい」ということを言っているに等しいのです。

パフォーマンスのためなら、それが正しいトレードオフなのかもしれません。残っている露出が非常に小さく、そのために追加の同期を入れると、別の場所でより大きな問題が生じてしまうのかもしれません。

しかし私がまだ決められないのは、Babylonが「許容できるタイミング前提」と、「タイミングに一切依存してはいけないプロトコル上の保証」の境界線をどこに引いているのか、という点です。
@BabylonLabs_io
#baby $BABY