DLC の技術原理と最適化のアイデアに関するディスカッション

1. 概要

離散対数契約(DLC)は、オラクルに基づく条件付き支払いの仕組みであり、MITのTadge Dryjaによって2018年に提案されました。DLCは、両者が事前に定義された条件に基づいて支払いを行うことを可能にし、参加者は可能な結果を事前に決定し、事前に署名します。オラクルが結果に署名した際に支払いが実行されます。これにより、DLCはビットコインの預金の安全性を保障しながら、新しい分散型金融アプリケーションを実現することができます。

閃電ネットワークと比較して、DLC には以下の利点があります:

• より良いプライバシー: 契約の詳細は参加者間でのみ共有され、ブロックチェーン上には保存されません
• 複雑な金融契約をサポート: ビットコインネットワーク上でデリバティブや保険などの複雑な契約を直接作成および実行できます。
• 相手方リスクの低減:資金はマルチシグ契約にロックされており、事前に定義されたイベントの結果が出たときのみ解放されます。
• 支払いチャネルの管理が不要: 操作が簡単で、支払いチャネルの作成や維持が必要ありません
• 特定のシーンでより良いスケーラビリティ: 複雑な契約に関して良好なスケーラビリティを提供します

しかし、DLCにはいくつかのリスクと問題が依然として存在します。

• オラクルの秘密鍵と乱数が漏洩または紛失する可能性があり、資産損失につながる。
• オラクルには中央集権的な信頼リスクが存在し、サービス拒否攻撃を受けやすいです。
• 分散型オラクルは直接キーの派生を行うことができません
• オラクルノードが共謀する可能性があり、信頼の問題が依然として存在する
• 条件付き署名は、事前にイベントのセットを定める必要があるため、資産の再配分には最小金額制限が存在します。

この記事では、上記の問題を解決し、ビットコインエコシステムの安全性を向上させるためのいくつかの最適化提案について探討します。

2. DLCの仕組み

アリスとボブが賭け契約を結ぶ例を挙げると、賭け金は n+k 番目のブロックハッシュの奇数性です。奇数の場合、アリスが勝ち、それ以外の場合はボブが勝ちます。DLC はオラクルを介してブロック情報を伝達し、条件付き署名を構築することで、勝者がすべての資産を獲得できるようにします。

具体的な手順は以下の通りです:

1. 初期化:楕円曲線ジェネレータGを次数qで設定します。

2. キー生成: オラクル、アリス、ボブはそれぞれ秘密鍵と公開鍵を生成します。 Oracles: 秘密鍵 z, 公開鍵 Z = z· G アリス:秘密鍵x、公開鍵X=x·G
   ボブ: 秘密鍵 y、公開鍵 Y = y· G

3. 注資取引:アリスとボブは注資取引を作成し、それぞれ1BTCを2-of-2マルチシグ出力にロックします。

4.先物執行取引:資金提供された取引に使用する2つの先物執行取引(CET)を作成します。

5. オラクル計算のコミットメント: R := k· G S := R - hash(奇数番号,R)· Z S' := R - hash(偶数,R)· Z ブロードキャスト(R,S,S')

6. アリスとボブが新しい公開鍵を計算する: PK^アリス := X + S PK^ボブ := Y + S'

7. 決済:オラクルは第 n+k ブロックのハッシュ値に基づいて s または s' を生成します。 奇数: s := k - hash(OddNumber, R)·z 偶数: s': = k - hash(EvenNumber, R)·z

8. 引き出し: 勝者は s または s' に基づいて新しいプライベートキーを計算し、資産を引き出します。 アリス:sk^アリス := x + s ボブ:sk^ボブ:= y + s'

分析によると、計算された新しい秘密鍵と新しい公開鍵は離散対数関係を満たしており、成功裏に出金できます。

さらに、引き出し時間を制限するためにタイムロックを追加する必要があり、期限切れ後に相手が資産を持ち去るのを防ぎます。

! DLC原理分析と最適化思考

3. DLCの最適化

3.1 キー管理

オラクルのプライベートキーとランダム数のセキュリティは非常に重要であり、漏洩または紛失するとさまざまなセキュリティ問題を引き起こす可能性があります:

1. 秘密鍵を失った: 決済できず、返金契約を実行する必要があります
2. 秘密鍵の漏洩: すべての DLC は詐欺決済リスクに直面しています
3. ランダム数の漏洩または再利用: プライベートキーを導き出すことができる
4. ランダム数の喪失:特定のDLCを決済できません

以下の対策を講じることをお勧めします:

• BIP32 を使用して子鍵または孫鍵を派生させて署名に使用する
• プライベートキーとカウンターのハッシュ値を乱数として使用する

3.2 分散型オラクル

Schnorr 門限署名を用いて非中央集権型オラクルを実現し、以下の利点があります:

• セキュリティの向上: 分散型キー管理、単一障害点のリスクを軽減
• 分散型コントロール: 単一の実体がすべての署名権を持たない
• 可用性の向上:閾値に達するだけで署名を完了できます
• 柔軟性とスケーラビリティ:異なる閾値を設定でき、さまざまなシーンに適応可能
• 責任追跡性: 各ノードの署名スライスの正確性を検証可能

3.3 分散化と鍵管理の結合

去中心化予言機のシナリオでは、完全な秘密鍵が現れず、BIP32を直接使用して鍵を派生することができません。分散型鍵派生方法を採用することができます:

• ラグランジュ補間多項式に基づき、秘密鍵のシェアと完全な秘密鍵は補間関係を満たします。
• プライベートキーの分割にインクリメントを加えた後、サブキーは引き続き補間関係を満たします。
• 各参加者は子プライベートキーのシェアを派生させて子署名のシェアを生成することができます。

強化型と非強化型BIP32の互換性の問題を考慮する必要があります。

! DLC原理分析と最適化思考

3.4 OP-DLC: Oracle の信頼の最小化

OP-DLCメカニズムを提案し、楽観的な挑戦を導入します:

• オラクルは事前にステーキングしてオンチェーンOPゲームを構築する必要があります
• どんな正直な参加者でも悪行に対して挑戦を起こすことができる
• チャレンジ成功の場合、チェーン上で悪事を働く予言者に罰則が科されます
• "k-of-n" モデル署名を採用できます。k 値は 1 にすることができます。
• 信頼仮定が、ネットワーク内に1つの誠実な参加者がいるだけで済むように低下する

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

OP-DLC と BitVM を組み合わせて、クロスチェーンブリッジにおける DLC の問題を解決する。

• BitVMを使用してお釣りの問題を解決し、CETの数量を減らす
• 様々な入出金チャネルを提供し、任意の粒度でのお釣りを実現
• BitVM アライアンスを Bob とオラクルに設定し、信頼を最小化する
• DLCチャネルの出金余量をBitVM資金プールに導入し、利用率を向上させる

! DLC原理分析と最適化思考

4. エピローグ

DLCは、TaprootやBitVMなどの新技術と組み合わせることで、より複雑なオフチェーン契約の検証と決済を実現できます。OPチャレンジメカニズムを通じて、オラクルの信頼最小化をさらに実現し、ビットコインエコシステムにより多くの可能性をもたらします。