Revaultでコベナンツなしでビットコインに特殊な送金条件を適用する

加藤規新 • 2025年03月07日

ビットコインの次の機能追加として期待されているコベナンツですが、実装方法自体については議論が続く一方で昔から言われてきたユースケースの１つとしてよりきめ細やかな保管を可能にする「Vault（金庫）」と呼ばれるものがあります。

何回か本稿でも取り上げていますが、提案されている実装方法のいくつかについて2023年に軽い要約をしています。

当時のソフトフォーク提案を軽く俯瞰しています。今とは少し差異が出てきているかもしれません。

また別の記事でした説明を引用させていただくと：

コベナンツは「ビットコインを使うときのトランザクションの内容」を限定する技術です。例えば現在、シングルシグ、マルチシグやタイムロックなどを使って「誰がビットコインを使えるか」「いつビットコインを使えるか」は限定することができますが、使うときのトランザクションの内容までは制限できません。「このアドレスにしか送金できない」「使うときは必ずこの送金先・金額で使う」「事前に作成したこのトランザクション内容以外は認めない」のような制限を課すのがコベナンツです。

さて、（技術力の高い人しか議論についていけていないからか）最近はもっぱら目的がArkのような新レイヤー２の導入やライトニングの改善という風に考えられがちになっているコベナンツですが、近年の「価値の保存」に重きを置いているユーザーはむしろVaultの恩恵は享受できるためVaultにもかなり潜在的な需要はあると考えられます。

その証拠に、Vaultのようなものを実現するプロダクトが存在します。以前紹介したLianaと同じ会社が手掛ける、Revaultというサービスです。

このサービスはコールド保管しているビットコインに「特定の条件に従った送金のみを許す」という、まさにコベナンツで実現しようとしている機能を提供しています。そこで、この機能がどのように実装されているのかが気になったので調べてみました。

・マルチシグ、タイムロック、プレサイントランザクション、署名サーバーの組み合わせによる複雑だが巧みなコベナンツ同等機能

・難しすぎて流行らない予感がする

・リスク要因も直感より多い

マルチシグ、タイムロック、プレサイントランザクション、署名サーバーの組み合わせによる複雑だが巧みなコベナンツ同等機能

Revaultの参加者には「ステークホルダー」「マネージャー」という2つの役割があり、基本的にはN人のステークホルダーがn-of-nマルチシグで持つ資金を、M人のマネージャーがk-of-mマルチシグによって特定の条件下で取り扱えるというものです。マネージャーがステークホルダーの定める条件に合致しないトランザクションを発した場合は、いずれのステークホルダーも1人でステークホルダーのマルチシグへと全資金を退避させ、そのトランザクションを無効にできます。

コベナンツであればマルチシグのスクリプト自体をもう少し複雑にして実現できる内容ですが、Revaultではプレサイントランザクションとタイムロックの組み合わせで行っているため、技術的な発想はDLCやLNなどに少し似ています。

むしろ、ステークホルダーが課す制約の内容をビットコインスクリプトで定義する必要がないため非常に柔軟なスマートコントラクト機能を実現できるとも考えられます。例えばRevaultのウェブサイトでは1回のトランザクションの送金金額だけでなく、1日の送金金額やマネージャーの2要素認証を必須にする例が提案されています。

このような機構が正常に動作すれば、会社の担当者ごとに動かせる予算を決めるなど、コーポレートガバナンスをビットコインの送金に強制する方法として役立つかもしれません。

RevaultはいくつかのDescriptor（ウォレット）の組み合わせによって資金の流れを制御しています。下図でウォレットと資金の流れを示しています。オレンジで示したDescriptor（楕円）はステークホルダー全員によるN-of-Nマルチシグ、ブルーで示したDescriptorはマネージャーによるK-of-Mマルチシグです。

資金のフローを見れば、緊急避難はいつでも可能で、マネージャーによる不正対策としてタイムロックとUnvault Emergency TXが機能することがわかる。

オレンジのトランザクション（矢印）はステークホルダーのマルチシグによって送金可能なもの、ブルーのトランザクションはマネージャーのマルチシグ＋タイムロック＋ステークホルダーの設定した条件を検証するサーバーの署名によって送金可能なものです。Unvault TXはSpend TXを配信したい場面がくるまでオフチェーンで保管されます。

赤色のトランザクションは全てのステークホルダーが署名済みの状態で保有し、緊急時に配信できる避難用トランザクションです。特にUnvault Emergency TXは、Spend TXにタイムロックがかかっているため不正なSpend TXを検知した場合に一定期間内に配信することでマネージャーによる不正送金を取り消すことができます。

この「ステークホルダーの設定した条件を検証するサーバーの署名」が曲者で、このサーバーをCo-signingサーバーと言い、これが前述した柔軟な送金条件の指定と検証を可能にしています。

