バビロンで最も難しい問題：FP はすでに BTC を委託されていますが、その行動をリアルタイムで監視できません。

私は以前、FP のすべての署名はチェーン上にあるのだから、正しい投票をしているかどうかはリアルタイムに検証できるはずだと考えていました。ところが実際に FP の監視の導線を深く掘り下げてみると、実は完全に別の2つの仕組みが存在することに気づきました。

FP が提出した署名記録は Babylon Genesis Chain に保存されています。誰が署名したか、どの高さで署名したか、どの BSN のブロックに署名したか――これらのデータはチェーン上で可視です。しかし「FP が正しい投票をしているかどうか」は、BSN が期待する挙動と照合する必要があります。FP が署名すべきだったのに署名していない、または即座に署名すべきなのに遅延した――こうした比較は、プロトコル層では強制されません。

言い換えると、Babylon は FP が「何をしたか」は記録しますが、「FP は何をすべきだったか」は記録しません。後者は BSN 自身が追跡するか、第三者の監視ツールに依存する必要があります。

この時間差が意味するのはこうです：ユーザーが FP の挙動に異常を見つけた頃には、FP はすでに数 epoch 分異常に稼働している可能性があることです。もしユーザーが大量の BTC を委託していれば、異常の発見から出金の申請、さらに unbonding 期間の終了まで――FP の異常ウィンドウは、ユーザーの想定よりずっと長くなり得ます。

これが、FP の運用履歴や評判が APY より重要である理由も説明します。APY は調整できますが、行動記録は変えられません。

また、ユーザーが複数の FP に同時委託している場合、各 FP の監視遅延は異なり、リスクはさらに積み重なります。

そのため、FP を選ぶ際には APY だけは見ません。見るのは次の3指標です。① FP に公開された投票参加率の記録があるか、② 異常行為の通知の遅延時間、③ 切り替えを決めてから新しい FP が有効になるまでの総運用コストです。

本当の試練は、委託時に FP がどれだけ信頼できそうに見えるかではありません。FP の挙動に異常が起きたとき、あなたがそれを見つけて離脱するまでにどれだけ時間がかかるかです。

@BabylonLabs_io $BABY #baby