私の友人がかつてエスクローを説明しようとして、ロッカーのたとえを使いました。つまり、あなたが荷物を入れるロッカーを用意し、別の誰かが鍵を持っていて、相手が「返す」と言ったときに返してくれると信じる、というものです。私は彼に、「私が想像しているのも結局そういう話で、すべてのカストディアルな暗号（仮想通貨）のセットアップも、鍵に他人の手がかかったロッカーみたいなものだ」と答えました。でも、Babylonのバル ト（vault）の内部で、支出パスがどう作られるのかを追跡してみたら、その比較は私の中で崩れました。なぜなら、私が想像していたように“鍵が誰かに握られている”わけではないからです。預託者はバル トの作成時点で、ビットコインのスクリプトに事前に共同署名（コサイン）します。そして、BTCが将来どんな正当な形で移動し得るかというすべての出し方は、その時点で、預託者とプロトコル参加者たちによって共同で「存在する」ように署名されます。私は、@BabylonLabs_io がバル ト構築の手順を段階的に説明していたスレッドを読み進めて、それを理解したのです。

後から差し込める裏口はありません。いったんバル トが存在すれば、プロトコルでも、バリデータ集合でも、将来のガバナンス投票でも、まったく新しい支出条件を発明することはできません。有効な署名セットは最初に固定されており、その後の事実によって拡張される余地がないからです。見落としやすいポイントは、これは「プロトコルが資金を悪用しないと約束する」という話ではなく、「事前に署名されたものの外で取引を構築するための機械的な手段がプロトコルに存在しない」ということです。これは、多くのカストディアルまたはマルチシグ・ブリッジのセキュリティモデルとは別物です。そこでは通常、鍵やしきい値をデプロイ後に調整できるように、柔軟性を意図的に残していることがあります。アップグレードのためには便利ですが、その“継ぎ目（seam）”が、結果的に悪用されてしまうことが多い。

それでも私がまだ描けないのは、もう少し厄介な状況――スラッシング条件が発動する場面、タイムロックが期限切れになる場面、バル トのライフサイクルの途中で参加者集合が入れ替わるような場面――そうしたものに対して、この硬直性がどう保たれるのかという点です。新しいパスが増えないのに、システムは適応し続ける必要がある、というのは緊張関係にあるように感じます。だから設計原則そのものは筋が良い、想像していたより保守的だと思う一方で、エッジケースの挙動については、@BabylonLabs_io がまだ私に実地で見せてくれていません。

#BABY $BABY @BabylonLabs_io #IntelRises9%AfterHours $COTI $ON #USStorageStocksExtendLosses
バル トの安全性は主に？