タスクを進めている途中で、統合ドキュメントを確認している際に何かに気づいた。Babylon、$BABY、#baby、@BabylonLabs_io——開発者向けの提案は明確だ：BSNとして参加し、コールドスタートのセキュリティ問題をスキップして、初日からBitcoinの重みを継承する。構造的には、これは本当だ。しかし、その背後にあるメカニズムは、一文で述べられているよりもはるかに条件に依存している。

問題は、新しいBSNにおけるBitcoinバックアップの最終確定が、デプロイ時にただ自動的に発生するわけではないということだ。2/3以上の委任されたBTCステークが、最終確定プロバイダーを通じてブロックに署名したときにのみ、それが達成される。そのしきい値が満たされるまで——これは、その特定のBSNの最終確定プロバイダーに委任されたBTCの量に完全に依存する——チェーンはCometBFTコンセンサスのみで動作する。ブロックは生成され、トランザクションは確認されるが、Bitcoinにアンカーされた最終確定レイヤーは非活性のままとなる。

先週、babylon.explorers.guruでこの状況を観察していた。最初のBSNであるBabylon Genesisは、このクォーラムを一貫して達成するための委任を保有している。毎時のBitcoinチェックポイントは着実に到着し、チェーンの状態は健全だ。しかしGenesisには56,000以上のBTCが裏付けとして存在している。新たなBSNが現在Phase-3として統合を開始する場合、自らの最終確定プロバイダーセットに新たに引き寄せるBTCの量からスタートする。

「Bitcoinセキュリティを継承する」とドキュメントが述べているため、自分自身で何度も確認した。技術的には正確だが、実際には「最終確定プロバイダーに十分なBTC委任を構築した時点で、初めてそれを継承できる」という意味に近い。まったく同じ文ではない。

セキュリティのコールドスタート問題は消えていない。ただ、その問題が一つ下のレイヤーに移動しただけだ。現在BSNを構築しているチームの多くが、ローンチ時の最終確定クォーラムがどのような形になるかをモデル化しているのか疑問に思う。