1. Introduction

Discreet Log Contract（DLC）は、2018年にマサチューセッツ工科大学のTadge Dryjaによって提案されたオラクルに基づく契約実行フレームワークです。DLCを使用すると、2つの当事者は事前に定義された条件に基づいて条件付き支払いを実行できます。当事者は可能な結果を決定し、事前に署名し、オラクルが結果を承認すると、これらの事前署名を使用して支払いを実行できます。したがって、DLCはビットコインの預金のセキュリティを確保しながら新しい分散型金融アプリケーションを可能にします。

ライトニングネットワークと比較すると、DLCには次の重要な利点があります。

• プライバシー：DLCはライトニングネットワークよりもプライバシー保護が向上しています。契約の詳細は関係者間でのみ共有され、ブロックチェーンには保存されません。一方、ライトニングネットワークの取引は公開チャネルとノードを経由してルーティングされるため、その情報は公開され透明です。
• 金融契約の複雑さと柔軟性: DLCはビットコインネットワーク上で派生品、保険、賭けなどの複雑な金融契約を直接作成および実行できます。一方、ライトニングネットワークは主に迅速で小額の支払いに使用され、複雑なアプリケーションをサポートすることはできません。
• カウンターパーティリスクの軽減: DLC資金はマルチサイン契約でロックされ、事前に定義されたイベントの結果が発生したときにのみリリースされるため、契約に違反する当事者のリスクが軽減されます。ライトニングネットワークは信頼の必要性を減らしますが、チャネル管理や流動性提供には依然としてある程度のカウンターパーティリスクがあります。
• 支払いチャネルを管理する必要はありません：DLCの運用には、ライトニングネットワークに不可欠で複雑でリソースを多く必要とする支払いチャネルの作成や保守が不要です。
• 特定のユースケース向けの拡張性：ライトニングネットワークはビットコインの取引スループットをある程度増やしますが、DLCはビットコイン上の複雑な契約に対してより良い拡張性を提供します。

ビットコインエコシステムにおいてDLCは重要な利点を有していますが、いくつかのリスクや問題も依然として存在しています。

• キーのリスク: オラクルの秘密鍵やコミットされたナンスの漏洩や損失のリスクがあり、それによりユーザー資産が失われる可能性があります。
• 中央集権信頼リスク：オラクルの中央集権化は容易にサービス拒否攻撃につながる可能性があります。
• 分散キー導出の問題: もしオラクルが分散している場合、オラクルノードはプライベートキーのシェアのみを保有します。しかし、分散型オラクルノードはこれらのプライベートキーシェアに基づいて直接BIP32を使用することはできません。
• 共謀リスク：オラクルノードが互いにまたはある一方と共謀した場合、オラクルに対する信頼問題は未解決のままです。信頼性のある監視メカニズムが必要です。
• 固定枚数変更問題：条件付き署名は、トランザクションを構築する前に決定論的で列挙可能なイベントのセットが必要です。したがって、資産再配分にDLCを使用すると、最小金額制限が生じ、固定枚数の変更の問題が発生します。

これらの課題に対処するため、本論文では、DLCに関連するリスクや問題を軽減するためのいくつかの解決策や最適化アイデアを提案し、Bitcoinエコシステムのセキュリティを向上させる。

2. DLC原則

アリスとボブは、(n+k)番目のブロックのハッシュ値が奇数か偶数かについての賭け契約を結びます。奇数の場合、アリスがゲームに勝ち、時間t内に資産を引き出すことができます。偶数の場合、ボブがゲームに勝ち、時間t内に資産を引き出すことができます。DLCを使用して、(n+k)番目のブロック情報がオラクルを介して伝送され、条件付き署名が構築され、正しい勝者がすべての資産を受け取ることが保証されます。

初期化：楕円曲線の生成子はGであり、その次数はqである。

キー生成：オラクル、アリス、ボブはそれぞれ独自の秘密鍵と公開鍵を生成します。

• オラクルの秘密鍵はzであり、その公開鍵はZであり、Z=z⋅Gを満たしています;
• アリスの秘密鍵はxであり、彼女の公開鍵はXであり、X=x⋅Gを満たしています;
• Bobの秘密鍵はyであり、彼の公開鍵はYであり、Y=y⋅Gを満たしています。

