Babylon型Bitcoinステーキングのリスク｜ブリッジなしでもBTCを失う道

ある暗号資産のカストディ会社が、預かっているBTCでBitcoinステーキングを始め、顧客に報酬を届ける商品を検討しています。候補はBabylon型の仕組みです。BTCをブリッジで別のチェーンへ移さず、Bitcoinの上でロックしたまま使えます。

社内の会議で、事業の責任者が聞きました。「ブリッジを使わないのなら、BTCを失うことはないのでは？」

ブリッジを使わないことで、減る心配は確かにあります。第三者がいつでも自由に送金できる預かり口座に、BTCを預けるわけではないからです。許された取引の形と署名の条件を、先にBitcoinの上に書き込んでおく仕組みです。

それでも、BTCを失う道は残ります。大きく分けて次の3つです。

• 委任先の違反：委任した先（Finality Provider）が二重に署名すると、BTCの一部が没収される（スラッシング）
• 自分の側の誤り：自分の鍵をなくしたり、取引の組み立てを誤ったりすると、引き出せなくなる
• 上に重ねた商品：ステーキングの上に重ねるBTCfiの商品に、別のリスクがある

どの道が起こりえて、どこまで失いうるか。それは、Bitcoinの上の引き出しの条件、委任先の運用、抜けるときの手順を分けて確かめれば判断できます。以下では、このカストディ会社が確かめていく順に見ていきます。

この記事でわかること

• 普通のステーキングとの違いと、ロックしたBTCを引き出す3つの道
• 委任先の二重署名が、なぜ自分のBTCの没収につながるのか
• 「ブリッジなし」でも残る8つのリスクと、導入してよいかの5つの条件

Bitcoinとブロックチェーンの基礎はブロックチェーンとビットコイン活用法で解説しています。

仕組みを評価するときに確かめる場所は、次の4つです。

• Bitcoinの上で、ロックしたBTCをどんな条件で引き出せるか（支出の条件）
• Babylon Genesisの上での登録と、委任先（Finality Provider）
• コベナントの委員会と、監視のサービス
• 報酬を払うネットワーク

普通のステーキングと違い、BTCはBitcoinに置いたまま別のネットワークを守る

一般的なPoS（Proof of Stake）では、そのチェーンの資産を、同じチェーンのステーキングの機能やスマートコントラクトに預けます（ボンド）。そしてバリデーターが、そのチェーンのブロックを検証します。

一方、BitcoinはProof of Workです。BTCを持つ人が、Bitcoinのブロックづくりに対してステークする機能は、もともとありません。

そこでBabylonのBitcoinステーキングは、別のやり方をとります。BTCをBitcoinの上で条件付きでロックし、それを担保にして、Babylon GenesisやBitcoin Supercharged Network（BSN）といった別のネットワークを守る役目に使う仕組みです。

BTCは、BitcoinのUTXOとして持たれたままです。ただし、登録、委任、投票、違反の見つけ出し、報酬の配分は、Bitcoinだけでは完結しません。Babylon公式のarchitectureも、Bitcoinのスクリプト、Babylonのノード、Finality Provider、周りのサービスからなる、何層にもなった構成として説明しています。

普通のステーキングとの違いは、次のとおりです。

ロックしたBTCを引き出す道は、3つある

ステーキングの取引は、BabylonのステーキングスクリプトをTaproot（Bitcoinの出力の形式の1つ。複数の使い方の条件を1つの出力にまとめられる）の出力に組み込んで、Bitcoinの上に作ります。

公式のBitcoin Staking Transactions Specificationでは、支出の条件に次のものが組み込まれます。ステーカー、Finality Provider、コベナント委員会の公開鍵。ステーキングの期間。コベナントの署名が何人分そろえばよいか（quorum）などです。

ロックしたBTCを使う道は、次の3つです。

1. タイムロックの道：ステーキングのときに決めた相対タイムロック（取引が取り込まれてから数えるタイムロック）が明けると、ステーカーの署名だけで引き出せる。外部のサービスが止まっても、Bitcoinが動いていて鍵を持っていれば、最後の出口が残る設計です。
2. 途中で解除する道：期間が明ける前に、アンボンディング（解除）用の取引を実行し、より短い解除待ちのタイムロックへ移す。ステーカーの署名に加えて、事前に集めたコベナント委員会の必要な人数分の署名が要ります。
3. スラッシングの道：ステーカーが事前に署名したスラッシング用の取引に、違反したFinality Providerから取り出された鍵と、コベナント委員会の署名を加えて有効にする。出力の一部はバーン（焼却）され、残りは解除待ちの期間の後にステーカーが取り戻せる形です。

この仕組みでは、許された取引の形と署名の条件を、先にBitcoinに書き込みます。一方で、スクリプト、設定値、事前に署名する取引、署名を保管・配布するソフトウェアのどれかを誤ると、自分で鍵を持っていても、思ったとおりに抜けられません。

