Bitlayer Research:DLCの原理解析とその最適化の考察
原文标题:《Bitlayer Core Technology: DLC and Its Optimization Considerations》
作者: lynndell \& mutourend, Bitlayer Research Group
1.はじめに
Discreet Log Contract (DLC) は、マサチューセッツ工科大学のTadge Dryjaによって2018年に提案された、オラクルに基づく契約実行のための一連のスキームです。DLCは、事前に定義された条件に基づいて、2者間で条件付きの支払いを行うことを可能にします。各当事者は可能な結果を特定し、事前に署名を行い、オラクルが結果に署名した際にこれらの事前署名を使用して支払いを実行します。したがって、DLCは新しい分散型金融アプリケーションを実現し、ビットコインの預金の安全性を保証します。
DLCは、ライトニングネットワークと比較して以下の顕著な利点があります:
- プライバシー: DLCはプライバシー保護においてライトニングネットワークよりも優れており、契約の詳細は参加者間でのみ共有され、ブロックチェーン上には保存されません。それに対して、ライトニングネットワークの取引は公開されたチャネルとノードを経由してルーティングされ、その情報は公開かつ透明です;
- 金融契約の複雑性と柔軟性: DLCはビットコインネットワーク上で複雑な金融契約(デリバティブ、保険、賭けなど)を直接作成および実行できるのに対し、ライトニングネットワークは主に迅速な小額支払いに使用され、複雑なアプリケーションをサポートできません;
- カウンターパーティリスクの低減: DLCの資金はマルチシグ契約にロックされており、事前に定義されたイベントの結果が発生した場合にのみ解放されるため、いずれかの当事者が契約を遵守しないリスクが減少します。ライトニングネットワークは信頼の必要性を減少させますが、チャネル管理や流動性提供においては依然として一定のカウンターパーティリスクが存在します;
- 支払いチャネルの管理不要: DLCの操作は支払いチャネルを作成または維持する必要がなく、これはライトニングネットワークの核心的な構成要素であり、チャネル管理は複雑でリソースを消費します;
- 特定のユースケースのスケーラビリティ: ライトニングネットワークはある程度ビットコインの取引スループットを向上させますが、DLCはビットコイン上の複雑な契約に対してより良いスケーラビリティを提供します。
DLCはビットコインエコシステムのアプリケーションにおいて非常に有利ですが、以下のようなリスクや問題も存在します:
- 鍵のリスク: オラクルの秘密鍵とコミットされたランダム数は漏洩または喪失のリスクがあり、ユーザーの資産損失を引き起こす可能性があります;
- 中央集権的信頼リスク: オラクルの中央集権的な問題は、サービス拒否攻撃を引き起こす可能性があります;
- 非中央集権的な鍵の派生が不可能: オラクルが非中央集権的である場合、オラクルノードは秘密鍵の断片のみを所有します。しかし、非中央集権的なオラクルノードは秘密鍵の断片に基づいてBIP32を使用して鍵を派生することができません;
- 共謀リスク: オラクルノード間で共謀が行われたり、参加者と共謀が行われたりする場合、オラクルの信頼問題は解決されません。オラクルの信頼を最小化するための信頼できる監視メカニズムが必要です;
- 固定額の釣り銭問題: 条件付き署名は、契約を構築する前に決定的な列挙可能なイベントの集合が必要です。そのため、DLCを資産再配分に使用する場合、最小金額の制限があり、固定額の釣り銭問題が生じます。
これに対処するために、本稿ではDLCのリスクと問題を解決し、ビットコインエコシステムの安全性を向上させるためのいくつかの提案と最適化の考え方を示します。
2.DLCの原理
アリスとボブは賭け契約に署名します:n+k番目のブロックのハッシュ値が奇数か偶数かに賭けます。奇数の場合、アリスがゲームに勝ち、t時間内に資産を引き出すことができます;偶数の場合、ボブがゲームに勝ち、t時間内に資産を引き出すことができます。DLCを使用して、オラクルを通じてn+k番目のブロック情報を伝達し、条件付き署名を構築して正しい勝者がすべての資産を獲得できるようにします。
初期化: 楕円曲線生成元をG、階をqとします。
鍵生成: オラクル、アリス、ボブはそれぞれ独立して秘密鍵と公開鍵を生成します。
- オラクルの秘密鍵はz、公開鍵はZであり、関係Z =z ⋅G を満たします;
- アリスの秘密鍵はx、公開鍵はXであり、関係X =x ⋅G を満たします;
- ボブの秘密鍵はy、公開鍵はYであり、関係Y =y ⋅G を満たします。
資金注入取引: アリスとボブは共同で資金注入取引を作成し、それぞれ1BTCを2-of-2のマルチシグ出力にロックします(アリスの公開鍵X、ボブの公開鍵Y)。
契約実行取引: アリスとボブは、資金注入取引を消費するための2つの契約実行取引(Contract Execution Transaction, CET)を作成します。
オラクルはコミットメントを計算します
$R:=k ⋅ G$
次に、SとS'を計算します
$S:=R-hash(OddNumber,R) ⋅ Z,$
$S':=R-hash(EvenNumber,R) ⋅ Z$
(R,S,S')をブロードキャストします。
アリスとボブはそれぞれ対応する新しい公開鍵を計算します
$PK\^{Alice}:=X+ S,$
$PK\^{Bob}:=Y+ S'.$
決済: n+k番目のブロックが出現したとき、オラクルはそのブロックのハッシュ値に基づいて、対応するsまたはs'を生成します。
- n+k番目のブロックのハッシュ値が奇数の場合、オラクルはsを計算してブロードキャストします
$s:=k-hash(OddNumber,R) ⋅ z$
- n+k番目のブロックのハッシュ値が偶数の場合、オラクルはs'を計算してブロードキャストします
$s':=k-hash(EvenNumber,R) ⋅ z$
引き出し: アリスまたはボブのいずれかの参加者は、オラクルがブロードキャストしたsまたはs'に基づいて資産を引き出すことができます。
- オラクルがsをブロードキャストした場合、アリスは新しい秘密鍵sk\^{Alice}を計算し、ロックされた2BTCを引き出すことができます
$sk\^{Alice}:= x + s.$
- オラクルがs'をブロードキャストした場合、ボブは新しい秘密鍵sk\^{Bob}を計算し、ロックされた2BTCを引き出すことができます
$sk\^{Bob}:= y + s'.$
分析: アリスが計算した新しい秘密鍵sk\^{Alice}と新しい公開鍵PK\^{Alice}は離散対数関係を満たします
$sk\^{Alice} ⋅ G= (x+s) ⋅ G=X+S=PK\^{Alice}$
この場合、アリスの引き出しは成功します。
同様に、ボブが計算した新しい秘密鍵sk\^{Bob}と新しい公開鍵PK\^{Bob}は離散対数関係を満たします
$sk\^{Bob} ⋅ G= (y+s') ⋅ G=Y+S'=PK\^{Bob}$
この場合、ボブの引き出しは成功します。
さらに、オラクルがsをブロードキャストした場合、アリスには有用ですが、ボブには無用です。なぜなら、ボブは対応する新しい秘密鍵sk\^{Bob}を計算できないからです。同様に、オラクルがs'をブロードキャストした場合、ボブには有用ですが、アリスには無用です。なぜなら、アリスは対応する新しい秘密鍵sk\^{Alice}を計算できないからです。
最後に、上記の説明ではタイムロックが省略されています。片方が新しい秘密鍵を計算し、t時間内に引き出しを行うためにタイムロックを追加する必要があります。そうでなければ、t時間を超えた場合、もう一方は元の秘密鍵を使用して資産を引き出すことができます。
3.DLCの最適化
3.1 鍵管理
DLCプロトコルにおいて、オラクルの秘密鍵とコミットされたランダム数は非常に重要です。オラクルの秘密鍵とコミットされたランダム数が漏洩または喪失した場合、以下の4つのセキュリティ問題が発生する可能性があります:
(1)オラクルが秘密鍵zを喪失した場合
オラクルが秘密鍵を喪失した場合、DLCは決済できず、DLCの返金契約を実行する必要があります。したがって、DLCプロトコルではオラクルが秘密鍵を喪失するのを防ぐために返金取引が設定されています。
(2)オラクルが秘密鍵zを漏洩した場合
オラクルの秘密鍵が漏洩した場合、その秘密鍵に基づくすべてのDLCは詐欺的な決済リスクにさらされます。秘密鍵を盗む攻撃者は、望む任意のメッセージに署名し、将来のすべての契約結果を完全に制御することができます。さらに、攻撃者は単一の署名メッセージを発行するだけでなく、n+k番目のブロックのハッシュ値が奇数と偶数であるという矛盾するメッセージを同時に署名することもできます。
(3)オラクルがランダム数kを漏洩または再利用した場合
オラクルがランダム数kを漏洩した場合、決済段階において、オラクルがsまたはs'をブロードキャストするかにかかわらず、攻撃者は次のようにしてオラクルの秘密鍵zを計算できます
$z:=(k-s)/hash(OddNumber, R)$
$z:=(k-s')/hash(EvenNumber, R)$
オラクルがランダム数kを再利用した場合、2回の決済を経て、攻撃者はオラクルがブロードキャストした署名に基づいて、以下の4つのいずれかの状況に基づいて方程式を解くことができます。
状況1:
$s1=k-hash(OddNumber1, R) ⋅ z$
$s2=k-hash(OddNumber2, R) ⋅ z$
状況2:
$s1'=k-hash(EvenNumber1, R) ⋅ z$
$s2'=k-hash(EvenNumber2, R) ⋅ z$
状況3:
$s1=k-hash(OddNumber1, R) ⋅ z$
$s2'=k-hash(EvenNumber2, R) ⋅ z$
状況4:
$s1'=k-hash(EvenNumber1, R) ⋅ z$
$s2=k-hash(OddNumber2, R) ⋅ z$
(4)オラクルがランダム数kを喪失した場合
オラクルがランダム数kを喪失した場合、対応するDLCは決済できず、DLCの返金契約を実行する必要があります。
したがって、オラクルの秘密鍵の安全性を高めるためには、BIP32を使用して子鍵または孫鍵を派生させ、署名に使用する必要があります。さらに、ランダム数の安全性を高めるためには、秘密鍵とカウンターのハッシュ値k:=hash(z, counter)をランダム数kとして使用し、ランダム数の重複や喪失を防ぐ必要があります。
3.2 非中央集権的オラクル
DLCにおいて、オラクルの役割は非常に重要であり、契約結果を決定するための重要な外部データを提供します。これらの契約の安全性を高めるためには、非中央集権的なオラクルが必要です。中央集権的なオラクルとは異なり、非中央集権的なオラクルは正確で改ざん防止されたデータの提供責任を複数の独立したノードに分散させることができ、単一の故障点への依存リスクを減少させ、操作や標的攻撃の可能性を低下させます。非中央集権的なオラクルを通じて、DLCはより高い信頼不要性と信頼性を実現し、契約の実行が完全に事前条件の客観性に依存することを保証します。
Schnorrの閾値署名は非中央集権的オラクルを実現できます。Schnorrの閾値署名には以下の利点があります:
- セキュリティの強化: 鍵の管理を分散させることで、閾値署名は単一障害点のリスクを減少させます。参加者の一部の鍵が漏洩または攻撃を受けた場合でも、設定された閾値を超えない限り、システム全体は安全です。
- 分散制御: 閾値署名は鍵管理の分散制御を実現し、単一の実体がすべての署名権を掌握することを防ぎ、権力の集中によるリスクを低下させます。
- 可用性の向上: 一定数のオラクルノードが同意すれば署名が完了するため、システムの柔軟性と可用性が向上します。部分的なノードが利用できなくても、全体のシステムの信頼性には影響しません。
- 柔軟性とスケーラビリティ: 閾値署名プロトコルは、必要に応じて異なる閾値を設定でき、さまざまなセキュリティニーズやシナリオに適応できます。また、大規模ネットワークにも適しており、良好なスケーラビリティを持っています。
- 追跡可能性: 各オラクルノードは秘密鍵の断片に基づいてメッセージに署名の断片を生成し、他の参加者は対応する公開鍵の断片を使用してその署名の断片の正当性を検証できます。正当であれば、署名の断片を累積して完全な署名を生成します。
したがって、Schnorrの閾値署名プロトコルは、セキュリティ、信頼性、柔軟性、スケーラビリティ、追跡可能性を向上させる非中央集権的オラクルにおいて顕著な利点を持っています。
3.3 非中央集権と鍵管理の結合
鍵管理技術において、オラクルは完全な鍵zを持ち、完全な鍵zと増分ωに基づいてBIP32を使用することで、多数の子鍵z+{ω }\^{(1)}や孫鍵z+ω \^{(1)}+ω \^{(2)}を派生させることができます。異なるイベントに対して、オラクルは異なる孫秘密鍵z+ω \^{(1)}+ω \^{(2)}を使用して対応するイベントmsgに対して対応する署名σを生成できます。
非中央集権的オラクルのアプリケーションシナリオでは、n人の参加者が必要で、t+1人の参加者が閾値署名を行う必要があります。その中で、t。nのオラクルノードはそれぞれ秘密鍵の断片ziを持ち、i=1,…,nです。このn個の秘密鍵の断片ziは完全な秘密鍵zに対応しますが、完全な秘密鍵zは最初から最後まで現れません。完全な秘密鍵zが現れない前提の下で、t+1のオラクルノードは秘密鍵の断片ziを使用してメッセージmsg'に対して署名の断片σi'を生成し、署名の断片σ_i'を結合して完全な署名σ 'を生成します。検証者は完全な公開鍵Zを使用してメッセージ署名対(msg',σ ')の正当性を検証できます。t+1のオラクルノードが共同で閾値署名を生成する必要があるため、高いセキュリティを持っています。
しかし、非中央集権的オラクルのアプリケーションシナリオでは、完全な秘密鍵zが現れず、直接BIP32を使用して鍵を派生させることができません。言い換えれば、オラクルの非中央集権技術と鍵管理技術は直接結合することができません。
論文Distributed Key Derivation for Multi-Party Management of Blockchain Digital Assetsは閾値署名シナリオにおける分散鍵派生方法を提案しています。この論文の核心的な考え方は、ラグランジュ補間多項式に基づいて、秘密鍵の断片z_iと完全な秘密鍵zが以下の補間関係を満たすことです。
上式の両辺に増分ωを加えると、以下の等式が得られます。
この等式は、秘密鍵の断片ziに増分ωを加えたものと、完全な秘密鍵zに増分ωを加えたものが依然として補間関係を満たすことを示しています。言い換えれば、子秘密鍵の断片zi+ωと子鍵z+ωは補間関係を満たします。したがって、各参加者は秘密鍵の断片ziに増分ωを加えて子秘密鍵の断片zi+ωを派生させ、子署名の断片を生成することができ、対応する子公開鍵Z+ω ⋅ Gを使用して有効性の検証を行うことができます。
ただし、強化型と非強化型のBIP32を考慮する必要があります。強化型BIP32は秘密鍵、チェーンコード、およびパスを入力としてSHA512を計算し、増分と子チェーンコードを出力します。一方、非強化型BIP32は公開鍵、チェーンコード、およびパスを入力としてSHA512を計算し、増分と子チェーンコードを出力します。閾値署名の場合、秘密鍵が存在しないため、非強化型BIP32を使用する必要があります。または、同態ハッシュ関数を使用することで、強化型BIP32を実現できます。ただし、同態ハッシュ関数はSHA512とは異なり、元のBIP32とは互換性がありません。
3.4 OP-DLC:オラクルの信頼最小化
DLCにおいて、アリスとボブ間の契約はオラクルの署名結果に基づいて実行されるため、ある程度オラクルを信頼する必要があります。したがって、オラクルの行動が正しいことはDLCの運用において重要な前提です。
オラクルの信頼を低下させるために、既存の研究ではn個のオラクルの結果に基づいてDLCを実行し、単一のオラクルへの依存を減少させています。
- "n-of-n"モデルは、n個のオラクルを使用して契約を締結し、n個のオラクルの結果に基づいて契約を実行します。このモデルでは、n個のオラクルがすべてオンラインで署名する必要があります。オラクルのいずれかがオフラインであるか、結果に対して意見の相違がある場合、DLC契約の実行に影響を与えます。信頼仮定はn個のオラクルがすべて誠実であることです。
- "k-of-n"モデルは、n個のオラクルを使用して契約を締結し、その中のk個のオラクルの結果に基づいて契約を実行します。k個を超えるオラクルが共謀した場合、契約の公正な実行に影響を与えます。さらに、"k-of-n"モデルを使用する場合、準備するCETの数は単一のオラクルまたは"n-of-n"モデルのC_n\^k倍になります。信頼仮定はn個のオラクルの中に少なくともk個のオラクルが誠実であることです。
オラクルの数を増やしても、オラクルの信頼を低下させることはできません。なぜなら、オラクルが悪意を持った場合、契約の損害を受けた側にはチェーン上での申立ての手段がないからです。
したがって、本節ではOP-DLCを提案し、DLCに楽観的な挑戦メカニズムを導入します。 n個のオラクルはDLCの設定に参加する前に、悪意を持たないことを約束するために事前に質権を設定してpermissionlessチェーン上のOPゲームを構築する必要があります。いずれかのオラクルが悪意を持った場合、アリスまたはボブ、または他の誠実なオラクル、または他の第三者の誠実な観察者が挑戦を開始できます。挑戦者がゲームに勝利した場合、チェーン上で悪意のあるオラクルに対して罰則が科され、その質権が没収されます。さらに、OP-DLCは"k-of-n"モデルを使用して署名することもできます。その中で、kの値は1でも構いません。したがって、信頼仮定はネットワーク内に誠実な参加者が1人いればOP挑戦を開始し、悪意のあるオラクルノードを罰することができるというものになります。
Layer2の計算結果に基づいてOP-DLCを決済する場合:
- オラクルが誤った結果に署名し、アリスの利益が損なわれた場合、アリスはLayer2で正しい計算結果を使用して、オラクルが事前に質権を設定したpermissionlessチェーン上のOPゲームに挑戦を開始できます。アリスがゲームに勝利すれば、悪意のあるオラクルに罰則が科され、損失が補填されます;
- 同様に、ボブ、他の誠実なオラクルノード、第三者の誠実な観察者も挑戦を開始できます。ただし、悪意のある挑戦を防ぐために、挑戦者も質権を設定する必要があります。
したがって、OP-DLCはオラクルノード間の相互監視を実現し、オラクルの信頼を最小化します。このメカニズムは、誠実な参加者が1人いれば99%の耐障害性を持ち、オラクルの共謀リスクをうまく解決します。
3.5 OP-DLC + BitVMダブルブリッジ
DLCがクロスチェーンブリッジに使用される場合、DLC契約の決済時に資金の配分が必要です:
- CETを事前に設定する必要があります。これは、DLCの資金決済の粒度が限られていることを意味します。たとえば、Bisonネットワークでは0.1 BTCの粒度です。問題点:Layer2のユーザーの資産の相互作用は、DLC CETの資金粒度に制約されるべきではありません。
- アリスがLayer2の資産を決済したい場合、ユーザーのボブのLayer2の資産もLayer1に決済される必要があります。問題点:各Layer2ユーザーは、他のユーザーの出入金に影響されずに自由に出入金を選択できるべきです。
- アリスとボブが費用を協議します。問題点:両者が協力する意志が必要です。
したがって、上記の問題を解決するために、本節ではOP-DLC + BitVMダブルブリッジを提案します。このソリューションにより、ユーザーはBitVMのpermissionlessブリッジを介して入金と出金を行うことも、OP-DLCメカニズムを介して入金と出金を行うこともでき、任意の粒度の釣り銭を実現し、資金の流動性を向上させます。
OP-DLCにおいて、オラクルはBitVMアライアンスであり、アリスは一般ユーザー、ボブはBitVMアライアンスです。OP-DLCを設定する際に構築されるCETの中で、ユーザーアリスへの出力はLayer1上で即座に消費可能であり、ボブへの出力には「アリスが挑戦できるDLCゲーム」を構築し、タイムロックのロック期間を設定します。アリスが出金したい場合:
- もしBitVMアライアンスがオラクルとして正しく署名すれば、アリスはLayer1から引き出すことができます。ただし、ボブはロック期間が過ぎた後にLayer1から引き出すことができます。
- もしBitVMアライアンスがオラクルとして不正を行い、アリスの利益が損なわれた場合、アリスはボブのUTXOに対して挑戦を開始できます。挑戦が成功すれば、ボブの金額を没収できます。注意:他のBitVMアライアンスのメンバーの1人も挑戦を開始できますが、アリスの利益が損なわれたため、最も挑戦を行う動機があります。
- もしBitVMアライアンスがオラクルとして不正を行い、ボブの利益が損なわれた場合、BitVMアライアンス内の誠実なメンバーが「BitVMゲーム」に挑戦を開始し、不正を行ったオラクルノードを罰することができます。
さらに、ユーザーアリスがLayer2から出金したいが、OP-DLC契約内の事前設定されたCETに一致する金額がない場合、アリスは以下の方法を選択できます:
- BitVMを介して出金し、BitVMオペレーターがLayer1で立て替えます。BitVMブリッジはBitVMアライアンス内に誠実な参加者がいると仮定します。
- OP-DLC内の任意のCETを介して出金し、残りの釣り銭はBitVMオペレーターがLayer1で立て替えます。OP-DLCからの出金はDLCチャネルを閉じますが、DLCチャネル内の残りの資金はBitVM Layer1資金プールに転送され、他のLayer2ユーザーの出金を強制することはありません。OP-DLCブリッジの信頼仮定は、チャネル内に誠実な参加者がいることです。
- アリスとボブが費用を協議し、オラクルの参加を必要とせず、ボブの協力を求めます。
したがって、OP-DLC + BitVMダブルブリッジには以下の利点があります:
- BitVMを使用してDLCチャネルの資金の釣り銭問題を解決し、CETの設定数を減少させ、CETの資金粒度の影響を受けません;
- OP-DLCブリッジとBitVMブリッジを組み合わせて、ユーザーに多様な出金入金の経路を提供し、任意の粒度の釣り銭を実現します;
- BitVMアライアンスをボブとオラクルとして設定し、OPメカニズムを通じてオラクルの信頼を最小化します;
- DLCチャネルの出金余剰をBitVMブリッジ資金プールに導入し、資金の利用率を向上させます。
4. 結論
DLCはSegwit v1(Taproot)がアクティブになる前に登場し、DLCチャネルとライトニングネットワークの統合を実現し、同じDLCチャネル内で連続契約を更新して実行できるように拡張されました。TaprootやBitVMなどの技術を活用することで、DLC内でより複雑なオフチェーン契約の検証と決済を実現し、OP挑戦メカニズムを組み合わせてオラクルの信頼を最小化します。
参考文献
- Specification for Discreet Log Contracts
- Discreet Log Contracts
- Scaling DLC Part1: Off-chain Discreet Log Contracts
- Scaling DLC Part2: Free option problem with DLC
- Scaling DLC Part3: How to avoid free option problem with DLC
- Lightning Network
- DLC on Lightning
- DLC Private Key Management Part 1
- DLC Private Key Management Part 2: The Oracle's private keys
- DLC Key Management Pt 3: Oracle Public Key Distribution
- BitVM: Compute Anything on Bitcoin
- BitVM 2: Permissionless Verification on Bitcoin
- BitVM Off-chain Bitcoin Contracts
- BIP32BIP44
- Schnorr signature
- FROST: Flexible Round-Optimized Schnorr Threshold Signatures
- A Survey of ECDSA Threshold Signing
- Distributed Key Derivation for Multi-Party Management of Blockchain Digital Assets
- Segregated Witness
- Optimistic Rollup
- Taproot