資金取引：アリスとボブは共に資金取引を作成し、2つの公開鍵X（アリスの鍵）とY（ボブの鍵）を持つ2-of-2のマルチシグナチャ出力にそれぞれ1 BTCをロックします。

契約執行トランザクション（CET）：アリスとボブは、資金取引を支出するために2つのCETを作成します。

オラクルはコミットメントを計算します

その後、SとS′を計算します

および放送（R、S、S′）。

AliceとBobはそれぞれ対応する新しい公開キーを計算します

決済：（n+k）番目のブロックが現れた後、オラクルはそのブロックのハッシュ値に基づいて対応するsまたはs'を生成します。

• もし（n+k)番目のブロックのハッシュ値が奇数である場合、Oracleは計算を行いブロードキャストします

• (n+k)番目のブロックのハッシュ値が偶数である場合、Oracleは計算を行いブロードキャストします

出金：アリスまたはボブは、オラクルによってブロードキャストされた s または s′ に基づいて資産を引き出すことができます。

• もしオラクルがsをブロードキャストした場合、アリスは新しい秘密鍵sk^{Alice}を計算し、ロックされた2 BTCを引き出すことができます

• オラクルがs′をブロードキャストした場合、Bobは新しい秘密鍵sk^{Bob}を計算し、ロックされた2 BTCを引き出すことができます

解析：アリスによって計算された新しい秘密鍵sk^{Alice}と新しい公開鍵PK^{Alice}は離散対数関係を満たします

したがって、アリスの引き出しが成功します。

同様に、Bobによって計算された新しい秘密鍵sk^{Bob}と新しい公開鍵PK^{Bob}は離散対数関係を満たす

したがって、ボブの引き出しは成功します。

さらに、Oracleがsをブロードキャストした場合、それはアリスにとって有用ですが、Bobにとっては有用ではありません。なぜなら、Bobは対応する新しい秘密鍵sk^{Bob}を計算することができません。同様に、Oracleがs′をブロードキャストした場合、それはBobにとって有用ですが、アリスにとっては有用ではありません。なぜなら、Aliceは対応する新しい秘密鍵sk^{Alice}を計算することができないからです。最後に、上記の説明ではタイムロックが省略されています。新しい秘密鍵を計算し、時間t内に引き出すことを可能にするためにタイムロックを追加する必要があります。そうでない場合、時間tを超過すると、他の当事者が元の秘密鍵を使用して資産を引き出すことができます。

3. DLC 最適化

3.1 キー管理

DLCプロトコルでは、オラクルの秘密鍵とコミットされたナンスが重要です。オラクルの秘密鍵とコミットされたナンスの漏洩や紛失は、次の4つのセキュリティ問題につながる可能性があります:

(1) オラクルがプライベートキーzを失う

もしオラクルが秘密鍵を失った場合、DLCは解決することができず、DLCの払い戻し契約の実行が必要となります。そのため、DLCプロトコルにはオラクルが秘密鍵を失う結果を防ぐための払い戻しトランザクションが含まれています。

(2) オラクルのプライベートキーz漏洩

オラクルの秘密鍵が漏洩した場合、その秘密鍵に基づくすべてのDLCは不正な決済のリスクに直面します。秘密鍵を盗んだ攻撃者は任意のメッセージに署名し、すべての将来の契約の結果を完全に制御することができます。さらに、攻撃者は単一の署名済みメッセージを発行するだけでなく、（n+k）番目のブロックのハッシュ値が奇数でありかつ偶数であることなど、矛盾するメッセージを公開することもできます。

(3) オラクルのNonce kの漏洩または再利用

オラクルがノンスkを漏洩した場合、決済フェーズでは、オラクルがsまたはs'をブロードキャストするかどうかに関係なく、攻撃者は次のようにオラクルの秘密鍵zを計算できます:

オラクルがノンス k を再利用すると、2 回の決済後、攻撃者はオラクルのブロードキャスト署名に基づいた方程式のシステムを解いて、4 つの可能なシナリオのうちの 1 つでオラクルの秘密鍵 z を導出することができます。

case 1:

case 2:

ケース3:

ケース4:

(4) Oracle Loses Nonce k

オラクルがナンスkを失うと、対応するDLCは解決できず、DLC返金契約の実行が必要となります。

