ついにビットコインのサイドチェーンが実現か？BitVM Bridgeとは何か

Table of Contents

はじめに

ビットコイン開発者のコミュニティーでは以前からサイドチェーンの可能性について議論されていました¹。しかし、例えばDrivechain²はソフトフォークを必要とし、Liquid¹などはマルチシグで管理されています。今回BitVM Bridge³として発表された論文はソフトフォークを必要とせず、マルチシグのようなt-of-n (t > n/2, honest majority)の信頼できるパーティがいる設定ではなくn人中少なくとも1人信頼できる人がいる設定(existential honesty)でサイドチェーンを構成しています。

主な仕組み

BitVM BridgeはオリジナルのBitVM⁴の仕組みを改良したBitVM 2³によって実現されています。
BitVM 2はfraud proofという仕組みで、ある計算結果に片方のパーティが納得できない場合に、不正な計算であることを証明する仕組みです。もとのBitVMのデザインでは不正の証明に最大70個のtxが必要でしたが、BitVM2では3つのtxで不正の証明ができるように改良されています。

BitVM2では、計算実行を直接証明するのではなく、計算が実行されたことを証明したSNARG(もしくはより強力なzkSNARKsなど)の検証をすることで、証明する問題の長さを一定に抑えています。

SNARK検証プログラム(Groth16)をビットコインのスクリプトで表現すると、3GBのサイズになりますが、このプログラムfをビットコインのブロックサイズ4MBに分割します。仮に入力x,出力yとして $f(x) = y$ として、k個に分割すると、 $f_i(z_{i-1}) = z_i, z_0 = x, z_k = y$ と表現できます。単純化して言えば、この検証が成り立たないことを示すには、 $\exists i\ f_i(z_{i-1}) \neq z_i$ を示せばいいのです。

このようなBitVM2の仕組みを使って、BitVM Bridgeではサイドチェーンからの引き出しを以下の順序で実行することになります。

サイドチェーンのユーザーが資金引き出しをリクエスト
オペレータ（後述。あらかじめ登録されたユーザー）がユーザーに引き出し用資金を支払う
オペレータは、2で「自分がユーザーに引き出し用資金を先払いした」という事実の証明を行い、メインチェーンにロックされているコインを取り出す。この時点でオペレータはユーザーに先払いした引き出し用資金を回収できる。

登場人物

オペレータ

オペレータは事前に合意した上記のSNARK検証プログラムfを実行する責務をもつ。BitVM Bridgeにおいてfが証明するのは「ブリッジからの出金が正当であること」になる。

挑戦者

挑戦者はオペレータが不正を行った場合、一定の期間内に意義を唱えてプログラムfが正しく実行されていることを保証する。他のオペレータ含めオンチェーンでトランザクションを発行できるユーザーは誰でも挑戦者になれる。

署名者(n人)

コベナンツのエミュレーションを行うためにn人の署名者がn-of-nマルチシグによって署名を行う。n人のうち1人は正直である必要がある。

サイドシステム

オペレータが資金引き出しを証明することができる、サイドチェーン的なシステム。BitVM Bridgeでは(仮想的な) Bitcoin Rollupを使うことが想定されている。Bitcoin Rollupでは状態遷移がビットコインのブロックチェーンに記録されていくため、サイドシステムのブロックサイズは基本的にビットコインのブロックサイズに限定される。

ここでいうBitcoin Rollupとは？

具体的な構成方法の記述が無いので不明です。コベナンツや柔軟なスクリプトが可能であるとしたら作れるような仮想的なプロトコルだと理解しました。

現在のビットコイン上ではトラストレスな出金ブリッジを実現できないため、完全なロールアップ(Rollup)は実現できないと考えられています⁵。

状態をコミットしておき、BitVM Bridgeですると書いてありますが、そもそも不正なステートがコミットされないようにするためにどうすればいいかなどの詳細は不明です。

Bitcoin Rollupと呼べるのかどうかは不明ですが、⁶⁷のような既存のutxo型とは違ったCSV(Client Side Validation)型のブロックチェーンのアーキテクチャもサイドシステムとして使えるようです。

