Bitlayer Research:DLC 原理解析及其優化思考

行業速遞
2024-04-02 12:18:41
收藏
Discreet Log Contract (DLC) 是由麻省理工學院的 Tadge Dryja 在 2018 年提出的一套基於預言機的合約執行方案。DLC 允許兩方根據預定義的條件進行有條件付款。各方確定可能的結果並進行預簽名,並在預言機簽署結果時使用這些預簽名來執行支付。因此,DLC 可實現新的去中心化金融應用,同時保證比特幣存款的安全。

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

作者: lynndell \& mutourend, Bitlayer Research Group

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 =zG
  • Alice的私鑰為x,公鑰為X,滿足關係X =xG
  • Bob的私鑰為y,公鑰為Y,滿足關係Y =yG

注資交易: 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:

$s1=k-hash(OddNumber1, R) ⋅ z$

$s2=k-hash(OddNumber2, R) ⋅ z$

情況2:

$s1'=k-hash(EvenNumber1, R) ⋅ z$

$s2'=k-hash(EvenNumber2, R) ⋅ z$

情況3:

$s1=k-hash(OddNumber1, R) ⋅ z$

$s2'=k-hash(EvenNumber2, R) ⋅ z$

情況4:

$s1'=k-hash(EvenNumber1, R) ⋅ z$

$s2=k-hash(OddNumber2, 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個預言機節點各自擁有一個私鑰分片zi, i=1,…,n。這n個私鑰分片zi對應一個完整私鑰z,但是完整私鑰z從始至終不出現。在完整私鑰z不出現的前提下,t+1個預言機節點使用私鑰分片zi, 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滿足如下插值關係

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

該等式表明:私鑰分片zi加上增量ω ,與完整私鑰z加上增量ω 仍滿足插值關係。換言之,子私鑰分片zi+ω與子密鑰z+ω滿足插值關係。因此,各個參與方能夠使用私鑰分片zi加上增量ω 派生出子私鑰分片zi+ω,用於生成子簽名分片,且使用對應的子公鑰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. Specification for Discreet Log Contracts
  2. Discreet Log Contracts
  3. Scaling DLC Part1: Off-chain Discreet Log Contracts
  4. Scaling DLC Part2: Free option problem with DLC
  5. Scaling DLC Part3: How to avoid free option problem with DLC
  6. Lightning Network
  7. DLC on Lightning
  8. DLC Private Key Management Part 1
  9. DLC Private Key Management Part 2: The Oracle's private keys
  10. DLC Key Management Pt 3: Oracle Public Key Distribution
  11. BitVM: Compute Anything on Bitcoin
  12. BitVM 2: Permissionless Verification on Bitcoin
  13. BitVM Off-chain Bitcoin Contracts
  14. BIP32BIP44
  15. Schnorr signature
  16. FROST: Flexible Round-Optimized Schnorr Threshold Signatures
  17. A Survey of ECDSA Threshold Signing
  18. Distributed Key Derivation for Multi-Party Management of Blockchain Digital Assets
  19. Segregated Witness
  20. Optimistic Rollup
  21. Taproot
關聯標籤
鏈捕手ChainCatcher提醒,請廣大讀者理性看待區塊鏈,切實提高風險意識,警惕各類虛擬代幣發行與炒作,站內所有內容僅係市場信息或相關方觀點,不構成任何形式投資建議。如發現站內內容含敏感信息,可點擊“舉報”,我們會及時處理。
ChainCatcher 與創新者共建Web3世界