したがって、Oracleの秘密鍵のセキュリティを強化するために、署名用の子孫キーまたは孫キーを導出するためにBIP32を使用することをお勧めします。また、ノンスのセキュリティを高めるために、ハッシュ値k:=hash(z, counter)をノンスkとして使用し、ノンスの繰り返しや損失を防ぐために利用すべきです。

3.2 分散型オラクル

DLCでは、オラクルの役割は重要であり、契約の結果を決定する重要な外部データを提供します。これらの契約のセキュリティを向上させるには、分散型オラクルが必要です。集中型オラクルとは異なり、分散型オラクルは正確で改ざん防止対策の取られたデータの提供責任を複数の独立したノードに分散し、単一障害点に関連するリスクを低減し、操作や標的型攻撃の可能性を減らします。分散型オラクルを使用することで、DLCはより高度な信頼性と信頼性を実現し、契約の実行が完全に予め決定された条件の客観性に依存することを保証します。

Schnorr閾値署名は分散型オラクルを実装するために使用できます。 Schnorr閾値署名には次の利点があります:

• セキュリティ強化：キーの管理を分散することにより、閾値署名は単一障害点のリスクを軽減します。一部の参加者のキーが危険にさらされたり攻撃を受けたとしても、事前に定義された閾値を超えない限り、システム全体は安全です。
• 分散制御：しきい値署名により、鍵管理を分散制御し、すべての署名権を保持する単一のエンティティを排除することで、権力集中に関連するリスクを低減します。
• 改善された可用性：特定の数のオラクルノードが合意すれば、署名を完了できるため、システムの柔軟性と可用性が向上します。一部のノードが利用できなくても、全体的なシステムの信頼性に影響はありません。
• 柔軟性と拡張性：閾値署名プロトコルは、さまざまなセキュリティ要件やシナリオに対応するために必要な異なる閾値を設定できます。さらに、大規模ネットワークに適しており、優れた拡張性を提供しています。
• アカウンタビリティ：各オラクルノードは、それ自身の秘密キー共有に基づいて署名シェアを生成し、他の参加者は対応する公開キー共有を使用してこの署名シェアの正確性を検証でき、アカウンタビリティを実現します。正しい場合、これらの署名シェアは蓄積されて完全な署名が生成されます。

したがって、Schnorr閾値署名プロトコルは、セキュリティ、信頼性、柔軟性、スケーラビリティ、および説明責任の向上において、分散型オラクルにおいて著しい利点を持っています。

3.3 分散化とキー管理の結合

キー管理技術において、オラクルは完全なキーzを所有し、BIP32と増分ωを使用して、多数の子キーz+ω^{(1)}および孫キーz+ω^{(1)}+ω^{(2)}を導出することができます。異なるイベントでは、オラクルはさまざまな孫プライベートキーz+ω^{(1)}+ω^{(2)}を使用して、それぞれのイベントmsgに対応する署名σを生成できます。

分散型Oracleシナリオでは、n人の参加者がおり、しきい値署名にはt+1人の参加者が必要で、ここでt

しかし、分散型オラクルのシナリオでは、完全なプライベートキーzが表示されないため、BIP32を使用した直接のキー導出は不可能です。言い換えれば、分散型オラクル技術とキー管理技術は直接統合することはできません。

その論文 “ブロックチェーンデジタル資産のマルチパーティ管理のための分散キー導出閾値署名シナリオにおける分散鍵導出スキームを提案します。中心となるアイデアは、ラグランジュ補間多項式に基づいており、個々の秘密鍵シェア z_i と完全な秘密鍵 z が次の補間関係を満たすという点です。

方程式の両側に増分ωを加えると、

この式は、プライベートキーのシェアz_iに増分ωを加えたものが、完全なプライベートキーzにωを加えた補間関係を満たすことを示しています。言い換えると、子プライベートキーのシェアz_i+ωと子キーz+ωは、補間関係を満たします。したがって、各参加者は、子プライベートキーのシェアz_iに増分ωを加えて子プライベートキーのシェアz_i+ωを導出し、子署名のシェアを生成し、それらを対応する子公開鍵Z+ω⋅Gを使用して検証できます。

