@BabylonLabs_io 私はバビロンの「スラッシング条件」がどのように書かれているかに、何度も立ち返ります。同じ高さで互いに矛盾する2つのブロックに、EOTSキーで署名すると、その数式そのものがあなたの秘密鍵を露呈させてしまうのです。委員会が審査するわけでもなく、投票で決まるわけでもありません。暗号がただ即座に作動するだけです。

その下にあるもののほうが、仕組みそのものよりも興味深いです。いまは、この発火を防ぐことを目的としたサードパーティのキー管理者の市場が存在します。なぜなら、このプロトコルには、不正をしたオペレーターと、クライアントソフトの不具合に見舞われたオペレーターとを分離する手段がないからです。「信頼不要、委員会なし」という売り文句はプロトコル層では本当ですが、現実世界での安全性は、最終性プロバイダがこれらのベンダーのいずれかを導入したかどうかに、部分的に依存するようになっています。それはチェーンに書き込まれたものではなく、民間企業の判断です。

最終性プロバイダを通じてBTCを割り当てる人にとって、それは現在あなたが確認できない変数です。ベンダーの導入状況は開示されず、標準化もされておらず、私が目にした流通中のデューデリジェンスのチェックリストにも含まれていません。

暗号学的な純粋さは、誰かの判断を信頼する必要を取り除くはずでした。ところが、判断を1層下に移しただけでした。つまり、誰も公開しないベンダー選定の領域へと。

委員会のないスラッシング条件にも、結局は委員会があります。違いは、誰がカバーされるかを決めるのがベンダー市場だという点です。

ここでの率直なギャップは、私は導入件数のデータも持っていないので、これは計測されたリスクというよりは構造上の指摘だということです。
#baby $BABY $BLESS $HOME
あなたの最終性プロバイダはEOTSキーの保護を運用していますか？