OP_CTVが導入されたらDLCは劇的に使いやすくなる

加藤規新 • 2022年01月27日

ビットコインへの機能追加案として積極的に推す人が多いものの１つにOP_CTVがあります。コインを使用するときのトランザクションの内容の一部にあらかじめコミットできるこの機能がもし導入されたら、DLCの使用時に大きなメリットがあるという内容の投稿がDLC開発者のメーリングリストにされました。

今日はDLCメーリングリストへの投稿を元に、OP_CTVの導入がどのようにDLCを改善するのかを解説します。

https://mailmanlists.org/.../dlc.../2022-January/000102.html

OP_CTVとは

最近こちらで触れることも多いですが、ご存知のない方のためにOP_CTVがどういう提案なのかを説明します。一言で言えば、マルチシグやタイムロックなどビットコインの使用条件を記述できるスクリプト言語があり、そこに使用時のトランザクションの形式(使うUTXOや送金先など)を条件として指定できる関数OP_CTVを追加しようという提案です。

送金先や送金の形式を条件として指定することで現在のスクリプトで実現できる機能を大幅に拡張することがOP_CTVの狙いです。

かつてOP_SECURETHEBAGという名称だったOP_CTVについてビットコイン研究所内で過去にも解説していますので、ぜひそちらの記事もご覧ください。

https://www.facebook.com/.../bitc.../posts/2419022928194034/

DLCとは

さて、DLCについても最近とても注目している分野として頻繁に触れていますが、一言でおさらいします。

DLCとは二者がマルチシグに入金し、そこから第三者のオラクルが発表する結果に応じて資金が分配されるというノンカストディアルな取引手段です。先物やオプション、予測市場、賭け事などに応用することができます。

DLCについても、詳しくは過去の記事をご参考にしてください。

DLCは結果が細かいと大変

メーリングリストの投稿は、OP_CTVとDLCの関係についてこう述べています。「CTVはパフォーマンスを劇的に改善するDLCプロトコルを可能にすることで技術的な障害とUX面の課題をいくつも改善する。」そう、OP_CTVがDLC界隈を唸らせる具体的な理由はDLCのプロトコルにあるのです。

DLCでは参加者がお互いに全ての想定される結果について、マルチシグから支払うコントラクト実行トランザクション(CET)を事前に準備します。これは例えばコイントスであれば表・裏の2通りのみですが、例えばビットコインの先物取引であれば(価格の有効桁数によって)数千通りから数百万通りに及ぶトランザクションを用意する必要が出てくる場合も考えられます。これらのCET全てについてオラクルの発表する結果を使って署名・配信できるようアダプタ署名を生成し検証する必要もあり、数が大きくなると結構な処理時間がかかってしまいます。

またオラクルを複数使用して結果をオラクルによる多数決で決定させようと思うと、それも署名やトランザクションの数を増大させます。具体例として、オラクル5人中3人以上という条件を追加したければCET数は5C3=10倍になります。

さらに言うまでもなく、DLCを結ぶ相手との間でこの大量のデータのやり取りも発生します。何メガバイトにも及ぶでしょう。ところが、OP_CTVを使えば全てのCETについてアダプタ署名を用意するステップを省くことができるというのです！

OP_CTVを使うと簡潔になる

先程はDLCの可能な結末全てに対応する各CETについて、アダプタ署名を生成し検証するステップが大変だと書きました。これはTaprootとOP_CTVを使えば、別の方法で置き換えて実際に劇的に改善することができます。

Taprootでは、多数の場合分けをそれぞれTapleafとしてTaptreeという木構造に入れ、使った条件(Tapleaf)だけを公開することができます。そこで、オラクルが鍵を発表したら署名できるような各CETを生成したのち、Taptreeの各TapleafでこれらのCETのハッシュ値にコミットすれば良いのです。

すなわち、これまでアダプタ署名でやっていたことが、全てのCETに対して

<CET-hash_i> CHECKTEMPLATEVERIFY <CET_i> CHECKSIG

という簡潔なスクリプトを用意することで置き換えられます。これは使用するCETの内容が事前にコミットしたものであること、そしてCETの署名が揃っていることを検証しています。

オラクルが公開した結果をnとすると、CET_nだけが署名できるはずなので、上記のスクリプトは、あらかじめコミットされていたトランザクションCET_nを実行することになります。

アダプタ署名を用意するのと比べて処理時間は数十倍高速化され、契約相手とやり取りするデータ量もTaprootの確認で済めば非常に小さなものとなります。またオラクルを複数使用するときの条件もスクリプトとして通常のマルチシグのように記述することでCET数の爆発的増加を防げます。

まとめ

メーリスでもまとめられていますが、OP_CTVを使えばDLCをScriptを利用して大幅に簡略化することができ、それによって処理時間で最低でも30倍の効率化、複数オラクルをしきい値で使う場合はそこから更に数倍以上の効率化を実現します。また、交換するデータ量も大幅に削減されます。これによって弱小なデバイスや悪い通信環境でもDLCがほぼ瞬時に作成でき、UXが改善されます。

その代償として、もともと署名の組み合わせのみでScriptlessと呼ばれるものであったDLCがスクリプトを持つことにより、非協力的な決済の場合には通常の送金とは異なる見た目になってしまうことと、スクリプト自体のサイズによって非協力的な決済にかかる手数料が2倍程度になることがトレードオフとして挙げられます。

ちなみにOP_ANYPREVOUTでも似たようなことができるという指摘がメーリスでありました。ANYPREVOUTも次のソフトフォークとして有力視される１つの機能追加提案です。

加藤規新

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