原題:「 Bitlayer Core Technology: DLC とその最適化に関する考慮事項」

著者: lyndell & mutourend、ビットレイヤー研究グループ

元のリンク: https://medium.com/@Bitlayer/bitlayer-core-technology-dlc-and-its-optimization-considerations-6fc5ebaae92c

Discreet Log Contract (DLC) は、2018 年に MIT の Tadge Dryja によって提案された、オラクルベースの契約実行ソリューションのセットです。 DLC を使用すると、双方が事前定義された条件に基づいて条件付き支払いを行うことができます。各当事者は、考えられる結果を決定して事前署名し、オラクルが結果に署名するときに、これらの事前署名を使用して支払いを実行します。したがって、DLC は、ビットコイン預金の安全性を確保しながら、新しい分散型金融アプリケーションを可能にします。

Lightning Network と比較して、DLC には次のような大きな利点があります。

DLC はビットコインのエコロジー アプリケーションにおいて大きな利点がありますが、次のようなリスクと問題がまだあります。

この目的を達成するために、この記事では、DLC のリスクと問題を解決し、ビットコイン エコシステムのセキュリティを向上させるためのいくつかのソリューションと最適化のアイデアを提案します。

アリスとボブは、n+k 番目のブロックのハッシュ値が奇数か偶数であるかに賭ける賭けの契約に署名します。奇数の場合、アリスはゲームに勝ち、t 時間以内に資産を引き出すことができ、偶数の場合、ボブはゲームに勝ち、t 時間以内に資産を引き出すことができます。 DLC を使用すると、n+k 番目のブロック情報がオラクルを通過して条件付き署名が構築され、正しい勝者がすべての資産を獲得できるようになります。

初期化: 楕円曲線生成器は G で、次数は q です。

鍵の生成: オラクル、アリス、ボブは独自の秘密鍵と公開鍵を個別に生成します。

資本注入トランザクション: アリスとボブは一緒に資本注入トランザクションを作成し、それぞれが 2-of-2 マルチ署名出力で 1 BTC をロックします (1 つの公開鍵 X はアリスに属し、1 つの公開鍵 Y はボブに属します)。

契約実行トランザクション: アリスとボブは、資本注入トランザクションを支出するために 2 つの契約実行トランザクション (CET) を作成します。

Oracle Computes のコミットメント

$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' を生成します。

$s:=k-hash(OddNumber,R) ⋅ z$

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

コインの引き出し: 参加者の 1 人、アリスまたはボブは、オラクルによるブロードキャストに基づいて資産を引き出すことができます。

$sk^{Alice}:= x + s.$

$sk^{Alice}:= x + s.$

$sk^{Bob}:= y + s'.$

分析: アリスが計算した新しい秘密鍵 sk^{Alice} と新しい公開鍵 PK^{Alice} は離散対数関係を満たす

$sk^{Alice} ⋅ G= (x+s) ⋅ G=X+S=PK^{Alice}$

この場合、アリスの通貨引き出しは成功します。

同様に、Bob が計算した新しい秘密鍵 sk^{Bob} と新しい公開鍵 PK^{Bob} は離散対数の関係を満たします。

$sk^{Bob} ⋅ G= (y+s') ⋅ G=Y+S'=PK^{Bob}$

この場合、ボブの撤退は成功します。

さらに、オラクルが s をブロードキャストした場合、アリスには役立ちますが、ボブには役立ちません。 Bob を使用して、対応する新しい秘密鍵 sk^{Bob} を計算することはできないためです。同様に、オラクルが s' をブロードキャストした場合、ボブにとっては役に立ちますが、アリスにとっては役に立ちません。これは、Alice を使用して対応する新しい秘密鍵 sk^{Alice} を計算することができないためです。

最後に、上記の説明ではタイムロックを省略しています。一方の当事者が新しい秘密キーを計算し、t 時間以内に通貨を引き出すことができるように、タイムロックを追加する必要があります。それ以外の場合、t 時間を超過すると、相手は元の秘密キーを使用して資産を引き出すことができます。

DLC プロトコルでは、オラクルの秘密鍵と約束された乱数が重要です。オラクルの秘密鍵と約束した乱数が漏洩・紛失すると、以下の4つのセキュリティ上の問題が発生しやすくなります。

(1) オラクルマシンが秘密鍵を失う z

オラクルが秘密鍵を紛失した場合、DLC を決済できなくなり、DLC 返金契約を締結する必要があります。したがって、オラクルが秘密キーを失うことを防ぐために、払い戻しトランザクションが DLC プロトコルに設定されています。

(2) オラクルマシンが秘密鍵を漏洩する z

オラクルの秘密鍵が漏洩した場合、その秘密鍵に基づく全てのDLCは不正決済の危険にさらされることになります。秘密キーを盗んだ攻撃者は、望むあらゆるメッセージに署名することができ、将来のすべての契約の結果を完全に制御することができます。さらに、攻撃者は単一の署名付きメッセージを公開することに限定されず、奇数ハッシュと偶数ハッシュで同時に n+k 番目のブロックに署名するなど、競合するメッセージを公開することもできます。

(3) オラクルマシンが乱数 k を漏洩または再利用する

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

$z:=(ks)/hash(OddNumber, R)$

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

オラクル マシンが乱数 k を再利用した場合、2 回の決済の後、攻撃者はオラクル マシンによる署名ブロードキャストと次の 4 つの状況のいずれかに従って連立方程式を解き、オラクル マシンの秘密鍵 z を取得できます。

ケース 1:

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

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

ケース 2:

$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) ⋅ z$

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

