Payoutを阻止できることは、BTCの送付先を改変できることを意味しません

Trustless Bitcoin Vaults(TBV)では、Security CouncilがBTCを管理する多重署名を持っていると誤解されがちです。現在公開されているテストネットでは、5つのBitcoin公開鍵と3-of-5の法定人数を用い、公開鍵はバージョン化されたチェーン外(オフチェーン)プロトコルのパラメータに書き込まれ、共同でCouncilNoPayoutに署名します。これは特定のVaultのPayoutを止めることはできますが、BTCをCouncilが指定する新しいアドレスへ振り向けることはできません。

制約は、Vault作成時に固定されたBitcoin支出の図(フロー)から来ています。預金者はPayoutを事前署名し、正当な送付先を確定します。通常の退出、またはself-claimは、既存の条件に従って預金者のアドレスへ返るため、Councilの承認は不要です。清算ルートの場合のみ、認可されたApplication Vault Keeperのアドレスへ入ります。Councilの鍵は、この受取先の集合に含まれていないため、法定人数に達しても“阻断権”はあるものの、“資産の送付先変更権”はありません。

これは、challengerが通常の係争手順でブロードキャストするNo-Payoutとは異なります。後者は、有効でないClaimが争われ、そのうえで反証不能になったことに基づいています。CouncilNoPayoutは、標準メカニズムでは扱えない極端な障害や特別な復旧を想定したものです。Ethereum側のpauseはさらに別の層で、アプリケーションの動作を停止できますが、すでに存在するPre-PegInの返金(refund)やWOTSのself-claimの経路を書き換えることはできません。

CouncilNoPayoutは、私の評価基準を変えました。私はもはや「システムに委員会が存在するか」だけを問わず、「それによってBitcoinがどんな結果を受け入れ得るのか」を問うようになりました。支出を阻止できるなら、利用可能性や退出遅延のリスクはもたらします。新しい送付先を作れないなら、最悪の結果は資産のリダイレクトではなく“阻断”に限定されます。Councilの権限が悪用された場合でも、正当なPayoutが止められてしまう可能性はあります。さらにCouncilが連絡不能になれば、緊急復旧能力も低下します。この設計を「ゼロリスク」と書くことはできません。

@BabylonLabs_io はSecurity Councilを暫定的なセキュリティ・ネットとして定義し、プロトコルの成熟に伴って、その権限を段階的に退役させることを目標としています。真に注目すべきは、多重署名が存在するかどうかではなく、緊急権限がBitcoinの支出経路のどこまで制限されているかです。$BTC $ETH

$BABY
#baby