#baby $BABY 午前3時、Babylonのバリデーター向けドキュメントを読み終えたところで、EOTS鍵管理の節に目が留まりました。バリデーターは鍵を生成して保管する必要があると書かれていますが、どこに保管すべきかは書かれていません。

コミュニティでの議論を追っていくと、ある暗黙の前提が浮かび上がってきました。機関バリデーターの大半は、実際にはEOTS秘密鍵をHSMやMPCのカストディインフラに保管しているのです。Coinbase Custody、Figment――聞き覚えのある名前です。問題は、Babylonの理念が「Trustless」を土台としていることです。そしてTrustlessの第一原則は、ユーザーがいかなる仲介者も信頼する必要がないことです。

2024年11月、ある大手MPCカストディ事業者でしきい値署名の欠陥が見つかり、同一の攻撃者が2つのシェアを入手しました。2025年3月には、主要なHSMのファームウェアにサイドチャネル脆弱性があることが明らかになり、攻撃者が消費電力の分析によって鍵を抽出できることが判明しました。2026年1月には、あるカストディ事業者の監査で、運用エンジニアが退職前に顧客のシェアをバックアップしていたことが発覚しました。

これらの出来事はBabylonのコードとは無関係ですが、そのセキュリティモデルを根本から揺るがします。EOTSの巧妙な点は、秘密鍵が一度漏えいすると、攻撃者が最適なタイミングを待って、気づかれないまま資産を引き出せることです。Babylonのスラッシングの仕組みがどれほど洗練されていても、鍵がすでにオフチェーンで複製されていたら防ぎようがありません。

さらに不安なのは、ドキュメントがこの点について沈黙していることです。ホワイトペーパーを探しても、「鍵管理の透明性要件」も「カストディ事業者の認定制度」も「強制的なローテーション監査」条項も見当たりません。バリデーターは「分散型ノード」を運用していると主張しながら、秘密鍵を単一のカストディ事業者に預けることができます――ユーザーにはまったく知らされないまま。

「無添加」を謳うレストランなのに、厨房には既製品ばかり並んでいるようなものです。表向きはTrustlessでも、裏側は高度に中央集権化されています。EOTS秘密鍵がある機関のHSMに保管されているなら、「Bitcoin-secured」の実態は「カストディ事業者-secured」です。ユーザーが信頼しているのはビットコインの暗号技術ではなく、カストディ事業者のファイアウォールなのです。

ビットコインの改ざん耐性はオンチェーンにありますが、EOTSの脆弱性はオフチェーンにあります。Babylonは最も重い理念をオンチェーンに託す一方で、最も見えにくいリスクをオフチェーンのブラックボックスに残しています。カストディ事業者が事実上のセキュリティ境界になったとき、「Trustless」という言葉に、どれほどの重みがあるのでしょうか?

以上はあくまで個人の見解であり、投資助言ではありません。異なる意見はありますか?ぜひコメント欄でお聞かせください。
#baby BABY @BabylonLabs_io