借助 Taproot 和 BitVM 等技術，將可在 DLC 內實現更複雜的鏈下合約驗證結算，同時結合 OP 挑戰機制，實現預言機信任最小化。
原文：Bitlayer Core Technology： DLC and Its Optimization Considerations
作者：lynndell，mutourend，Bitlayer Research Group
出品：Bitlayer 研究組
1. 引言
Discreet Log Contract（DLC）是由麻省理工學院的 Tadge Dryja 在 2018 年提出的一套基於預言機的合約執行方案。 DLC 允許兩方根據預定義的條件進行有條件付款。 各方確定可能的結果並進行預簽名，並在預言機簽署結果時使用這些預簽名來執行支付。 因此，DLC 可實現新的去中心化金融應用，同時保證比特幣存款的安全。
與閃電網路相比，DLC 具有以下顯著優勢：
- 隱私性：DLC 在隱私保護方面優於閃電網路，合約細節僅在參與方之間分享，而不會在區塊鏈上存儲。 相比之下，閃電網路交易通過公開的通道和節點路由，其資訊公開且透明;
- 財務合約的複雜性和靈活性：DLC 能夠直接在比特幣網路上創建和執行複雜的金融合約，如衍生品、保險和賭約等，而閃電網路主要用於快速的小額支付，無法支援複雜應用;
- 降低對手方風險：DLC 資金被鎖定在多簽合約中，只有在預定義事件的結果出現時才會釋放，減少了任一方不遵守合約的風險。 儘管閃電網路減少了信任需求，但在通道管理和流動性提供方面仍存在一定的對手方風險;
- 無需管理支付通道：DLC 操作無需創建或維護支付通道，而這是閃電網路的核心組成部分，通道管理既複雜又耗資源;
- 特定用例的可擴充性：閃電網路在一定程度上提高了比特幣的交易輸送量，而 DLC 在比特幣上的複雜合約方面提供了較好的可擴充性。
雖然 DLC 在比特幣生態應用中極具優勢，但是仍存在一些風險和問題，如：
- 密鑰風險：預言機的私鑰和承諾的隨機數具有洩露或丟失風險，導致使用者資產損失;
- 中心化信任風險：預言機中心化問題，容易導致拒絕服務攻擊;
- 去中心化無法金鑰派生：如果預言機去中心化，則預言機節點僅擁有私鑰分片。 但是，去中心化的預言機節點無法基於私鑰分片直接使用 BIP32 進行密鑰派生;
- 串謀風險：如果預言機節點之間串謀、或與參與方串謀，則仍沒解決預言機的信任問題。 需要一個可靠的監督機制，使得預言機信任最小化;
- 固定面額找零問題：條件簽名需要在構建合約之前有確定性的可枚舉事件集合來構建交易。 因此，DLC 用於資產重新分配會有最小金額的限制，導致存在固定面額的找零問題。
為此，本文提出一些方案和優化思路，解決 DLC 的風險和問題，提高比特幣生態系統的安全性。
2.DLC 原理
Alice 和 Bob 簽署一個對賭協定：投注第 n+k 個區塊的哈希值是奇數或偶數。 如果是奇數，則 Alice 贏得遊戲，可在 t 時間內提取資產; 如果是偶數，則 Bob 贏得遊戲，可在 t 時間內提取資產。 使用 DLC，通過預言機傳遞第 n+k 的區塊資訊來構造條件簽名使得正確的獲勝方贏得所有資產。
初始化：橢圓曲線生成元為 G，階為 q。
金鑰生成：預言機、Alice 和 Bob 獨立生成各自的私鑰和公鑰。
- 預言機的私鑰為 z，公鑰為 Z，滿足關係 Z=z⋅G;
- Alice 的私鑰為 x，公鑰為 X，滿足關係 X=x⋅G;
- Bob 的私鑰為 y，公鑰為 Y，滿足關係 Y=y⋅G。
注資交易： Alice 和 Bob 一起創建一筆注資交易，各自將 1BTC 鎖在一個 2-of-2 的多簽輸出（一個公鑰 X 屬於 Alice，一個公鑰 Y 屬於 Bob）。
合約執行交易：Alice 和 Bob 創建兩筆合約執行交易（Contract Execution Transaction， CET），用於花費注資交易。
預言機計算承諾
$R:=k ⋅ G$
然後，計算 S 和 S'
$S:=R-hash(OddNumber,R) ⋅ Z,$
$S’:=R-hash(EvenNumber,R) ⋅ Z$
廣播（R，S，S'）。
Alice 和 Bob 各自計算對應的新公鑰
$PK^{Alice}:=X+ S,$
$PK^{Bob}:=Y+ S’.$
結算：當第 n+k 個區塊出現后，預言機根據該區塊的哈希值，生成對應的 s 或 s'。
- 如果第 n+k 個區塊的哈希值為奇數，則預言機計算並廣播 s
$s:=k-hash(OddNumber,R) ⋅ z$
- 如果第 n+k 個區塊的哈希值為偶數，則預言機計算並廣播 s'
$s’:=k-hash(EvenNumber,R) ⋅ z$
提幣：Alice 或 Bob 其中一個參與方能根據預言機廣播的 s 或 s'，提取資產。
- 如果預言機廣播 s，則 Alice 可以計算出新私鑰 sk^{Alice} ，並提取鎖定的 2 個 BTC
$sk^{Alice}:= x + s.$
- 如果預言機廣播 s'，則 Bob 可以計算出新私鑰 sk^{Bob}，並提取鎖定的 2 個 BTC
$sk^{Bob}:= y + s’.$
分析：Alice 計算的新私鑰 sk^{Alice} 與新公鑰 PK^{Alice} 滿足離散對數關係
$sk^{Alice} ⋅ G= (x+s) ⋅ G=X+S=PK^{Alice}$
該情況下，Alice 提幣會成功。
同理，Bob 計算的新私鑰 sk^{Bob} 與新公鑰 PK^{Bob} 滿足離散對數關係
$sk^{Bob} ⋅ G= (y+s’) ⋅ G=Y+S’=PK^{Bob}$
該情況下，Bob 提幣會成功。
此外，如果預言機廣播 s，對 Alice 有用，但是對 Bob 沒用。 因為，Bob 無法用於計算出對應的新私鑰 sk^{Bob}。 同理，如果預言機廣播 s'，對 Bob 有用，但是對 Alice 沒用。 因為，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
$z:=(k-s)/hash(OddNumber, R)$
$z:=(k-s’)/hash(EvenNumber, R)$
如果預言機重用隨機數 k，則經過 2 次結算，攻擊者可以根據預言機廣播的簽名，根據以下四種情況之一解方程組，求出預言機的私鑰 z，
情況 1：
$s_1=k-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) ⋅ z$
$s_2=k-hash(OddNumber_2, R) ⋅ z$
（4）預言機丟失隨機數 k
如果預言機丟失隨機數 k，則對應的 DLC 無法結算，需要執行 DLC 退款合約。
因此，為提高預言機私鑰的安全性，應使用 BIP32 派生出子秘鑰或孫金鑰，用於簽名。 此外，為提高隨機數的安全性，應使用私鑰和計數器的哈希值 k：=hash（z， counter），作為隨機數 k，以防隨機數重複或丟失。
3.2 去中心化預言機
DLC 中，預言機的作用至關重要，提供了決定合約結果的關鍵外部數據。 為提高這些合約的安全性，則需要去中心化預言機。 與中心化預言機不同，去中心化預言機將提供準確和防篡改數據的責任分散到多個獨立節點上，可以減少依賴單一故障點的風險，並降低操縱或針對性攻擊的可能性。 通過去中心化預言機，DLC 可以實現更高程度的無需信任和可靠性，確保合約執行完全依賴於預定條件的客觀性。
Schnorr 門限簽名可以實現去中心化預言機。 Schnorr 門限簽名具有以下優勢：
- 增強安全性：通過分散密鑰的管理，門限簽名減少了單點故障的風險。 即使部分參與方的密閜被洩露或受到攻擊，只要不超過設定的閾值，整個系統仍然安全。
- 分散式控制：門限簽名實現了對密鑰管理的分散式控制，無單一實體掌握全部簽名權力，從而降低了權力過於集中帶來的風險。
- 提高可用性：只需達到一定數量的預言機節點同意即可完成簽名，提高了系統的靈活性和可用性。 即使部分節點不可用，也不會影響整體系統的可靠運行。
- 靈活性與可擴充性：門限簽名協定可以根據需要設置不同的閾值，適應各種不同的安全需求和場景。 此外，它也適用於大規模網路，具有良好的可擴充性。
- 可追責性：每個預言機節點基於私鑰分片對消息生成簽名分片，其他參與方均可使用對應的公鑰分片驗證該簽名分片的正確性，實現追責。 如果正確，則累加簽名分片，生成完整簽名。
因此，Schnorr 門限簽名協定在提高安全性、可靠性、靈活性、可擴展性和可追責性等的去中心化預言機中具有顯著優勢。
3.3 去中心化與密鑰管理耦合
在密鑰管理技術中，預言機擁有一個完整密鑰 z，基於完整密鑰 z 和增量ω ，使用 BIP32，能夠派出大量的子密鑰 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 個預言機節點聯合生成門限簽名，所以具有較高的安全性。
但是，在去中心化預言機應用場景下，完整私鑰 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 以私鑰、鏈碼和路徑為輸入，計算 SHA512，輸出增量和子鏈碼。 而非增強型 BIP32 以公鑰、鏈碼和路徑為輸入，計算 SHA512，輸出增量和子鏈碼。 門限簽名情況下，私鑰不存在，所以只能使用非增強型 BIP32。 或使用同態哈希函數，則有增強型 BIP32。 但是，同態哈希函數與 SHA512 不同，與原 BIP32 不相容。
3.4 OP-DLC：預言機信任最小化
DLC 中，Alice 和 Bob 之間的合約是根據預言機簽名的結果來執行的，因此需在一定程度上信任預言機。 所以，預言機的行為正確，是 DLC 運行的一大前提。
為預言機去信任化，已有研究根據 n 個預言機的結果執行 DLC，減少對單個預言機的依賴。
- “n-of-n” 模型表示使用 n 個預言機簽訂合約，並根據 n 個預言機的結果執行合約。 該模型要求 n 個預言機均在線簽名。 如果有預言機離線或對結果有分歧，則影響 DLC 合約執行。 信任假設為 n 個預言機均為誠實的。
- “k-of-n” 模型表示使用 n 個預言機簽訂合約，根據其中 k 個預言機的結果執行合約。 如果有超過 k 個預言機串謀，則影響合約的公正執行。 此外，使用 “k-of-n” 模型時，需要準備的 CET 數量，是單個預言機或 “n-of-n” 模型的 C_n^k 倍。 信任假設為 n 個預言機中至少有 k 個預言機是誠實的。
增加預言機數量，並沒有實現對預言機的去信任化。 因為當預言機作惡后，合約受損方沒有鏈上申訴通道。
因此，本節提出 OP-DLC，在 DLC 中引入樂觀挑戰機制。 n 個預言機在參與設置 DLC 之前，需提前質押構建 permisssionless 鏈上 OP 遊戲，承諾不作惡。 如果有任何一個預言機作惡，則 Alice 或 Bob 或任何其它誠實預言機或其它第三方誠實觀察者，均可發起挑戰。 如果挑戰方贏得遊戲，則鏈上懲罰作惡預言機，罰沒其押金。 此外，OP-DLC 也可採用 “k-of-n” 模型來簽名。 其中，k 值甚至可為 1。 因此，信任假設降為只要網路中有一個誠實的參與方就可發起 OP 挑戰，懲罰作惡的預言機節點。
當根據 Layer2 計算結果，對 OP-DLC 結算時：
- 如果預言機使用錯誤的結果簽名，使得 Alice 利益受損，則 Alice 可使用 Layer2 正確計算結果，對預言機提前質押的 permisssionless 鏈上 OP 遊戲發起挑戰。 Alice 贏得遊戲，懲罰作惡預言機，彌補損失;
- 同理，Bob、其它誠實預言機節點、第三方誠實觀察者均可發起挑戰。 但是，為防止惡意挑戰，挑戰方也需要質押。
因此，OP-DLC 使得預言機節點之間互相監督，使得預言機信任最小化。 該機制僅需要一個誠實參與方，容錯率 99%，較好地解決了預言機串謀風險。
3.5 OP-DLC + BitVM 雙橋
當 DLC 用於跨鏈橋，DLC 合約結算時需要進行資金分配：
- 需要通過 CET 預先設置。 這意味著 DLC 的資金結算粒度是有限的，如 Bison 網路以 0.1 BTC 為粒度。 存在問題：使用者在 Layer2 的資產交互不應受限於 DLC CET 的資金粒度。
- 當 Alice 想要對其 Layer2 資產結算時，會強制將使用者 Bob 的 Layer2 資產也結算到 Layer1。 存在問題：每個 Layer2 用戶應可自由選擇出入金，而不受其它使用者出入金影響。
- Alice 和 Bob 協商花費。 存在問題：要求二者願意配合。
因此，為解決上述問題，本節提出 OP-DLC + BitVM 雙橋。 該方案使得使用者即可通過 BitVM 的 permissionless bridge 進行入金和出金，也可以通過 OP-DLC 機制入金和出金，實現任意粒度找零，且提高資金流動性。
在 OP-DLC 中，預言機為 BitVM 聯盟，Alice 為普通使用者，Bob 為 BitVM 聯盟。 在設置 OP-DLC 時，所構建的 CET 中，給使用者 Alice 的 output 可在 Layer1 上立即花費，給 Bob 的 output 中構建一個 “Alice 能參與挑戰的 DLC 遊戲” 並設置 timelock 鎖定期。 當 Alice 想要出金時：
- 如果 BitVM 聯盟作為預言機，正確簽名，則 Alice 可在 Layer1 取款。 但是，Bob 等待鎖定期過後可在 Layer1 提款。
- 如果 BitVM 聯盟作為預言機，作弊，導致 Alice 利益受損。 但是，Alice 可對 Bob 的 UTXO 發起挑戰。 如果挑戰成功，則可罰沒 Bob 的金額。 注意：其它 BitVM 聯盟成員之一也可發起挑戰，但 Alice 利益受損，最有動機發起挑戰。
- 如果 BitVM 聯盟作為預言機，作弊，導致 Bob 利益受損。 但是，BitVM 聯盟中的一個誠實成員可對 “BitVM 遊戲” 發起挑戰，懲罰作弊的預言機節點。
此外，當使用者 Alice 想要從 Layer2 出金，但是 OP-DLC 合約內預設的 CET 沒有匹配的金額，則 Alice 可選擇以下方式：
- 通過 BitVM 出金，由 BitVM operator 在 Layer1 墊付。 BitVM bridge 假設為 BitVM 聯盟中有一個誠實參與方。
- 通過 OP-DLC 中的某個 CET 出金，同時剩餘的找零由 BitVM operator 在 Layer1 墊付。 OP-DLC 出金會關閉 DLC 通道，但 DLC 通道中剩餘的資金會轉向 BitVM Layer1 資金池，而不會強迫其他 Layer2 用戶出金。 OP-DLC bridge 信任假設為通道內有一個誠實參與方。
- Alice 和 Bob 協商花費，無需預言機參與，要求 Bob 配合。
因此，OP-DLC + BitVM 雙橋具有以下優勢：
- 使用 BitVM 解決了 DLC 通道資金找零問題，降低 CET 的設置數量，且不受 CET 資金粒度影響;
- 將 OP-DLC bridge 和 BitVM bridge 結合，為使用者提供多種出金入金通道，任意粒度找零;
- 將 BitVM 聯盟設置為 Bob 和預言機，通過 OP 機制，使得預言機信任最小化;
- 將 DLC 通道的出金餘量引入到 BitVM bridge 資金池，提升資金利用率。
4. 結論
DLC 出現在 Segwit v1（Taproot）啟動之前，且已實現 DLC 通道與閃電網路的集成，並將 DLC 擴展為可在同一 DLC 通道內更新執行連續合約。 借助 Taproot 和 BitVM 等技術，將可在 DLC 內實現更複雜的鏈下合約驗證結算，同時結合 OP 挑戰機制，實現預言機信任最小化。
參考文獻
- Specification for Discreet Log Contracts
- Discreet Log Contracts
- Scaling DLC Part1: Off-chain Discreet Log Contracts
- Scaling DLC Part2: Free option problem with DLC
- Scaling DLC Part3: How to avoid free option problem with DLC
- Lightning Network
- DLC on Lightning
- DLC Private Key Management Part 1
- DLC Private Key Management Part 2: The Oracle’s private keys
- DLC Key Management Pt 3: Oracle Public Key Distribution
- BitVM: Compute Anything on Bitcoin
- BitVM 2: Permissionless Verification on Bitcoin
- BitVM Off-chain Bitcoin Contracts
- BIP32 BIP44
- Schnorr signature
- FROST: Flexible Round-Optimized Schnorr Threshold Signatures
- A Survey of ECDSA Threshold Signing
- Distributed Key Derivation for Multi-Party Management of Blockchain Digital Assets
- Segregated Witness
- Optimistic Rollup
- Taproot
免責聲明：作為區塊鏈資訊平臺，本站所發佈文章僅代表作者及嘉賓個人觀點，與 Web3Caff 立場無關。 文章內的資訊僅供參考，均不構成任何投資建議及要約，並請您遵守所在國家或地區的相關法律法規。