ただし、硬化および非硬化されたBIP32を考慮する必要があります。硬化BIP32は、秘密鍵、チェーンコード、およびパスを入力とし、SHA512を実行し、増分と子チェーンコードを出力します。一方、非硬化BIP32は、公開鍵、チェーンコード、およびパスを入力とし、SHA512を実行し、増分と子チェーンコードを出力します。閾値署名シナリオでは、秘密鍵は存在しないため、非硬化BIP32のみを使用できます。または、同型性ハッシュ関数を使用するか、硬化BIP32を適用することができます。ただし、同型性ハッシュ関数はSHA512とは異なり、元のBIP32と互換性がありません。

3.4 OP-DLC: Oracle Trust-minimized

DLCでは、アリスとボブの間の契約は、オラクルの署名された結果に基づいて実行されるため、オラクルへのある程度の信頼が必要です。そのため、オラクルの正しい動作は、DLCの運用にとって重要な前提条件です。

Oracleへの信頼を減らすために、1つのOracleへの依存を減らすために、n個のOracleの結果に基づいてDLCを実行する研究が行われています。

• 「n-of-n」モデルは、n人のオラクルを使用して契約に署名し、すべてのオラクルの結果に基づいて契約を実行することを含みます。このモデルでは、すべてのオラクルが署名のためにオンラインである必要があります。オラクルのいずれかがオフラインになった場合や結果に意見の相違がある場合、それはDLC契約の実行に影響します。ここでの信頼の前提は、すべてのオラクルが正直であるということです。
• 「k-of-n」モデルは、契約に署名するためにn個のオラクルを使用し、任意のk個のオラクルの結果に基づいて契約を実行することを含みます。 k個以上のオラクルが共謀すると、契約の公正な実行に影響します。さらに、「k-of-n」モデルで必要なCETの数は、1つのオラクルまたは「n-of-n」モデルのC_n^k倍です。このモデルの信頼仮定は、少なくともn個のオラクルのうちk個が正直であるというものです。

単にオラクルの数を増やすだけでは、オラクルの不信を解消することはできません。なぜなら、オラクルの悪意のある行為の後、契約上の被害者はチェーン上で救済手段を持っていないからです。

したがって、私たちはOP-DLCを提案しています。これは、楽観的なチャレンジメカニズムをDLCに組み込んでいます。DLCの設定に参加する前に、n人のオラクルは事前にプレッジをし、許可なしでチェーン上のOPゲームを構築し、悪意を持って行動しないことを約束する必要があります。もしオラクルの1人が悪意を持って行動した場合、アリス、ボブ、他の正直なオラクル、または他の第三者の正直な観察者はチャレンジを開始することができます。もしチャレンジャーがゲームに勝利した場合、チェーン上のシステムは悪意を持つオラクルのデポジットを没収します。さらに、OP-DLCは署名のための「k-of-n」モデルを採用することもできます。ここで、kの値は1であっても構いません。したがって、信頼の前提は、ネットワークに正直な参加者が1人だけ必要で、OPチャレンジを開始し、悪意を持つオラクルノードを罰することができます。

Layer 2の計算結果に基づいてOP-DLCを決済する場合:

• オラクルが誤った結果で署名した場合、アリスが損失を被ることになりますが、アリスは正しいレイヤー2の計算結果を使用して、オラクルの事前公約なしのオンチェーンOPゲームに挑戦することができます。ゲームに勝利すると、アリスは悪意のあるオラクルに罰金を科し、損失を補償することができます。
• 同様に、ボブ、他の正直なオラクルノード、および第三者の正直な観察者もチャレンジを開始することができます。ただし、悪意のあるチャレンジを防ぐためには、チャレンジャーも質入れしなければなりません。

そのため、OP-DLCはオラクルノード間の相互監視を容易にし、オラクルに置かれる信頼を最小限に抑えます。このメカニズムは1人の正直な参加者だけを必要とし、99%の故障耐性を持ち、オラクルの共謀のリスクに効果的に対処します。

3.5 OP-DLC + BitVM デュアルブリッジ

DLCをクロスチェーンブリッジに使用する場合、資金分配はDLC契約の決済時に行われなければなりません:

• DLCの資金決済の細かさは、Bisonネットワークで0.1 BTCのように制限されているため、事前にCETを設定する必要があります。これにより、ユーザーのレイヤー2資産取引がDLC CETの資金細かさで制限されるべきではありません。
• Aliceがレイヤー2の資産を解決したいとき、ユーザーBobのレイヤー2の資産もレイヤー1に強制的に解決されます。これにより問題が発生します：各レイヤー2ユーザーは、他のユーザーの行動とは独立して、預金と引き出しを自由に選択できるべきです。
• アリスとボブは支出を交渉します。問題は、両当事者が協力する意思が必要であることです。