(4) オラクルマシンが乱数 k を失う

オラクルが乱数kを失った場合、対応するDLCを決済できなくなり、DLC返金契約を締結する必要があります。

したがって、Oracle 秘密キーのセキュリティを向上させるには、署名用の子キーまたは孫キーの導出に BIP32 を使用する必要があります。また、乱数の安全性を高めるため、乱数kとして秘密鍵とカウンタのハッシュ値k:=hash(z, counter)を使用し、乱数の重複や紛失を防ぐ必要があります。

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

Schnorr しきい値署名は、分散型オラクルを実装できます。 Schnorr しきい値署名には次の利点があります。

したがって、Schnorr しきい値署名プロトコルには、セキュリティ、信頼性、柔軟性、拡張性、説明責任を向上させる分散型オラクルにおける大きな利点があります。

鍵管理技術では、オラクルは完全な鍵 z を持ち、完全な鍵 z と増分 ω に基づいて、BIP32 を使用して、多数のサブ鍵 z+{ω }^{(1)} とグランド鍵を発行できます。 z+ω^{(1)}+ω^{(2)}。異なるイベントに対して、オラクルは異なるグランド秘密鍵 z+ω ^{(1)}+ω ^{(2)} を使用して、対応するイベント msg に対応する署名 σ を生成できます。

鍵管理技術では、オラクルは完全な鍵 z を持ち、完全な鍵 z と増分 ω に基づいて、BIP32 を使用して、多数のサブ鍵 z+{ω }^{(1)} とグランド鍵を発行できます。 z+ω^{(1)}+ω^{(2)}。異なるイベントに対して、オラクルは異なるグランド秘密鍵 z+ω ^{(1)}+ω ^{(2)} を使用して、対応するイベント msg に対応する署名 σ を生成できます。

分散型オラクル アプリケーション シナリオでは、n 人の参加者がおり、t+1 人の参加者がしきい値署名を実行する必要があります。その中には、T. n 個のオラクル ノードのそれぞれには、秘密鍵フラグメント z_i (i=1,...,n) があります。これらの n 個の秘密鍵フラグメント z_i は完全な秘密鍵 z に対応しますが、完全な秘密鍵 z は最初から最後まで出現しません。完全な秘密鍵 z が現れないという前提の下で、t+1 個のオラクルノードは秘密鍵フラグメント z_i, i=1,...,t+1 を使用してメッセージ msg' の署名フラグメント σ_i' を生成し、署名フラグメントを生成します。 σ_i' は完全な署名 σ ' にマージされます。検証者は、完全な公開鍵 Z を使用して、メッセージ署名ペア (msg',σ ') の正当性を検証できます。 t+1 個のオラクルノードが共同して閾値署名を生成する必要があるため、高いセキュリティを備えています。

ただし、分散型 Oracle アプリケーションのシナリオでは、完全な秘密キー z は表示されず、BIP32 をキー導出に直接使用することはできません。つまり、オラクル分散化技術と鍵管理技術を直接連携させることはできません。

論文「ブロックチェーンデジタル資産のマルチパーティ管理のための分散キー導出」では、しきい値署名シナリオにおける分散キー導出方法が提案されています。この論文の中心的な考え方は、ラグランジュ補間多項式によれば、秘密鍵フラグメント z_i と完全な秘密鍵 z は次の補間関係を満たすということです。