登録から引き出しまで、どんな状態を通るか

Bitcoinの上に取引を作っただけでは、委任も報酬も有効になりません。Babylonの側での登録と、Bitcoinでの取り込みの確認が必要だからです。公式のBitcoin Stake Registrationにもとづくと、ステークはおおよそ次の順に進みます。

1. 登録待ち・確認済み：登録のメッセージを送り、コベナントの署名を得る。
2. 有効：Bitcoinへの取り込みが、決められた深さ（何ブロック後まで積み重なったか）に届く。
3. 解除中：アンボンディング用の取引がBitcoinに取り込まれる。
4. 引き出し可能：ステーキングか解除待ちのタイムロックが明ける。
5. 没収：違反の証拠がそろい、スラッシング用の取引が成立する（違反があった場合）。

それぞれの段階で止まる原因があります。設定値の食い違い、署名の不足、承認の遅れ、ブロックの巻き戻り（再編成）、手数料の不足、監視サービスの遅れなどです。状態ごとの原因と、残す記録は後半の表にまとめています。

カストディの画面で、これらをまとめて「ステーキング中」と1つで表示したとします。すると、Bitcoinの上のロック、Babylonの側の登録、投票力、報酬の対象、引き出せる時刻のずれが隠れてしまいます。

ですから社内の台帳では、これらを別々の項目にします。さらに、Bitcoinのブロックハッシュを含む「巻き戻りで変わりうる観測値」と、「業務の上で確定した状態」も分けておきます。

委任先の二重署名が、なぜ自分のBTCの没収につながるのか

Finality Providerは、Babylon Genesisのブロックに、「このブロックで確定してよい」という投票を送ります。このとき使うのが、EOTS（Extractable One-Time Signature）という署名です。1回限りの署名で、使い方を誤ると秘密鍵が取り出せてしまう、という性質を持ちます。

具体的には、同じ高さの別々のブロックに、同じ乱数を使って署名したとします。すると、2つの署名から、EOTSの秘密鍵を取り出せます。その鍵があれば、委任ごとに事前に署名してあるスラッシング用の取引を完成させられます。こうして、別のチェーンでの違反が、BitcoinのUTXOの損失につながるのです。

問題は、悪意がなくても二重署名が起きうることです。Babylon公式のslashing protectionとFinality Providerの運用ガイドは、ハードウェアの故障やソフトウェアの不具合でも、まじめな運用者が二重署名の危険にさらされると明記しています。

委任先のソフトウェアは、二重に署名しないための記録を持っています。投票を管理するソフトウェア（fpd）は、最後に投票した高さを覚えています。署名を担うソフトウェア（eotsd）は、同じ高さで別の中身に署名し直すことを断ります。

ですから、その記録を壊すような操作が危険になります。

• データベースのバックアップを無造作に戻して、2台同時に起動する
• 複数の拠点で同時に動かす
• 壊れた保存データから復旧する

これらは、単に「止まるかどうか」の問題ではなく、元本を失うリスクです。委任先を選ぶ側から見れば、評価すべきはこうした運用の中身です。鍵の分け方などの具体的な手当ては、後半にまとめています。

「ブリッジなし」でも残る8つのリスク

冒頭の3つの道に分けて並べると、次のとおりです。

委任先の違反

1. スラッシング：委任先の二重署名で、BTCの一部を失いえます。バックアップから戻して2台同時に起動した、複数の拠点で同時に動かした、といった運用の誤りでも起こりえます。運用者の名前や過去の稼働率だけでなく、二重署名を防ぐ仕組みの状態と、復旧の手順を評価します。

自分の側の誤りと、周りの仕組み

2. スクリプトと取引の作り方：ステーキングの期間、金額、公開鍵、ネットワーク、出力の番号が食い違うと、登録を断られたり、資金がロックされたままになったりします。署名の前に、別の実装で生の取引を読み解いて確かめます。
3. コベナントへの依存：委員会の署名は、不正な形の取引を防ぎます。一方で、署名が遅れたり委員会が動かなかったりすると、登録やアンボンディングに響きます。タイムロックの道が、最後の出口として使えることを確かめます。
4. Bitcoinの巻き戻り・手数料：決められた深さに届く前に巻き戻りが起きると、証明と状態が戻ることがあります。引き出しやスラッシングも、Bitcoinのブロックの容量と手数料の相場に左右されます。
5. 監視・中継のサービス：取り込みの証明、アンボンディングの検知、違反の証拠の中継が遅れると、BitcoinとBabylonの表示がずれます。第三者の監視サービスだけに頼らず、自分で送り直せるようにします。
6. 鍵の管理：ステーカーの鍵をなくすと、タイムロックが明けた後に取り戻せません。委任していても、引き出し用の鍵のバックアップ、署名の方針、相続・災害のときの復旧は必要です。

報酬と、上に重ねた商品

