DLCの原理とその最適化の説明

$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をブロードキャストした場合、アリスには効くが、ボブには効かない。なぜならBobは対応する新しい秘密鍵sk^{Bob}を計算するのに使えないからである。同様に、述語マシンがs'をブロードキャストした場合、それはボブには有効だが、 アリスには有効ではない。なぜなら、アリスは対応する新しい秘密鍵sk^{Alice}を計算するために使うことができないからである。

最後に、上記の説明では時間ロックが省略されている。パーティがt時間以内に新しい秘密鍵を計算し、コインを引き出すように、時間ロックを追加する必要がある。そうしないと、t時間を超えた場合、もう一方の当事者は元の秘密鍵を使って資産を引き出すことができます。

3.DLCの最適化

3.1 鍵の管理

DLCプロトコルでは、述語マシンの秘密鍵と約束の乱数が重要です。もし述語マシンの秘密鍵と約束乱数が漏れたり紛失したりした場合、以下の4つのセキュリティ問題が発生します。

(1) 述語マシンによる秘密鍵の紛失

もし述語マシンが秘密鍵を紛失した場合、DLCの決済ができなくなり、DLC返金契約を実行する必要が生じます。そのため、予言マシンが秘密鍵を失うことを防ぐために、DLCプロトコルに払い戻しトランザクションが設定されています。

(2)予言マシンの秘密鍵が漏れる

予言マシンの秘密鍵が漏れると、その秘密鍵に基づくすべてのDLCが不正決済の危険にさらされます。秘密鍵を盗んだ攻撃者は、好きなメッセージに署名することができ、将来のすべての契約の結果を完全にコントロールすることができます。さらに、攻撃者は単一の署名付きメッセージを投稿するだけでなく、奇数と偶数のハッシュ値で同時にn+k番目のブロックに署名するなど、矛盾したメッセージを投稿することもできます。

(3)予測者が乱数kを漏らす、または再利用する

予測者が乱数kを漏らした場合、攻撃者は、予測者がsをブロードキャストするかs'をブロードキャストするかにかかわらず、決済フェーズ中に予測者の秘密鍵zを以下のように計算することができます

$z:=(k-s)/hash(OddNumber, R)$<。/p>