上式の両辺に増分 ω を追加すると、次の式が得られます。

この式は、秘密鍵フラグメント z_i に増分 ω を加えたものでも、完全な秘密鍵 z に増分 ω を加えたものとの補間関係を満たしていることを示しています。換言すれば、部分秘密鍵断片z_i+ωと部分鍵z+ωとは補間関係を満たす。したがって、各参加者は、秘密鍵フラグメント z_i と増分 ω を使用して、サブ署名フラグメントの生成に使用されるサブ秘密鍵フラグメント z_i+ω を導出し、対応するサブ公開鍵 Z+ω ⋅ を使用できます。 G 有効性の検証。

ただし、強化された BIP32 と強化されていない BIP32 を考慮する必要があります。拡張 BIP32 は、秘密キー、チェーン コード、およびパスを入力として受け取り、SHA512 を計算し、インクリメント コードとサブチェーン コードを出力します。非拡張 BIP32 は、公開キー、チェーン コード、およびパスを入力として受け取り、SHA512 を計算し、インクリメント コードとサブチェーン コードを出力します。閾値署名の場合は秘密鍵が存在しないため、非拡張BIP32のみ使用可能です。または、準同型ハッシュ関数を使用する、拡張された BIP32 があります。ただし、準同型ハッシュ関数は SHA512 とは異なり、元の BIP32 とは互換性がありません。

DLCでは、アリスとボブの契約は神託署名の結果に基づいて実行されるため、神託はある程度信頼される必要があります。したがって、オラクル マシンが正しく動作することは、DLC を動作させるための主要な前提条件です。

オラクルを信頼しないために、単一のオラクルへの依存を減らすために、n オラクルの結果に基づいて DLC を実行する研究が行われています。

オラクルマシンの数を増やしても、オラクルマシンに対する不信感は解消されません。なぜなら、神託が何か悪いことをしたとき、契約で被害を受けた当事者には、連鎖的に上訴する手段がないからです。

そこで本節では、DLC に楽観的チャレンジ機構を導入する OP-DLC を提案する。オラクルが DLC のセットアップに参加する前に、事前に許可のないオンチェーン OP ゲームを構築し、悪事を行わないことを誓約する必要があります。オラクルが悪を行った場合、アリスまたはボブ、またはその他の誠実なオラクルまたはその他の第三者の誠実な観察者がチャレンジを開始できます。挑戦者がゲームに勝った場合、邪悪な神託者は連鎖的に罰せられ、そのデポジットは没収されます。さらに、OP-DLC は、「k-of-n」モデルを使用して署名することもできます。このうち、k 値は 1 の場合もあります。したがって、信頼の仮定は、ネットワークに正直な参加者が存在する限り、邪悪なオラクルノードを罰するために OP チャレンジを開始できるというものになります。

Layer2の計算結果に基づいてOP-DLCを決定する場合：

したがって、OP-DLC により、Oracle ノードが相互に監視できるようになり、Oracle の信頼が最小限に抑えられます。このメカニズムには正直な参加者が 1 人だけ必要で、フォールト トレランス率が 99% であるため、オラクルによる共謀のリスクがより適切に解決されます。

DLC をクロスチェーンブリッジとして使用する場合、DLC 契約の決済時に資金の割り当てが必要です。

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

OP-DLC では、オラクルは BitVM Alliance、アリスは一般ユーザー、ボブは BitVM Alliance です。 OP-DLCを設定すると、構築されたCETでは、ユーザーAliceに与えられた出力はLayer1ですぐに使用でき、Bobに与えられた出力では、「アリスがチャレンジに参加できるDLCゲーム」が構築され、タイムロックがかかります。ロック期間が設定されています。アリスがお金を引き出したいとき:

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

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

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

DLC は Segwit v1 (Taproot) のアクティブ化前に登場し、DLC チャネルとライトニング ネットワークの統合が実装され、同じ DLC チャネル内で継続的な契約の更新と実行ができるように DLC が拡張されました。 Taproot や BitVM などのテクノロジーの助けを借りて、より複雑なオフチェーン契約の検証と決済を DLC 内で実現でき、OP チャレンジ メカニズムと組み合わせることで、オラクルの信頼を最小限に抑えることができます。

参考文献