構成要素

n-of-n マルチシグによるコベナンツのエミュレーション(deleted-key covenants)

コベナンツ⁸は、後続のトランザクションがどのように使われるかを指定できるような仕組みです。

BitVM2においては、オペレータの発行したトランザクションが、後続のトランザクションにおいて必ず挑戦者によって検証可能であってほしいので、コベナンツが必要です。

BitVM2のセットアップ時に、オンラインであれば誰でも参加できるような、n人からなる「署名者委員会」(signer comittee)のようなものを組織し、n-of-nマルチシグを作成します。署名者委員会は以下のようにしてコベナンツを擬似的に実装します。

それぞれの署名者は新しい鍵ペアを作成します。
特定の方法で消費される必要がある全てのトランザクションアウトプットに対して、マルチシグでの消費条件 $\text{CheckMultiSig}_C$ を追加します。すなわち、そのUTXOを消費するためには署名 $\sigma_C$ を作成する必要があり、そのためには全ての署名者が協力しなければなりません。Cはコベナンツの送金条件とします。
それら全てのUTXOに対して、署名者は、プロトコルに従うと期待されるトランザクションを作成し、署名します（この時点ではそもそもUTXOは存在しないのでブロードキャストはできません）。それぞれのオペレータに対して署名済みトランザクションを配布します。オペレータは、特定の条件でのみそれらのトランザクションを消費することができます。
署名者が全員鍵を削除します。

もし一人でも署名者が正直であるならば、鍵を削除することで、条件に沿った方法でしかUTXOを動かすことができなくなるので、擬似的にコベナンツが実現できたことになります(deleted-key covenants⁹という)。

なお、ここでもし署名者が特定のトランザクションを事前に署名してしまったら、動的に宛先や数量を変えられなくなりそうですが、SIGHASH_SINGLEという署名タイプなどを使うと宛先一つを固定して署名し、その他の宛先はあとから自由に追加できるという性質によって回避しています。詳細はSIGHASHの仕様¹⁰¹¹を参照してください。

ランポート署名を使ったスクリプトの状態管理

ランポート署名によって、仮想的な変数に特定の値をセットした後、その値を書き換えることを罰するような仕組みができるということが、以前Blockstream社の研究者が解説したブログ記事¹²に書かれています。

ただ、BitVM2では、上記ブログ¹²のインセンティブベースの状態管理ではなく、擬似的なコベナンツのトランザクションによって、量が0のインプットとアウトプットで現在の状態変数を次のトランザクションの状態に持ち越す形になっています。

そしてこの変数はランポート署名によって割り当てられているので（これは¹²と共通しています）、割当が可能なのは特定の公開鍵の持ち主（BitVM2では各オペレータ）だけであり、正当なユーザーが割り当てた変数であることが保証されます。

例えばhash(v0)とhash(v1)という2つのハッシュ値が公開鍵として公開されており、アンロックスクリプトにエンコードされている状況で、どちらかのハッシュ元像のみをscriptSigとして与えた場合にアンロックされるような構成が可能です。
さらに次のアンロックスクリプトにおいても同じような変数を与えないとアンロックできないような出力先の形式をコベナンツによって強制するとします（コベナンツで強制する時点ではまだどのような変数が割り当てられるかは決まっていません）。すると次のアンロックスクリプトをアンロックするためには、（v0, v1両方のハッシュ元像が公開されることはないという前提で）すでに知られているハッシュ元像を使いまわす以外に方法がなく、結果的にグローバルなステートを次のアンロックスクリプトに渡すことが可能になります。

Assert用のトランザクション(証明が正しいと主張するためのトランザクション)を発行するのはオペレータであり、したがって変数割当を行うのもオペレータになります。オペレータがもしも複数のハッシュ元像を公開したならば、それはオペレータ自身が「ハッシュ元像を満たす変数であり、かつ、反証されるような入力」を挑戦者に渡してしまうことになります。よって、オペレータには合理的にSNARG検証が通らない変数を割り当てるようなインセンティブはないと言えます。