$z:=(k-s')/hash(EvenNumber, R)$

述語マシンが乱数kを再利用する場合、2回の決済後、攻撃者は述語マシンによってブロードキャストされた署名に基づいて方程式系を解き、以下の4つのシナリオのいずれかに基づいて述語マシンの秘密鍵zを見つけることができます。hash(OddNumber_1, R)・z$

$s_2=k-hash(OddNumber_2, R)・z$

ケース2:

$s_1'=k-hash(EvenNumber_1, R)・z$

$s_2'=k-hash(EvenNumber_2, R)・z$

ケース3:

$s_1=k-hash(OddNumber_1, R)・z$

$s_2'=k-hash(EvenNumber_2, R)・z$

ケース4:

$s_1'=k-hash(EvenNumber_1, R)hash(EvenNumber_1, R)・z$

$s_2=k-hash(OddNumber_2, R)・z$

(4) 予言マシンが乱数kを失う

予言マシンが乱数kを失うと、対応するDLCを決済できず、DLC払い戻し契約を実行する必要がある。DLC払い戻し契約を実行する必要がある。

したがって、予言マシンの秘密鍵の安全性を向上させるために、BIP32を使用して署名用のサブ秘密鍵またはグランド鍵を導出すべきである。さらに、乱数の安全性を向上させるために、乱数が複製されたり失われたりした場合に備えて、秘密鍵とカウンタのハッシュ値k:=hash(z, counter)を乱数kとして使用すべきである。

3.2分散型予測マシン

DLCにおける予測マシンの役割は非常に重要であり、契約の結果を決定する重要な外部データを提供します。これらの契約の安全性を向上させるために、分散型予言機が必要となります。中央集権型の予言マシンと異なり、分散型の予言マシンは、正確で改ざんされにくいデータを提供する責任を、複数の独立したノードに分散させることで、単一障害点に依存するリスクを減らし、操作や標的型攻撃の可能性を減少させます。分散型プレディケーターにより、DLCはより高度な信頼性と無信頼性を達成することができ、契約の実行があらかじめ決められた条件の客観性だけに依存することを保証します。

Schnorr Threshold Signaturesは、分散型述語を可能にします。

• 強化されたセキュリティ： 鍵の管理を分散することで、Threshold Signaturesは単一障害点のリスクを低減します。単一障害点のリスクを低減します。一部の参加者の鍵が漏洩したり攻撃されたりしても、設定されたしきい値を超えない限り、システム全体は安全なままです。

• 分散制御：閾値署名は、単一のエンティティがすべての署名権限を保持することなく、鍵管理の分散制御を可能にします。

• 可用性の向上：署名は一定数の述語ノードの同意で完了できるため、システムの柔軟性と可用性が向上します。一部のノードが利用できなくても、システム全体の信頼性の高い運用には影響しません。

• 柔軟性と拡張性：閾値署名プロトコルは、さまざまな異なるセキュリティニーズやシナリオに適応するために、必要に応じて異なる閾値を設定することができます。さらに、スケーラビリティに優れた大規模ネットワークにも適しています。

• リコース可能性：各述語ノードは秘密鍵スライスに基づいてメッセージの署名スライスを生成し、他のすべての参加者は対応する公開鍵スライスを使用して署名スライスの正しさを検証し、リコースを達成することができます。もしそれが正しければ、署名スライスは完全な署名を生成するために蓄積される。

このように、Schnorr閾値署名プロトコルは、セキュリティ、信頼性、柔軟性、スケーラビリティ、リコースを向上させる分散型述語における重要な利点を持つ。

3.3鍵管理と結合した分散化

鍵管理技術では、予言マシンは完全な鍵zを所有する。完全な鍵zと増分ωに基づいて、多数のサブ鍵z + {ω }^{(1)}とグランド鍵z + ω ^{(1)} + ω ^{(2)}は、BIP32を使用してディスパッチすることができる。異なるイベントに対して、述語マシンは異なるSun秘密鍵z+ω ^{(1)}+ω ^{(2)}を使用して、対応するイベントmsgに対応する署名σを生成することができる。

分散型予言マシンの応用シナリオでは、n人の参加者がいて、閾値署名にはt+1人の参加者が必要である。ここで、t. n個の予言マシンノードはそれぞれ秘密鍵スライスz_i, i=1,... ,nを持つ。これらのn個の秘密鍵ス ライスz_iは完全な秘密鍵zに対応するが、完全な秘密鍵zは最初から最後まで現れない。完全な秘密鍵zが出現しないことを前提に、t+1個の述語マシン・ノードは、 メッセージmsgに秘密鍵スライスz_i, i=1,... ,t+1個を使用する。署名スライスσ_i'は完全な署名σ 'にマージされる。検証者は、完全な公開鍵Zを用いて、メッセージ署名ペア(msg',σ ')の正しさを検証することができる。t+1個の述語マシンノードが共同で閾値署名を生成する必要があるため、高い安全性を持つ。

しかし、分散化された予言マシンの応用シナリオでは、完全な秘密鍵zは現れず、鍵導出はBIP32を使って直接実行できない。言い換えれば、予言マシンの分散化技術を鍵管理技術と直接結合することはできません。

論文「Distributed Key Derivation for Multi-Party Management of Blockchain Digital Assets」は、閾値署名シナリオの下での分散鍵導出法を提案している。この論文の核となる考え方は、ラグランジュ補間多項式に従って、秘密鍵スライスz_iが完全な秘密鍵zと以下の補間関係を満たすというものです

上記の式の両辺に増分ωを加えて、以下の式を得ます

この式は、秘密鍵スライスz_iに増分ωを加えたものが、依然として完全秘密鍵zに増分ωを加えたものとの補間関係を満たすことを示している。言い換えると、サブ秘密鍵スライスz_i + ωは、サブ鍵z + ωとの補間関係を満たす。したがって、各参加者は、秘密鍵スライスz_iにインクリメントωを加えたものを使用して、サブ署名スライスを生成するためのサブ秘密鍵スライスz_i+ωを導出することができ、対応するサブ公開鍵Z+ω・  Gを使用して有効性を検証することができる。

ただし、拡張BIP32と非拡張BIP32を比較検討する必要があります。拡張BIP32は、秘密鍵、チェーンコード、パスを入力としてSHA512を計算し、インクリメンタルコードとサブチェーンコードを出力します。一方、非強化BIP32は、公開鍵、チェーンコード、パスを入力とし、 SHA512を計算し、インクリメントコードとサブチェーンコードを出力する。閾値署名の場合、秘密鍵は存在しないので、非強化型BIP32しか使用できない。同型ハッシュ関数を使用する場合は、拡張型BIP32がある。

3.4OP-DLC：予言マシンの信頼最小化

DLCでは、アリスとボブ間の契約は予言マシンの署名結果に基づいて実行されるため、予言マシンに対するある程度の信頼が必要となる。したがって、予言マシンの正しい動作はDLCが機能するための主要な前提条件となる。

述語マシンを信頼しないために、n個の述語マシンの結果に基づいてDLCを実行し、単一の述語マシンへの依存を減らす研究があります。

• 「n-of-n」モデルは、n台の述語マシンを使用して契約を締結し、n台の述語マシンの結果に基づいて契約を実行することを表しています。このモデルは、すべてのn台の述語マシンがオンラインで署名することを必要とする。予測マシンのいずれかがオフラインであったり、結果について不一致であったりすると、DLCの契約実行に影響する。信頼の前提は、すべてのn台の予測マシンが正直であるということです。

• 「k-of-n」モデルは、契約を締結するためにn台の述語マシンが使用され、そのうちのk台の結果に基づいて契約が締結されることを示します。もしk人以上の述語が共謀すれば、契約の公正な執行に影響を与える。また、「k-of-n」モデルを使用する場合、用意するCETの数は、1台の予測マシンまたは「n-of-n」モデルのCET数のC_n^k倍となる。信頼は、n個の予測器のうち少なくともk個が正直であると仮定します。

予測マシンの数を増やしても、予測マシンの非信頼化は達成されません。なぜなら、予言マシンが悪である場合、契約の被害を受けた当事者にはオンチェーンでの救済手段がないからです。

そこで本節では、DLCにオプティミスティック・チャレンジメカニズムを導入したOP-DLCを提案する。n台の予言マシンは、DLCのセットアップに参加する前に、悪事を働かないことを約束し、事前にパーミッションレスのオンチェーンOPゲームを構築することを誓約することが求められる。もしいずれかの予言マシンが悪事を働いた場合、アリスやボブ、あるいは他の正直な予言マシンや他の第三者の正直なオブザーバーは、挑戦を開始することができる。挑戦者がゲームに勝った場合、チェーンは預金を没収することで悪の予言マシンを罰する。さらに、OP-DLCは「k-of-n」モデルを使って署名することもできる。このように、信頼の仮定は、ネットワーク内に正直な参加者がいる限り、悪の予言者ノードを罰するためにOPチャレンジを開始できるという事実に還元される。

レイヤー2計算に基づいてOP-DLCを解決するとき：

• もし予言マシンが間違った結果署名を使い、アリスの利益を損ねた場合、アリスはレイヤー2の正しい計算結果を使い、予言マシンに事前に誓約することができます。

• 同様に、ボブ、他の正直な予言マシンのノード、第三者の正直なオブザーバーはチャレンジを開始することができます。しかし、悪意のあるチャレンジを防ぐために、チャレンジする側も誓約する必要があります。

したがって、OP-DLCは予言マシンノードがお互いを監視することを可能にし、予言マシンの信頼を最小化します。このメカニズムは99%のフォールトトレランスを持つ1人の正直な参加者だけを必要とし、予言マシンの共謀のリスクをよりよく解決する。

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

DLCがクロスチェーンブリッジに使用される場合、DLC契約決済のために資金割り当てが必要です：

• CETを介して事前に設定する必要があります。これは、DLCの資金決済の粒度が限られていることを意味します。例えば、Bisonネットワークの粒度は0.1BTCです。問題：Layer2におけるユーザーのアセットインタラクションは、DLC CETの資金調達粒度に制限されるべきではありません。

• アリスがレイヤー2の資産を決済しようとすると、ユーザーのボブのレイヤー2の資産もレイヤー1に決済されることになります。問題点：各レイヤー2のユーザーは、他のユーザーの入出金に影響されることなく、自由に入出金を選択するべきです。

• アリスとボブは支出について交渉する。問題：両者に協力する意思が必要。

そこで、上記の問題を解決するために、このセクションでは、OP-DLC + BitVM デュアルブリッジを提案します。このソリューションにより、ユーザーはBitVMのパーミッションレスブリッジを通じて資金の入出金を行うことができ、またOP-DLCメカニズムを通じて資金の入出金を行うことができるため、任意の粒度の変更を実現し、資金の流動性を向上させることができる。

OP-DLCでは、ProphetはBitVMアフィリエイト、Aliceは一般ユーザー、BobはBitVMアフィリエイトです。OP-DLCを設定する際、構築されたCETにおいて、ユーザーAliceへのアウトプットはLayer1で即座に使用することができ、Bobへのアウトプットは「Aliceがチャレンジに参加できるDLCゲーム」として構築され、タイムロック期間を設定します。アリスが引き出しをしたいとき：

• BitVM allianceが予言者として正しくサインすれば、アリスはLayer1で引き出しができます。しかし、ボブはレイヤー1で引き出しができるように、ロックアウト期間が切れるのを待ちます。

• もしBitVMアライアンスが予言者として不正を行い、アリスの利益が損なわれた場合。しかし、アリスはボブのUTXOに挑戦することができます。挑戦が成功すれば、ボブの金額は没収される。注：他のBitVMアライアンスメンバーの1人もチャレンジを開始することができますが、アリスは利益を損ない、チャレンジを開始する最も動機があります。

• BitVM同盟が予言者として振る舞い、不正を働いた結果、Bobの利益が損なわれた場合。しかし、BitVM連合の正直なメンバーは「BitVMゲーム」に挑戦することができ、不正行為をした予言者ノードを罰することができます。

さらに、ユーザーであるアリスがLayer2から撤退したいが、OP-DLC契約に一致するCETがない場合、アリスは以下のオプションを選択できます：

• BitVM経由でLayer2から撤退するには、BitVMオペレータがLayer2で撤退を行います。レイヤー1でのBitVMオペレータによるアドバンス。 BitVMブリッジは、BitVMアライアンスの誠実な参加者であると仮定されます。

• OP-DLCのCETを経由して発信し、残りの小銭はレイヤー1のBitVMオペレーターが進めます。 OP-DLCの発信はDLCチャネルを閉じますが、DLCチャネルの残りの資金は、他のレイヤー2ユーザーに引き出しを強いることなく、BitVMレイヤー1プールにリダイレクトされます。OP-DLCブリッジの信頼は、チャネル内の正直な参加者を想定しています。

• アリスとボブは、予言者が参加する必要なく支出を交渉し、ボブに協力を求めます。

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

• BitVM を使用することで、DLCチャネルの資金をゼロにする問題を解決し、CETのセットアップ数を減らし、CETの資金粒度に影響されません。

• OP-DLCブリッジとBitVMブリッジを組み合わせ、ユーザーに複数の送受信チャンネルを任意の変更粒度で提供します。

• BitVMアライアンスをBobと予言者マシンとしてセットアップし、OPメカニズムを通じて予言者マシンの信頼を最小化します。

• 資金の利用を改善するために、DLCチャネルの発信マージンをBitVMブリッジプールに導入します。

4.結論

DLCはSegwit v1（Taproot）がアクティブになる前に登場し、DLCチャネルとライトニングネットワークの統合を可能にし、同じDLCチャネル内で連続するコントラクトの実行を更新するためにDLCを拡張しました。TaprootやBitVMのような技術により、DLC内でより複雑なオフチェーンコントラクト検証決済を実装することが可能になると同時に、予言マシンの信頼を最小化するOPチャレンジメカニズムを組み込むことができます。

参考資料

1. 以下の仕様Discreet Log Contracts

2. Discreetログ契約

3. スケーリングの日付。"https://medium.com/crypto-garage/scaling-dlc-part1-off-chain-discreet-log-contracts-8bb9a57c86b">スケーリングDLCパート1：オフチェーン慎重なログ契約

4. DLCを拡大する Part2: DLCの無料オプション問題

5. Scaling DLC Part3: How to avoid free option problem with DLC

6. ライトニング・ネットワーク

7. DLCon Lightning

8. DLC 秘密鍵管理 パート1<

9. DLC秘密鍵管理パート2：オラクルの秘密鍵

10. DLC 鍵管理 その3：オラクル公開鍵の配布

11. BitVM.Bitcoin で何でも計算

12. BitVM 2: Bitcoin でパーミッションレス検証

13. BitVM 2: Bitcoin でパーミッションレス検証

14. BitVM 2: Bitcoin でパーミッションレス検証<

15. BitVMオフチェーンビットコイン契約

.

16. BIP32 BIP44

17. シュナー署名

18. FROST：柔軟なラウンド最適化シュナー閾値署名

19. ECDSA閾値署名の調査

20. ECDSA閾値署名の調査

21. ブロックチェーンデジタル資産のマルチパーティ管理のための分散鍵導出

22. 分離された証人

23. 楽観的ロールアップ

24. 元記事へのリンク

    Preview