Discreet Log Contracts -Lightning Networkを使用したオラクル署名の販売
Discreet Log Contractsオラクルシリーズ
1.Discreet Log Contracts -現実世界でオラクルが機能するために必要なもの-
2.Discreet Log Contracts -マルチオラクルサポート-
3.Discreet Log Contracts -レンジ署名-
4.Discreet Log Contracts -秘密分散・秘密計算（マルチパーティschnorr署名）を用いたオラクルフェデレーションモデル-
5.Discreet Log Contracts -Lightning Networkを使用したオラクル署名の販売（本投稿）
Discreet Log Contractsオラクルシリーズも一旦今回で最終回となります。
これまでのシリーズでは、単一オラクルへの信頼依存度を下げるためにマルチオラクルをサポートする方法や、オラクルフェデレーションを構築する方法などについて説明してきました。
今回はオラクルのインセンティブモデルを検討する上で有効となりうるライトニングネットワーク(以下LN)でのオラクル署名の購入について説明します。本概要は過去にSuredbitsが匿名の資格情報(anonymous credentials)の販売に関する記事を投稿しており、それをより具体的に解説した内容になっています。
なお、この提案が実現するのはLNに現状のHTLCに変わるPTLCが導入された後になります。HTLCとPTLCについて聴き慣れない方は次のセクションをご覧ください。（既にご存知の方は飛ばしていただいて構いません）HTLC、PTLCといったプロトコルの内容をスキップして何ができるかが知りたい、という方は「まとめ」のセクションから読み始めることをお勧めします。
(LNの前提知識)HTLCとPTLC
今回説明する内容はビットコインメインネットでTaprootがアクティベートされ、現状のLNがHashを用いた支払い(HTLC)から楕円曲線のポイントを用いた支払い(PTLC)に変更された後に可能となります。PTLCのメカニズムについて詳細を知りたい方は過去のブログ投稿もしくは説明用スライドの24~33Pをご覧ください。
LNのHTLCとPTLCの違いを簡潔に以下の記載すると以下の通りです。
-HTLCでは支払いの受け取り手（D）が、自身のみが知る秘密の値（Preimageと呼ばれています）をHashしたものを事前に準備し、これを用いて支払い資金をロックします。支払いは、受け取り手（D）から順々にpreimageが中継ノード(B、C)を経由して支払い者(A)に共有することで行われます。
-PTLCでは、支払いを中継する各ノードが各々が秘密の値（スカラー）および対応するポイント（ベースポイントGを秘密の値でスカラー倍したポイント）を準備、各ノードは前のノードが作成したポイントに自身で作成したポイントを合算することで各々オリジナルのポイントを作成し、これを用いて各々支払い資金をロックします。支払いは受け取り手（D）から順々に秘密の値を共有することで行われます。
受け取り人(D)が用意する秘密の値は、HTLCの場合は全てのノードに最終的に共有されるのに対して、PTLCの場合は最終的に支払い者(A)のみ把握可能な点に注意してください。（HTLCではA~Dは全てPreimage把握するが、PTLCではzはAとDのみ把握可能）
(DLCs前提知識)オラクル署名tとアダプターポイントT
DLCsの場合、ユーザは秘密の値tのパブリックイメージ（署名ポイントとも呼ばれます）Tを作成、それを元にAdaptor signatureを作成します。オラクルが公開した署名tを持いてユーザは作成したAdaptor siganatureを復号し、署名を完成させます。概要をおさらいしたい方はこちらの投稿のアダプター署名(Adaptor Signature)の章を、より詳しく知りたい方はこちらの投稿をご覧ください。
ポイントはユーザは署名ポイントT は予め作成しており、後に署名tをオラクルが発表する、という点です。このtとTは、以下で示す通り秘密の値（スカラー）および対応するポイント（ベースポイントGを秘密の値でスカラー倍したポイント）の関係が成立します。
T=t*G
このTとtの関係が、LN PTLCの秘密の値（スカラー）とポイントと同じ関係であることに注意してください。これがオラクル署名tをLN支払いで購入する際のキーポイントとなります。
LNによるDLCsオラクル署名の購入
さて、ここからが本題である、LNを使用したDLCsのオラクル署名の購入についてです。ユーザが予めオラクルが公開している公開鍵とランダムポイントを使用してDLCを締結します。契約満期になるとオラクルが結果を発表します。
ここでオラクルが発表するのは結果（message）のみ、契約履行に必要なtは公開しない点に注意してください。ユーザはtをどうやって取得するのでしょう？LN支払いです。
ユーザは結果（message）を知っているので予め作成した複数のアダプターポイントTのうち、どれが有効なものかを選別可能です。選別したアダプターポイントTに対応するオラクル署名tを取得したいユーザは、オラクルにLN支払いを行います。この際に、ユーザは支払い金額のロックにTを使用するのです。（以下図参照）オラクルが支払い金額を確認し、受け入れるとロックが解除され、最終的にユーザはtを入手することが可能になります！このtはLN支払いを行ったユーザのみが取得可能であり、図のBやCなどの中間ホップをはじめとする第三者がそれを把握することはできません。
LNによるDLCsオラクル署名の購入の特徴
今回はPTLCベースのLN支払いでDLCで使用するオラクルの署名を購入する方法について記載しました。この購入方法には以下の特徴があります。
-オラクルの署名tはLN支払いによる購入者のみ知ることができる
-LNの支払いとオラクル署名の交換はアトミックに行われる
-ユーザはアダプターポイントTを指定して購入するので、支払いの結果、想定と異なる値を受け取る心配がない
-LN支払いによるオラクルの署名を購入した痕跡はブロックチェーン上に記録されない
-オラクルはユーザの契約の中身を知る必要がない
-オラクルがLN支払いをあえて受け取らないなどして、署名を配信しない嫌がらせは可能（現状のLNおよびDLCでも起こりうる）
-上記の嫌がらせが発生した場合に、それを証明し第三者が検証する術がないのが課題（オラクルがパブリックに署名を公開しているのであれば第三者も検証が可能だが今回のケースではそれが行えない）
現状のビットコイン上でトラストレスに署名を販売する方法はないのか？
では現状のプロトコルでオラクルが署名を販売する方法はないのでしょうか？上記のPTLC支払いよりもプライバシー面やスケール面（計算コスト、トランザクションサイズおよびトランザクション手数料、コンファメーション時間）で劣りますが、大きく２通りあります。
1つはBitcoin上でECDSAベースのAdaptor signaturesを使用して購入する方法です。ここでは詳しく触れませんが、dlc-dev mailに以前投稿したこちらの内容で、その方法とその簡単な分析がご覧いただけます。
こちらの方法はLN経由ではなく、オンチェーンでの支払いになるので手数料およびコンファメーション時間が大きいのはいうまでもありません。また、支払いをする際にユーザはオラクルとインタラクションを行い、自身のUTXOを連携する必要があるので(LNの場合にはUTXOは連携しない)プライバシーの観点でも劣っていると言えます。
もう一つがZKCPを用いて現状のHTLCベースのLightning支払いを用いて販売する方法です。このハッシュファンクションを用いたZKCPは2016年時点でGregory Maxwellより発表されており（詳しくはこちら）、既にビットコイン上でも購入のトランザクションが実行されています。
PLTCベースのLNと比較した際のこの方法の課題は、ZKCPのロジックは当然LNには実装されていないので、それ自身をプロトコルの外側で実装しなければいけない点、ハッシュファンクションを使用した秘密情報はフットプリントとしてブロックチェーンに記録される可能性を含んでおり（PTLCの場合はこれは起こりません）、第三者によって識別されるリスクがあるという点です。
LNを使用した秘密情報の販売のユースケースについて
上記のようなLNを活用した秘密情報の販売はDLCsのオラクル署名だけに限らず、様々なユースケースが想定されます。
具体的には以下の３つをキーに発展していくと考えられます。
1.支払いとデータのアトミックな交換
上記の内容はオラクルの署名だけでなく、様々な秘密情報を販売することが可能です。LN支払いとアトミックにデジタルデータを販売するサービスは既に存在しています。Bitfinex terminalではマーケットデータをLN支払いでアトミックに行うことが可能です。
2.P2P販売
さらにはデータの販売をP2Pで行うサービスもいくつか存在します。Bitfinex terminalはマーケットデータを保持するユーザをP2Pネットワークで接続して、P2Pでの売買も行うことを視野に入れており、Lightning poolなどもLNの流動性をP2Pで購入可能です。LN自体がP2Pで接続されるネットワークなので、これと相性がいいのは言うまでもありません。
3.ゼロ知識証明との組み合わせ
No KYCのP2P売買で重要となるのが「相手が信用できるか？」つまり「取引相手がこちらが想定している条件を満たしているか？」です。「条件を満たしている」には特定の金額を保持している、特定の秘密情報を保持している、年齢や出身地など特定の条件をクリアしている、などが挙げられます。ここで相手に秘密の情報を伝えることなく秘密情報を保持していることを証明する「ゼロ知識証明」が有効になります。
現状もゼロ知識証明は様々な用途で既に使用されており、具体的には、Joinmarketで取引時にUTXO保持していることを離散対数の等価性証明で実施しています。（詳しくはこちらを参照）またLiquid上のConfidential transactionではPederen commitmentを使用し、各トランザクションのインプットとアウトプットの値は明かさずにインプットとアウトプットの合計値が一致していることを第三者が検証可能な形にしています。（詳しくはこちらを参照）
さらに、このゼロ知識証明とLNを組み合わせたユースケースとして、匿名の属性証明書をデジタルデータとして作成し、その一部の属性の情報（年齢など）の証明や開示をLN課金などで行ったりするようなユースケースなども言及されています。（詳しくはこちらを参照）
このように過去に研究されてきたゼロ知識証明と、ビットコインはじめとする匿名性を担保した暗号通貨の発展と普及により、これらを組み合わせたアイディアやサービスは検討の余地があり、これからも様々な提案が生まれてくると想像します。
少々脱線しましたが、これにてDLCのオラクル編の投稿はこれにて完結です。
オラクルだけでなく、DLC自体が現実的に稼働するための検討は現在進行形で進んでいます。興味のある方はSpecを覗いてみてください。
またCrypto GarageはこのDLCをベースにしたアプリケーションP2P derivativesを開発しています。興味のある方は使ってみてください。これについての最新情報を知りたい方は我々のTwitterアカウントもぜひフォローお願いします。
