DLC原理解析及其優化思考

DLC原理解析及其最佳化思考

原文標題:《Bitlayer Core Technology: DLC and Its Optimization Considerations》

作者:lyndell 和 mutourend,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 ution Transaction, CET),用於花費注資交易。

預言機計算承諾

$R:=k·G$

然後,計算S和S’

$S:=R 哈希(OddNumber,R) ⋅ Z,$

$S’:=R 哈希(偶數,R) ⋅ Z$

廣播(R,S,S’)。

Alice和Bob各自計算對應的新公鑰

$PK^{愛麗絲}:=X+ S,$

$PK^{鮑伯}:=Y+ S’.$

結算:當第n+k個區塊出現後,預言機根據該區塊的雜湊值,產生對應的s或s’。

  • 如果第n+k個區塊的雜湊值為奇數,則預言機計算並廣播s

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

  • 如果第n+k個區塊的雜湊值為偶數,則預言機計算並廣播s’

$s’:=k 哈希(偶數,R) ⋅ z$

提幣:Alice或Bob其中一個參與者能根據預言機廣播的s或s’,提取資產。

  • 如果預言機廣播s,則Alice可以計算出新私鑰sk^{Alice} ,並提取鎖定的2個BTC

$sk^{愛麗絲}:= x + s.$

  • 如果預言機廣播s’,則Bob可以計算出新私鑰sk^{Bob},並提取鎖定的2個BTC

$sk^{鮑伯}:= y + s’.$

分析:Alice計算的新私鑰sk^{Alice} 與新公鑰PK^{Alice} 滿足離散對數關係

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

該情況下,Alice提幣會成功。

同理,Bob計算的新私鑰sk^{Bob} 與新公鑰PK^{Bob} 滿足離散對數關係

$sk^{鮑伯} ⋅ G= (y+s’) ⋅ G=Y+S’=PK^{鮑伯}$

該情況下,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:=(ks)/哈希(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(偶數_1, R) ⋅ z$

$s_2’=k-hash(偶數_2, R) ⋅ z$

情況3:

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

$s_2’=k-hash(偶數_2, R) ⋅ z$

情況4:

$s_1’=k-hash(偶數_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)}和孫密鑰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滿足如下插值關係

DLC原理解析及其最佳化思考

上式兩邊均加上增量ω ,則得到下列等式

DLC原理解析及其最佳化思考

此等式顯示:私鑰分片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挑戰機制,實現預言機信任最小化。

參考文獻

  1. 離散日誌合約規範
  2. 謹慎日誌合約
  3. 擴展 DLC 第 1 部分:鏈下離散日誌合約 4.擴展DLC第2部分:DLC的自由選項問題 5.擴展DLC第3部分:如何避免DLC的自由選項問題
  4. 閃電網絡 7.閃電DLC 8.DLC私鑰管理第1部分
  5. DLC私鑰管理第2部分:Oracle的私鑰
  6. DLC 金鑰管理第 3 部分:Oracle 公鑰分發
  7. BitVM:在比特幣上計算任何東西
  8. BitVM 2:比特幣的無許可驗證
  9. BitVM 鏈下比特幣合約
  10. BIP32 BIP44 15.施諾爾簽名
  11. FROST:靈活的輪優化 Schnorr 閾值簽名
  12. ECDSA 閾值簽名調查 18.區塊鏈數位資產多方管理的分散式金鑰派生
  13. 隔離證人
  14. 樂觀匯總 21.主根
查看原文
此頁面可能包含第三方內容,僅供參考(非陳述或保證),不應被視為 Gate 認可其觀點表述,也不得被視為財務或專業建議。詳見聲明
  • 讚賞
  • 留言
  • 轉發
  • 分享
留言
0/400
暫無留言
交易,隨時隨地
qrCode
掃碼下載 Gate App
社群列表
繁體中文
  • بالعربية
  • Português (Brasil)
  • 简体中文
  • English
  • Español
  • Français (Afrique)
  • Bahasa Indonesia
  • 日本語
  • Português (Portugal)
  • Русский
  • 繁體中文
  • Українська
  • Tiếng Việt