なお変数割当をどのようにして読み出し、次のアウトプットにつなげるのかという問題をコベナンツが存在する状況下で一般化しようとする試み（state caboose）もありますが、BitVM2とは直接の関係はなさそうです。state cabooseについては参考文献¹³を参照してください。

コネクターアウトプット

過去の記事¹⁴を参照してください。

BitVM2 プロトコルの概要

まず、SNARKを使用してプログラムを圧縮します。BitVM2では、プログラムの実行自体を検証するのではなく、プログラム実行に対する証明を検証するSNARK検証器が正しく動作しているかを確認します。
SNARK検証器をBitcoin Scriptで実装します。しかし、プログラムサイズ（例：Groth16で3GB）はブロックサイズを大幅に超えています。
検証器をk個のサブプログラムに分割し、それぞれ最大で4MBのサイズにします。これらのチャンクはBitcoinのトランザクションやブロック内で実行可能です。このようにして、サブプログラムは順次実行されます。つまり、プログラム2はプログラム1の出力を入力として取り込み、その後最終的にプログラムkの出力が元のプログラムの出力と一致します。
オペレーターはセットアップ中にプログラム（つまり、SNARK検証器）を正しく実行することを約束します。関連するBitcoinトランザクションとTaprootツリーに事前に署名することで、オペレーターが不正行為を行った場合に、資金を引き出すためには必ずチャレンジを受ける必要があるように設定します（ここでコベナンツが必要になります）。
オペレーターがBitVM2から資金を引き出そうとする場合、例えばブリッジのペグアウト処理の一環としてBTCを取り出す際には、SNARK検証器の出力をオンチェーンに公開する必要があります。
誰でも、公開されている入力を基にして、SNARK検証器の出力を自分のローカル環境での実行結果と照らし合わせて確認できます（※入力値についてはデータの可用性問題が出てくる可能性あり）。もし結果に異議がある場合、誰でもオンチェーンでチャレンジを行う挑戦者となり、オペレーターに計算に関する追加データを公開させることができます。
チャレンジされた場合、オペレーターはサブプログラムの中間出力すべてをオンチェーンのトランザクションで公開しなければなりません。
その時点で、挑戦者は誰でも不正な中間結果を見つけ、対応するサブプログラムをオンチェーンで実行することで、結果が一致しないことを証明できます。これにより、オペレーターのBitVM2引き出しトランザクションは無効になり、一部の担保が没収され（オンチェーンのコストが補填されます）、不正が罰せられます。

上記を簡単に説明したのが以下の図です（実際にはもっと複雑）。

なお上記の担保(コラテラル)の没収とは、以下のような担保dが没収されることです。

BitVM2では、以下の2通りの用途に応じて誰かが担保dを預ける必要があります。

プログラムの検証をリクエストした第三者による担保。この担保はオペレータがプログラム検証に成功するとオペレータのものになります。失敗すると、挑戦者のものになります。
- これは例えば、「ある問題を解くための鍵をオペレータが知っていることを証明した場合に限り、オペレータに報酬を与える」ようなクイズコントラクトの場合に、出題者が報酬として設定する資金です。
オペレータ自身による担保。この担保はオペレータがプログラム検証に成功するとオペレータに返却されます。失敗すると挑戦者のものになります。そして、オペレータに対するプログラム検証の報酬は、BitVM BridgeのようにBitVM2の外部で支払われます（bitvm bridgeにおいて、最終的にサイドチェーン入金トランザクションはオペレータに支払われます）。

BitVM Bridge プロトコルの概要

アリスがサイドシステムにPegInトランザクションで入金し、サイドシステム上でボブに送金し、ボブがサイドシステムからBurnトランザクションで出金する場合を考えます。