またライトニング同様、Spend TXを取り消すには一定時間内に検知する必要があるので、ステークホルダーが動かすWatchtowerという概念が存在します。WatchtowerはマネージャーからSpend TXの登録を受け付け、もし受け付けていないのにUnvault TXが発せられた場合は即時にUnvault Emergency TXを配信して資金を避難させます。

Unvault Emergency TXを時間内に配信できるかどうかはWatchtowerの存在に依存しているため、ステークホルダー全員でこちらも少なくとも1台は必要になります。実際には1人1台が妥当でしょう。

難しすぎて流行らない予感がする

単純なマルチシグ保管と比べて、ウォレットが3つ出てきたり、ステークホルダーとマネージャーというポジションの差があったり、常時オンラインのサーバーやWatchtowerが必要だったりと、RevaultはVault機能の実現のためにかなりの複雑性を持っています。（もちろんライトニングなどと比べるとかなりシンプルではありますが。）

じゃあ逆に簡単だったら（より少ない参加者で、よりシンプルで放ったらかせる要件で使えるVaultが作れたら）流行るのかというと、むしろ難しいのはそこではなくてリスクの切り出しだったり、それに応じてどのような使用条件を課すべきか決めるところなんじゃないかなと思います。したがって、コベナンツが導入されてもVaultを利用するのは主にビットコインを保有する企業など、ビットコインの保管や移動権限についてトラストが発生しがちでペインが大きいアドバンスユーザーに限られるのではないでしょうか。個人でマルチシグを使うことすら未だにニッチな業界で、それよりもカスタマイズ性の高いコベナンツの需要は限定的かもしれません。

むしろ、保管時のリスク要因の明確化や、それを元にどのように保管すれば対処できるのかというノウハウが簡単に把握できるウェブサイトとかあったら便利そうで圧倒的に需要がある気がしてきました。

リスク要因も直感より多い

Revaultはコベナンツを使っていないために仕組みが複雑化していますが、その複雑性の中にも様々なリスク要因が潜んでいます。

例えば不正防止をWatchtowerとCo-signingサーバーに完全に依存しているため、あるRevaultについてWatchtowerが全てダウンしていたり、あるいは一定数のCo-signingサーバーが侵害されていて署名すべきでないトランザクション（登録したSpendTXを置き換えようとするSpendTXなど）に署名してしまうと全損するリスクがあります。

また、鍵の導出にUnhardened Derivationというセキュリティの低い方法を使っているため、何らかの理由であるユーザーの末端の1つのアドレスの秘密鍵が漏れてしまうと、そのユーザーの全ての秘密鍵が漏洩したのと同じことになってしまいます。すなわち、N人のステークホルダーがそれぞれ1つだけ末端の秘密鍵を漏洩させてしまうとマルチシグ全体の資金がリスクに晒されます。

Pre-signed Transactionベースのプロトコルとして、Emergency Unvault TXやCancel TXの手数料を安い状態で決定されてしまい（Transaction Pinning）、手数料の高いときに制限時間内に実行されない可能性もあります。一応、ライトニングと同様、CPFPで手数料を追加するためのアウトプットがUnvault TXにはあり、Pinning攻撃の対策であると同時にRevaultからの出金にかかる時間を調整する役割を果たしているようですが。

また、Emergency Descriptor（避難用ウォレット）は厳重に管理されている前提となるため、仮にそこに送金することができたとしてもビジネス継続上の懸念が発生する場合も考えられます。避難用ウォレットのシードの保管場所が遠く離れているステークホルダーがいる場合などが該当するでしょう。それを逆手に取って、Emergency TXをちらつかせて資金を人質に取る攻撃者もいるかもしれません。

最後に、仕組み自体が簡単にバックアップできるものではないため、互換性の問題などがあり、セルフGOXリスクも通常のマルチシグと比べて高い可能性があります。（一応ドキュメントさえ残っていれば専門家に手伝ってもらって復旧できる可能性もありますが、ユーザーにもかなりの技術的な理解が要求されるものと考えて差し支えなさそうです。）

このように、直感では気づきにくい新しいリスク要因がたくさんあるため、Revaultを利用することが保管のリスク削減になるかはケースバイケースでしょう。個人的には非常に面白いプロダクトだと思いますが、自分が使うシチュエーションは思いつきません。セットアップからめんどくさくなってしまいそうです。

加藤規新

1994年生まれ、シカゴ大学でGISやコンピューターサイエンスを学び学士号取得。2016年末よりビットコインに関するリサーチや実験的な開発をしており、今までにいくつかのブログやサロンで解説を担当。ビットコインについて一番好きなところはパーミッションレスに誰でも使うことができること。 2024年11月より日本ビットコイン産業株式会社取締役。