かつて私は、バビロンの最大のブレイクスルーは単純だと思っていました。

「BTCは誰にもカストディを渡さずにステークできる。」

それは事実です――しかし、その裏にもっと面白いアーキテクチャ上の依存関係があります。

私はバビロンが実際にどうやってBTCをスラッシュ可能にしているのか、さらに深く調べました。

BTCはビットコイン上にそのまま残り、UTXO、タイムロック、暗号学的な条件を使います。ファイナリティ・プロバイダーは、EOTSを用いて矛盾する投票をスラッシュ可能にします。

しかし、ビットコインの現在のスクリプトモデルでは、バビロンが要求するステーキング規則をネイティブにすべて強制することはできません。

そのため、バビロンは現在、カヴナント・コミッティ（誓約委員会）を使っています。

その委員会はM-of-Nの署名者セットで、ステーキング取引に共同署名し、次のようなルールを強制します：

• スラッシング率
• スラッシングの送付先
• 最低アンボンド（解除）期間

これによって「トラストレスなBTCステーキング」という解釈が変わります。

BTC保有者は自己カストディのままでいられますが、プロトコルの強制レイヤーの一部は、現状ではビットコインのコンセンサス規則の外側で実装されています。

そしてこれは単なる机上の構想ではありません。バビロン自身のドキュメントには、ビットコインが必要なプログラマビリティを備えていないため「当面の間」委員会が必要だと書かれています。委員会のメンバー構成はバビロンのパラメータによって管理され、変更にはガバナンスが必要です。

反論点は重要です。

これはバビロンが従来型のカストディブリッジになるという意味ではありません。委員会は単にユーザーのBTCを保管するだけではなく、あらかじめ定義された取引条件を強制します。さらにバビロンは、ビットコインが適切なカヴナント機能を獲得すれば、委員会を最終的に削除できるようにも設計しています。

つまり、この委員会は恒常的な弱点としてはあまり面白くない一方で、アーキテクチャ上の移行としてはより面白い存在になります。

そこで結論も変わりました：

バビロンの本当の実験は、おそらく「ビットコインが、ビットコイン自身がそれをネイティブに強制できるほど十分にプログラマブルになる前に、プログラマブルな経済的セキュリティを提供できるかどうか」かもしれません。

そして残る疑問は1つです：

#BABYBONK $BABY @BabylonLabs_io