7. 報酬の出どころ：報酬は、Bitcoinのブロック報酬から自動で生まれるわけではありません。対象のBSNのインセンティブ、トークン、手数料、委任先の手数料率、配る条件を別に評価します。
8. 上に重ねるBTCfi：リキッドステーキングトークン、ボールト、レンディング、ラップドBTCを重ねると、別のリスクが加わります。スマートコントラクト、オラクル、ブリッジ、流動性、価格のずれ（デペッグ）、保管業者のリスクです。ネイティブなステーキングの安全の範囲を、そのまま引き継ぐとは限りません。

導入してよいかを、5つの条件で判断する

Babylon型のBitcoinステーキングには、ラップドBTCを発行してブリッジの保管に移す方式とは違う、設計上の利点があります。ただ、ここまで見てきたとおり、リスクはBitcoinの取引だけでなく、何層にもまたがっています。

ですから、比べる単位は「ネイティブかラップドか」の2択ではありません。次のものを、1つの依存関係の図として評価します。ステーカーが署名するBitcoinの取引。コベナント委員会。委任先のEOTSの運用。両方のチェーンをつなぐ監視サービス。報酬を払うBSN。さらに上に重ねるBTCfiの商品です。

導入の前に、最低限次の5つを満たしているかを確かめます。

• 生の取引と支出の道を、自社で確かめられる
• スラッシングの条件と最大の損失を、利用者の台帳に反映できる
• 外部のサービスが止まっても、タイムロックが明けた後の取り戻しを再現できる
• 報酬の出どころと、追加のトークンのリスクを分けて表示できる
• 設定値やリリースの変更に気づける

これらを満たせないなら、年利（APR）が高くても、カストディの商品に組み込む段階ではありません。

ウォレットの鍵の階層、署名の承認、入出庫の台帳を先に整理するならブロックチェーンウォレットの導入・開発と運用設計、機関向けの保管の設計全体は機関投資家向け暗号資産カストディ設計、ステーキング報酬の設計はステーキング・ファーミングで長期参加を促すインセンティブ設計を参照してください。

実装する人向けの詳細

ここからは、このカストディ会社やBTCfiのプロトコルで、仕組みを作る開発者向けの話です。

ステークの状態遷移

Finality Providerの鍵と二重署名の防ぎ方

運用では、EOTSの鍵、Babylon Genesisの鍵、日常の運用の鍵を分け、fpdとeotsdを別のホストか別のネットワーク区画に置きます。次の手当ても設けます。

• EOTSのRPCへの認証
• 書き込む主体を1つに限るリース（期限付きで書き込み役を1台に割り当てる仕組み）
• 起動前のデータベースの整合性の検査
• 投票した高さの外部からの監視

公式のFinality Provider Operationによれば、EOTSの鍵は登録後に変えられず、Babylon Genesisの鍵と永久に対になります。そのため、鍵を定期的に取り替える前提の設計は使えません。

カストディ・プロトコルの実装で固める統制

PSBTは、署名する前の取引を関係者のあいだで受け渡すための形式です。

本番に入れる前の再現試験

新しい設定値やソフトウェアのリリースを本番に入れる前に、試験用のネットワーク（signet・regtest）か限られた金額で、次の場面を再現します。

• ふだんの引き出し、途中での解除（アンボンディング）
• Bitcoinの巻き戻り、証明の中継の停止
• Finality Providerの一時停止（jailed）・スラッシング、コベナントの遅れ

特に、BabylonのAPIにACTIVEと出たことだけで、カストディ台帳の利用可能残高を変えないようにします。

XTELAができること

私たちは、Bitcoinステーキングのプロトコル調査、署名前のトランザクション検証、鍵・ノード・監視サービスの責任の分け方、カストディ台帳との照合を設計・開発します。signetや限定額で引き出し・アンボンディング・再編成を再現するPoC（概念実証）から始め、貴社の商品に組み込めるかを一緒に見極めます。ご相談はお問い合わせからどうぞ。

主要参考資料

• Babylon Labs: Bitcoin Staking Transactions Specification（2026年9月24日確認）
• Babylon Labs: Bitcoin Stake Registration（2026年8月12日確認）
• Babylon Docs: Architecture（2026年8月12日確認）
• Babylon Docs: Finality Provider Overview（2026年8月12日確認）
• Babylon Docs: Slashing Protection（2026年8月12日確認）
• Babylon Labs: Finality Provider Operation（EOTS鍵が登録後に変更できない旨、2026年9月24日確認）
• Babylon Labs: babylon source repository（2026年8月12日確認）

資料の確認日と注意

一次資料は2026年8月12日に確認しました。支出の道とFinality Providerの鍵の扱い（EOTSの鍵が登録後に変えられないことを含む）は、2026年9月24日に確認し直しています。内容は公開された仕様にもとづく技術・運用の整理です。プロトコルの設定値、ソフトウェア、報酬、対応するネットワークは変わりえます。実装の時点の公式資料とオンチェーンの状態を確かめ、投資・法務・税務・会計の判断は専門家へご確認ください。