原題：「Bitlayer Core Technology: DLC and Its Optimization Considerations》
オリジナル著者: lyndell mutourend、Bitlayer Research Group
1 はじめに
Discreet Log Contract (DLC) は、2018 年に MIT の Tadge Dryja によって提案された、オラクルベースの契約実行ソリューションのセットです。 DLC を使用すると、双方が事前定義された条件に基づいて条件付き支払いを行うことができます。各当事者は、考えられる結果を決定して事前署名し、オラクルが結果に署名するときに、これらの事前署名を使用して支払いを実行します。その結果、DLC はビットコイン預金を安全に保ちながら、新しい分散型金融アプリケーションを可能にします。
Lightning Network と比較して、DLC には次のような大きな利点があります。
プライバシー：DLC は、契約の詳細が参加者間でのみ共有され、ブロックチェーンに保存されないため、プライバシー保護の点でライトニング ネットワークよりも優れています。対照的に、ライトニング ネットワーク トランザクションはパブリック チャネルとノードを通じてルーティングされ、その情報は公開され、透過的になります。
金融契約の複雑さと柔軟性:DLC は、デリバティブ、保険、ギャンブル契約などの複雑な金融契約をビットコイン ネットワーク上で直接作成および実行できますが、ライトニング ネットワークは主に迅速な少額支払いに使用され、複雑なアプリケーションをサポートできません。
取引相手のリスクを軽減します:DLC 資金は複数署名契約でロックされており、事前定義されたイベントの結果が発生した場合にのみ解放されるため、どちらかの当事者が契約を遵守しないリスクが軽減されます。ライトニングネットワークにより信頼の必要性は軽減されますが、チャネル管理と流動性の提供に関しては依然としてカウンターパーティリスクがいくらかあります。
支払いチャネルを管理する必要はありません。DLC の運用では、ライトニング ネットワークのコア コンポーネントである支払いチャネルの作成やメンテナンスは必要ありません。チャネル管理は複雑でリソースを大量に消費します。
特定のユースケース向けのスケーラビリティ:ライトニング ネットワークはビットコインのトランザクション スループットをある程度向上させますが、DLC はビットコインの複雑なコントラクトの拡張性を向上させます。
DLC はビットコインのエコロジー アプリケーションにおいて大きな利点がありますが、次のようなリスクと問題がまだあります。
主なリスク:オラクルマシンの秘密鍵と約束された乱数が漏洩または紛失する危険性があり、その結果、ユーザーの資産が失われる可能性があります。
一元化された信頼リスク:オラクルの集中化の問題は、簡単にサービス妨害攻撃につながる可能性があります。
分散型キーの導出は不可能です。オラクルが分散型の場合、オラクルノードは秘密鍵シャードのみを所有します。ただし、分散型 Oracle ノードは、秘密キーのシャーディングに基づくキー導出に BIP 32 を直接使用できません。
共謀のリスク:オラクルノードが相互に、または参加者と共謀した場合でも、オラクルマシンの信頼性の問題は依然として解決されません。オラクルへの信頼を最小限に抑えるには、信頼できる監視メカニズムが必要です。
額面変更の問題を修正しました:条件付き署名では、トランザクションを構築するためのコントラクトを構築する前に、確定的な一連の列挙可能なイベントが必要です。したがって、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 を満たします。
資本注入取引:アリスとボブは一緒に資金調達トランザクションを作成し、それぞれが 2-of-2 マルチ署名出力で 1 BTC をロックします (1 つの公開キー X はアリスに属し、1 つの公開キー Y はボブに属します)。
契約実行トランザクション:アリスとボブは、資本注入トランザクションを支出するための 2 つの契約実行トランザクション (CET) を作成します。
Oracle Computes のコミットメント
次に、S と S を計算します。
ブロードキャスト(R、S、S)。
アリスとボブはそれぞれ、対応する新しい公開鍵を計算します。
決済：n+k 番目のブロックが出現すると、オラクルはブロックのハッシュ値に基づいて対応する s または s を生成します。
n+k ブロックのハッシュが奇数の場合、オラクルは を計算してブロードキャストします。
n+k ブロックのハッシュ値が偶数の場合、オラクルは s を計算してブロードキャストします。
コインを引き出す:参加者の 1 人、アリスまたはボブは、オラクルによるブロードキャストに基づいて資産を引き出すことができます。
オラクルが s をブロードキャストすると、アリスは新しい秘密鍵 sk^{Alice} を計算し、ロックされた 2 BTC を引き出すことができます。
オラクルが s をブロードキャストすると、ボブは新しい秘密鍵 sk^{Bob} を計算し、ロックされた 2 BTC を引き出すことができます。
分析: アリスが計算した新しい秘密鍵 sk^{Alice} と新しい公開鍵 PK^{Alice} は離散対数関係を満たす
この場合、アリスの通貨引き出しは成功します。
同様に、Bob が計算した新しい秘密鍵 sk^{Bob} と新しい公開鍵 PK^{Bob} は離散対数関係を満たします。
この場合、ボブの撤退は成功します。
さらに、オラクルが s をブロードキャストした場合、アリスには役立ちますが、ボブには役立ちません。 Bob を使用して、対応する新しい秘密鍵 sk^{Bob} を計算することはできないためです。同様に、オラクルが s をブロードキャストした場合、ボブにとっては役に立ちますが、アリスにとっては役に立ちません。これは、Alice を使用して対応する新しい秘密鍵 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 を計算できます。
オラクル マシンが乱数 k を再利用した場合、2 回の決済の後、攻撃者はオラクル マシンによってブロードキャストされた署名に従って連立方程式を解き、次の 4 つの状況のいずれかに従ってオラクル マシンの秘密鍵 z を計算できます。 :
ケース 1:
ケース 2:
ケース 3:
ケース 4:
(4) オラクルマシンが乱数 k を失う
オラクルが乱数kを失った場合、対応するDLCを決済できなくなり、DLC返金契約を締結する必要があります。
したがって、Oracle 秘密キーのセキュリティを向上させるには、BIP 32 を使用して署名用の子キーまたは孫キーを取得する必要があります。また、乱数の安全性を高めるため、乱数kとして秘密鍵とカウンタのハッシュ値k:=hash(z, counter)を使用し、乱数の重複や紛失を防ぐ必要があります。
3.2 分散型オラクル
DLC では、オラクルが重要な役割を果たし、契約の結果を決定する重要な外部データを提供します。これらのコントラクトのセキュリティを向上させるには、分散型オラクルが必要です。集中型オラクルとは異なり、分散型オラクルは、正確で改ざん防止されたデータを提供する責任を複数の独立したノードに分散させるため、単一障害点に依存するリスクを軽減し、操作や標的型攻撃の可能性を減らすことができます。分散型オラクルを通じて、DLC はより高度なトラストレス性と信頼性を実現し、契約の実行があらかじめ定められた条件の客観性に完全に依存することを保証します。
Schnorr しきい値署名により、分散型オラクルが可能になります。 Schnorr しきい値署名には次の利点があります。
強化されたセキュリティ:分散キー管理により、しきい値署名により単一障害点のリスクが軽減されます。一部の参加者の鍵が漏洩したり攻撃を受けたりしても、設定した閾値を超えない限りシステム全体は安全です。
分散制御:閾値署名は鍵管理の分散制御を実現し、単一の主体がすべての署名権限を持たないため、過度の権限集中によるリスクを軽減します。
使いやすさの向上:署名は特定の数の Oracle ノードによってのみ同意される必要があるため、システムの柔軟性と可用性が向上します。一部のノードが利用できなくなっても、システム全体の信頼性の高い動作には影響しません。
柔軟性と拡張性:しきい値署名プロトコルは、さまざまなセキュリティ要件やシナリオに適応するために、必要に応じてさまざまなしきい値を設定できます。また、大規模ネットワークにも適しており、拡張性にも優れています。
説明責任:各オラクルノードは秘密鍵フラグメントに基づいてメッセージの署名フラグメントを生成し、他の参加者は対応する公開鍵フラグメントを使用して署名フラグメントの正確性を検証し、説明責任を達成できます。正しい場合、署名のフラグメントが蓄積されて完全な署名が生成されます。
したがって、Schnorr しきい値署名プロトコルには、セキュリティ、信頼性、柔軟性、拡張性、説明責任を向上させる分散型オラクルにおける大きな利点があります。
3.3 分散化と鍵管理の組み合わせ
鍵管理技術では、オラクルマシンは完全な鍵 z を持ち、完全な鍵 z と増分 ω に基づいて、BIP 32 を使用して多数のサブ鍵 z+{ω }^{(1) を送信できます。 } と Sun 秘密鍵 z+ω ^{( 1)}+ω ^{( 2)}。異なるイベントに対して、オラクルは異なるグランド秘密鍵 z+ω ^{(1)}+ω ^{(2)} を使用して、対応するイベント msg に対応する署名 σ を生成できます。
分散型オラクル アプリケーション シナリオでは、n 人の参加者がおり、t+1 人の参加者がしきい値署名を実行する必要があります。その中には、T. n 個の Oracle ノードには、それぞれ秘密鍵シャード z_i、i= 1、...、n があります。これらの n 個の秘密鍵フラグメント z_i は完全な秘密鍵 z に対応しますが、完全な秘密鍵 z は最初から最後まで出現しません。完全な秘密鍵 z が出現しないという前提の下で、t+ 1 個のオラクル ノードは秘密鍵フラグメント z_i、i= 1、...、t+ 1 を使用して署名フラグメント σ_i を生成し、メッセージ msg の署名フラグメント σ_i をマージします。完全な署名 σ。検証者は完全な公開鍵 Z を使用して、メッセージ署名ペア (msg,σ ) の正当性を検証します。 t+1 個のオラクルノードが共同して閾値署名を生成する必要があるため、高いセキュリティを備えています。
ただし、分散型 Oracle アプリケーションのシナリオでは、完全な秘密キー z は表示されず、BIP 32 をキーの導出に直接使用することはできません。つまり、オラクル分散化技術と鍵管理技術を直接連携させることはできません。
紙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 を使用して妥当性検証を実行できます。 。
ただし、強化された BIP と強化されていない BIP を考慮する必要があります 32。拡張 BIP 32 は、秘密キー、チェーンコード、パスを入力として受け取り、SHA 512 を計算し、デルタとサブチェーンコードを出力します。非拡張 BIP 32 は、公開キー、チェーン コード、パスを入力として受け取り、SHA 512 を計算し、デルタ コードとサブチェーン コードを出力します。しきい値署名の場合、秘密キーが存在しないため、非拡張 BIP 32 のみを使用できます。または、準同型ハッシュ関数を使用すると、拡張された BIP 32 があります。ただし、準同型ハッシュ関数は SHA 512 とは異なり、元の BIP 32 とは互換性がありません。
3.4 OP-DLC: Oracle Trustの最小化
DLCでは、アリスとボブの契約は神託署名の結果に基づいて実行されるため、神託はある程度信頼される必要があります。したがって、オラクル マシンが正しく動作することは、DLC を動作させるための主要な前提条件です。
オラクルに対する不信感を高めるために、n オラクルの結果に基づいて DLC を実行し、単一のオラクルへの依存を減らす研究が行われています。
"n-of-n"このモデルは、n オラクルを使用して契約に署名し、n オラクルの結果に基づいて契約を実行することを表します。このモデルでは、すべてのオンライン署名に n Oracle が必要です。オラクルがオフラインになったり、結果について意見が一致しない場合、DLC 契約の履行に影響します。信頼性の前提は、すべての n オラクルが正直であるということです。
"k-of-n"このモデルは、契約の署名に n オラクルが使用され、k オラクルの結果に基づいて契約が実行されることを示しています。 k を超えるオラクルが共謀すると、契約の公正な履行に影響を及ぼします。さらに、使用"k-of-n"モデルの場合、準備する必要がある CET の数は 1 オラクルまたは"n-of-n"モデルの C_n^k 倍。信頼の前提は、n オラクルのうち少なくとも k オラクルが誠実であるということです。
オラクルマシンの数を増やしても、オラクルマシンに対する不信感は解消されません。なぜなら、神託が何か悪いことをしたとき、契約で被害を受けた当事者には、連鎖的に上訴する手段がないからです。
そこで本節では、DLC に楽観的チャレンジ機構を導入する OP-DLC を提案する。DLC のセットアップに参加する前に、n オラクルは、許可のないチェーン上に OP ゲームを構築し、悪を行わないことを事前に誓約する必要があります。オラクルが悪を働いた場合、アリスまたはボブ、またはその他の誠実なオラクルまたはその他の第三者の誠実な観察者がチャレンジを開始できます。挑戦者がゲームに勝った場合、邪悪な神託者は連鎖的に罰せられ、そのデポジットは没収されます。さらにOP-DLCも使用可能"k-of-n"署名するモデル。ここで、k は 1 の場合もあります。したがって、信頼の仮定は、ネットワークに正直な参加者が存在する限り、邪悪なオラクルノードを罰するために OP チャレンジを開始できるというものになります。
レイヤ 2 の計算結果に基づいて OP-DLC を決定する場合:
オラクルが誤った結果署名を使用し、アリスの利益が損なわれた場合、アリスはレイヤー 2 を使用して結果を正しく計算し、オラクルが事前に誓約した許可のないチェーンで OP ゲームに挑戦できます。アリスはゲームに勝ち、邪悪な神託を罰し、損失を埋め合わせます。
同様に、ボブ、他の誠実なオラクルノード、およびサードパーティの誠実なオブザーバーはすべてチャレンジを開始できます。ただし、悪意のあるチャレンジを防ぐために、挑戦者もステークする必要があります。
したがって、OP-DLC により、Oracle ノードが相互に監視できるようになり、Oracle の信頼が最小限に抑えられます。このメカニズムには正直な参加者が 1 人だけ必要で、フォールト トレランス率が 99% であるため、オラクルによる共謀のリスクがより適切に解決されます。
3.5 OP-DLC + BitVM デュアルブリッジ
DLC をクロスチェーンブリッジとして使用する場合、DLC 契約の決済時に資金の割り当てが必要です。
CET による事前セットアップが必要です。これは、Bison ネットワークの 0.1 BTC 粒度など、DLC の資金決済粒度が制限されていることを意味します。問題があります。レイヤー 2 でのユーザーの資産インタラクションは、DLC CET の資金粒度に限定されるべきではありません。
アリスがレイヤー 2 資産を決済したい場合、ユーザー ボブのレイヤー 2 資産も強制的にレイヤー 1 に決済されます。問題があります。各レイヤー 2 ユーザーは、他のユーザーの入出金の影響を受けることなく、資金の入出金を自由に選択できる必要があります。
アリスとボブは費用について交渉します。問題は、双方が進んで協力する必要があるということです。
したがって、上記の問題を解決するために、このセクションでは OP-DLC + BitVM デュアル ブリッジを提案します。このソリューションにより、ユーザーは BitVM のパーミッションレス ブリッジを通じて資金の入出金を行うことができるほか、OP-DLC メカニズムを通じて資金の入出金も行うことができるため、あらゆる粒度で変化を実現し、資本の流動性を向上させることができます。
OP-DLC では、オラクルは BitVM Alliance、アリスは一般ユーザー、ボブは BitVM Alliance です。 OP-DLC を設定する場合、構築された CET では、ユーザー アリスへの出力は直ちにレイヤー 1 に費やすことができ、ボブへの出力では、「アリスがチャレンジに参加できる DLC ゲーム」が構築され、タイムロックがロックされます。期間が設定されています。アリスがお金を引き出したいとき:
BitVM Alliance がオラクルとして機能し、正しく署名された場合、Alice はレイヤー 1 で資金を引き出すことができます。ただし、ボブは、レイヤー 1 でお金を引き出す前に、ロックイン期間が終了するまで待ちます。
BitVM Alliance が神託の役割を果たして不正行為を行った場合、Alice の利益は損なわれてしまいます。ただし、アリスはボブの UTXO に挑戦できます。チャレンジが成功すると、ボブの金額は没収される可能性があります。注: 他の BitVM Alliance メンバーの 1 人もチャレンジを開始できますが、アリスは自分の利益が損なわれるため、チャレンジを開始することに最も意欲的です。
BitVM Alliance が神託の役割を果たして不正行為を行った場合、Bob の利益は損なわれてしまいます。ただし、BitVM Alliance の誠実なメンバーは、「BitVM ゲーム」に挑戦し、不正なオラクル ノードを罰することができます。
さらに、ユーザーのアリスがレイヤー 2 から資金を引き出したいが、OP-DLC 契約で事前に設定された CET が金額と一致しない場合、アリスは次の方法を選択できます。
BitVM を介した出金は、レイヤー 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 アライアンスをボブとオラクルに設定し、OP メカニズムを通じてオラクルの信頼を最小限に抑えます。
DLC チャネルの出金残高を BitVM ブリッジ資金プールに導入し、資金利用率を向上させます。
4 結論
DLC は Segwit v1 (Taproot) のアクティブ化前に登場し、DLC チャネルとライトニング ネットワークの統合が実装され、同じ DLC チャネル内で継続的な契約を更新および実行できるように DLC が拡張されました。 Taproot や BitVM などのテクノロジーの助けを借りて、より複雑なオフチェーン契約の検証と決済を DLC 内で実現でき、OP チャレンジ メカニズムと組み合わせることで、オラクルの信頼を最小限に抑えることができます。
参考文献
IOS
Android