Discreet Log Contracts -マルチオラクルサポート-

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を使用したオラクル署名の販売

前回の投稿では現実世界でオラクルが機能するために必要なものの１つとして、DLCのマルチオラクルサポートについて軽く触れました。
今回はマルチオラクルサポートのDLC実装とその利点や課題について触れていきたいと思います。この投稿はAdaptor signaturesを使用したDLCの実現方法が前提知識となってきます。こちらについて知りたい方は以前のブログをご覧ください。
現状、DLCのマルチオラクルサポートでは以下の通り「n of n」及び「k of n」の議論がされています。

「n of n」：n個のオラクルを用いて契約締結、n個のオラクルの結果をもって契約履行
「k of n」：n個のオラクルを用いて契約締結、k個のオラクルの結果をもって契約履行

マルチオラクルの実装方法

それぞれの実装を単一オラクル、「2 of 2」、「2 of 3」の比較で見ていきましょう。

単一オラクルを使用したDLC実装
契約者は単一のオラクルから作成されたTweak point(契約用の公開鍵)で資金をロックし、オラクルから最終的に発表されるTweak number(契約用の公開鍵)を元に資金のロックが解除されます。

「2 of 2」オラクルを使用したDLC実装
契約者はオラクル1からTweak point1(契約用の公開鍵1)、オラクル2からTweak point2(契約用の公開鍵2)を作成し、これらを合算したTweak point1,2(契約用の公開鍵1,2)を作成します。

Tweak point 1,2 =Tweak point1 + Tweak point2

契約満期に各オラクルが結果Tweak number1(契約用の秘密鍵1)、Tweak number2(契約用の秘密鍵2)を発表するので、それを合算したTweak number1,2でロックが解除可能になります。

Tweak number 1,2 = Tweak number1 + Tweak number2

「2 of 3」オラクルの実装方式
３つのオラクルから２つのオラクルを選択する組み合わせは3通りです。
ユーザはこの組み合わせ分、Tweak point(契約用の公開鍵)を作成します。

Tweak point 1,2=Tweak point1+Tweak point2
Tweak point 1,3=Tweak point1+Tweak point3
Tweak point 2,3=Tweak point2+Tweak point3

契約満期に各オラクルがTweak number1,2,3(契約用の秘密鍵1,2,3)を発表するので、そのうち２つを合算することでロックの解除が可能になります。

Tweak number 1,2=Tweak number1+Tweak number2
Tweak number 1,3=Tweak number1+Tweak number3
Tweak number 2,3=Tweak number2+Tweak number3

このように各オラクルが発表した値の組み合わせを合算して使用することで、資金のロックおよび解除が可能になります。ちなみに一つの結果に対しオラクルの組み合わせの数だけContract Execution Transaction (以降、CET)が必要になるため、用意するCETの数は単一オラクルやn of nオラクルと比較して多くなります。

マルチオラクルの利点

上記のマルチオラクルの実現により、単一のオラクルを信頼する必要性を下げることが可能になります。例えば「2 of 2」の場合、オラクルのうちの１つが契約者の片方に有利な不正値を発表した場合でも、もう一つが正常な値を値を発表している場合は契約は履行されません（RefundTxを使用して資金を契約者の元に戻すことが可能です）
更に「2 of 3」オラクルなどを用いることでオラクルのうちの１つが不正値を発表した場合でも、正常稼働した残り2つのオラクルを用いて契約が履行可能になります。

また、実装面におけるこれらの提案のメリットはオラクルの実装方式は単一の場合でもマルチの場合でも同じ点です。単一のオラクルを使用するのか複数のオラクルを使用するのかはユーザ自身が決定可能であり、各オラクルはどのような使われ方をされたかを知る必要はありません。もちろん第三者が契約の内容を予測することもできません。

マルチオラクルの課題

単一オラクルと比較した時のマルチオラクルの課題は用意するべきCETの数が多くなる点です。以下２つの場合、CETの数が単一オラクルより増加します。

課題1)「k of n」オラクルの場合
まず、「k of n」オラクルの場合には、オラクルの組み合わせ分だけCETを用意する必要があります。例えば「2 of 3」オラクルの場合、単一オラクルと比較すると、ユーザが準備するCETの数が3倍(オラクルの組み合わせ分)になります。
CETを減らす方法としてはTaprootを用いて複数の条件を１つのトランザクションにまとめる方法や、秘密分散と秘密計算を用いた閾値署名を扱う方法なども考えられますが、こちらについては別の章で説明したいと思います。

課題2)各オラクルの発表結果に差異がある場合
またオラクルの発表する値（BTC/USD）ズレが生じる点もCET増加の要因になります。XX時点のBTC/USDについて「3 of 3」のDLCを行う場合を考えてみましょう。この場合、使用するオラクル1~3の間で結果の値にズレが生じることは（例えばそれぞれのBTC/USD結果が30000、30001、30001など）現実世界で起こり得ます。「3つのオラクルの値が全て30000」を表現したい場合は1つのCETで事足りますが、上記の「30000〜30002」のレンジで差異があっても契約を成立させるためには以下27つのCETを用意する必要があります。

オラクル1の取りうるパターン(3通り)×オラクル2の取りうるパターン(3通り)×オラクル3の取りうるパターン(3通り)= 27通り

この問題の解決方法として「オラクルの発表する値のレンジ」に対して署名をする方法が議論されています（次回、こちらについてはご説明します）

まとめ

今回はマルチオラクルサポートのDLC実装方式とその利点や課題について説明しました。
マルチオラクルによりDLCの単一障害点(SPOF)の排除や、単一のオラクルへの依存する必要性を下げることが可能になります。しかし、上述した通り、用意するCETが増加するという課題も残っています。
次回のブログでは、課題２）の対策として検討されている「レンジ」に対しての署名を作成する方法について説明したいと思います。