ボブは出金時、まずサイドシステム上でBurnトランザクションを発行します。それを見たオペレータはオペレータ自身の資金を使ってボブに支払いを行い(PegOut)、その支払いを行ったトランザクションPegOutとサブシステム上の状態を証拠として、Operator自身が受け取るPayOutトランザクションを発行します。これが正常系の流れです。

概要は以下の図を参照してください。

実際には異常系があり、PegInトランザクションを消費できるようにするためには、最初にいくつかのトランザクション(KickOffトランザクションなど)を発行して、予定されていた他のトランザクションが揃ったら初めてPayOutトランザクションが有効になるように設定しておきます。

中間で発行されるいくつかのトランザクション(KickOffトランザクションなど)に対して挑戦者がオペレータの不正を証明したり、反証したりといったBitVM2の仕組みが使われることになります。

BitVM Bridgeのメリット

信頼を最小限に留めてサイドチェーンが実現できる
誰でも挑戦者(challenger)になれる。挑戦者になる金銭的なメリットがある。
資金の引き出しが可能なオペレータ(operator)のセットは定期的に入れ替えることができるので、オペレータ全員が出金を拒否しても永久にロックされるとは限らない。また、オペレータは資金をロックし続ける必要がないので、他のコラテラルが必要な代替プロトコルと比較すると資金効率が高い。オペレータは正直に振る舞う金銭的なメリットがある。

BitVM Bridgeのリスク

複雑な暗号学的仮定

Groth16の仮定全てが必要(楕円曲線ペアリング、トラステッドセットアップ)

SPVノード検証

ブロックのヘッダーのみの検証を行っており遷移ロジックを検証していない。そのため、悪意のあるマイナーが無効なブロックを生成して証明とする可能性がある。

オペレーター全員による資金のロック

オペレーター全員が協力することで、資金をロックすることができる。ただし、資金を盗むことはできない。なお、定期的にオペレーターのセットを更新するように合意していても、必ず新しいオペレーターによって資金が取り出せるようになるとは限らない。

また、オペレータは引き出し時に、以下の順序で引き出しをおこなう。

ユーザーに対してオペレータが引き出し金額を支払う。
オペレータがコントラクトから引き出した金額と同じ金額を受け取る。

したがって、オペレータは常にビットコインをロックしておく必要はないにせよ、一時的にユーザーに対して引き出し用の資金を供出しなければならない。なおオペレータは引き出しを実行することで最終的には金銭的な対価を得ることができる。

一定期間内にトランザクションが取り込まれないリスク

巨大なfraud proofのトランザクションを実行するためには非標準形式のトランザクションが必要なので、マイナーに対して個別に依頼する必要がある。一定期間内に取り込まれないと異議申し立てをしたことにならないので、短期的な51%攻撃に対して脆弱。

サイドシステムのコンセンサスが不明確

Bitcoin Rollupを使えばいいと書いてあるが、サイドシステムからメインチェーンに対して不正な状態がコミットされないようにするための手法が不明。これを実現するために、第三者への信頼を含めて何らかの別の仮定が必要そう。

Q&A

不正を行ったオペレータはどのように追放されるか

8.6.に紹介されているとおり、定期的にオペレータのセットを入れ替えるように予め決めておくなどすれば追放できる可能性があります。具体的な方法については書いてないです。もしも追放できない場合、不正を行ったオペレータは金銭的に損をした状態でプロトコル内に残り続けることになります（多分）。

BitVM Bridgeはビットコインのスケーリングに使えるか？

現在発表されている内容では、トークンの保有者が変わった場合その情報をメインチェーン上でも記帳しなければならないので(bitcoin rollup)、署名値部分の検証集約化ができるくらいで、あまり本質的なスケーリングはできません。しかし、サイドシステムの方でSIGHASH_NOINPUT / SIGHASH_ANYPREVOUT (BIP 118) ¹⁵などの拡張機能が使えるようになると、ライトニングネットワークなどのスケーリングに役立つ可能性はあります。

サイドシステムの仕組みとして⁶⁷を使った場合にはトランザクションのサイズが小さくなるため、BitVM Bridgeが成立するならばスケーリング効果はありそうです。