したがって、上記の問題に対処するために、私たちはOP-DLC + BitVMデュアルブリッジを提案します。このソリューションにより、ユーザーはBitVMの許可なしブリッジを介して入金および出金することができるだけでなく、OP-DLCメカニズムを介して、いかなる粒度の変更も実現し、流動性を向上させることができます。

OP-DLCでは、オラクルはBitVM連盟であり、アリスは通常のユーザー、ボブはBitVM連盟です。 OP-DLCを設定する際、構築されたCETにより、アリスの出力を第1レイヤーで即座に使用できる一方、ボブの出力には「アリスが挑戦できるDLCゲーム」が含まれ、タイムロック期間があります。 アリスが引き出したい場合:

• BitVM連盟がオラクルとして正しく署名した場合、アリスはレイヤー1で引き出すことができます。ただし、タイムロック期間後にボブはレイヤー1で引き出すことができます。
• BitVM連合体がOracleとして不正を働いた場合、Aliceに損失を与えたため、BobのUTXOに挑戦することができます。挑戦が成功した場合、Bobの金額は没収される可能性があります。注：BitVM連合体の別のメンバーも挑戦を開始することができますが、被害を受けたAliceが最も動機づけられているため、そうする可能性が高いです。
• BitVM連盟がオラクルとして不正行為を行い、ボブに損害を与えた場合、BitVM連盟の誠実なメンバーはその不正行為を罰するために「BitVMゲーム」に挑戦できます。

また、ユーザーのアリスがレイヤー2から引き出したい場合、OP-DLC契約内の事前設定されたCETの金額が一致しない場合、アリスは以下の方法を選択できます:

• BitVMを介して引き出し、BitVMオペレーターが第1レイヤーで金額をフロントしました。 BitVMブリッジは、BitVM連盟に少なくとも1人の正直な参加者がいると仮定します。
• OP-DLCで特定のCETを通じて引き出し、残りのお釣りはLayer 1のBitVMオペレーターによって支払われます。OP-DLCを介して引き出すと、DLCチャンネルが閉じられますが、DLCチャンネル内の残高は他のLayer 2ユーザーに引き出しを強制することなく、BitVM Layer 1プールに移動します。OP-DLCブリッジは、そのチャンネルに少なくとも1人の誠実な参加者がいると仮定しています。
• アリスとボブは、オラクルの関与なしに支出を協議し、ボブからの協力を必要としています。

したがって、OP-DLC + BitVMデュアルブリッジには、次の利点があります。

• BitVMはDLCチャンネルの変更問題を解決し、必要なCETの数を削減し、CET基金の粒度に影響を受けません。
• OP-DLCブリッジとBitVMブリッジを組み合わせることで、ユーザーに入出金のための複数のチャネルを提供し、ユーザーエクスペリエンスを向上させます。
• BitVMコンソーシアムをボブとオラクルの両方として設定し、OPメカニズムを利用することで、オラクルへの信頼を最小限に抑えます;
• DLCチャネルからの余剰引き出しをBitVMブリッジプールに統合することで、資金利用を向上させます。

4. 結論

DLCは、Segwit v1（Taproot）の有効化よりも前に現れ、すでにライトニングネットワークに統合されており、同じDLCチャネル内での継続的な契約の更新と実行を可能にしています。TaprootやBitVMなどの技術により、より複雑なオフチェーン契約の検証と決済がDLC内で実装されることがあります。さらに、OPチャレンジメカニズムを統合することで、Oraclesへの信頼を最小限に抑えることが可能になります。

声明:

1. この記事は再版されました中間, 元のタイトルは「Bitlayer Core Technology: DLCおよびその最適化に関する考慮事項」で、著作権は元の著者に属しています。ビットレイヤー。もし、この転載に異議がある場合は、お問い合わせください。Gate Learnチーム. チームは関連手続きに応じてできるだけ迅速に対応します。

2. 免責事項：この記事で表現されている見解や意見は、著者個人の見解を表しており、投資アドバイスを構成するものではありません。

3. 他の言語版はGate Learnチームによって翻訳されました。言及なしでGate, 翻訳された記事はコピー、拡散、または盗用されていない可能性があります。