Bitlayer核心技術：DLC及其優化考慮

進階

4/14/2024, 7:53:52 AM

Discreet Log Contract (DLC) 這一套基於預言機的合約執行方案，實現 DLC 通道與閃電網路的集成，並將 DLC 擴展爲可在同一 DLC 通道內更新執行連續合約。借助 Taproot 和 BitVM 等技術，將可在 DLC 內實現更復雜的鏈下合約驗證結算，同時結合 OP 挑戰機制，實現預言機信任最小化。

一、引言

離散對數合約（DLC）是一種基於預言機的合約執行框架，由麻省理工學院的Tadge Dryja在2018年提出。該框架允許兩個參與方基於事先設定的條件來執行有條件的支付。各方提前籤署可能的結果，並利用這些預先籤署的承諾在預言機確認結果後完成支付。因此，DLC不僅保障了比特幣存款的安全，還爲新型去中心化金融應用的發展提供了可能。

相較於閃電網絡，DLC在以下方面表現出顯著的優勢：

隱私性：DLC在隱私保護方面優於閃電網絡。合約的細節僅在參與方之間共享，不會被記錄在區塊鏈上。而閃電網絡的交易通過公開的通道和節點進行，其信息公開透明。
金融合約的復雜性與靈活性：DLC能夠直接在比特幣網路上創建和執行復雜的金融合約，如衍生品、保險及賭博，而閃電網絡則主要用於快速小額支付，不適合復雜的金融應用。
降低交易對手風險：在DLC中，資金被鎖定在多籤名合約裏，只有在預設事件結果發生時才會釋放，大大降低了違約風險。相比之下，盡管閃電網絡減少了信任需求，但在通道管理和資金流動性方面仍存在一定的交易對手風險。
免除支付通道管理：與需管理復雜支付通道的閃電網絡不同，DLC不需創建或維護這樣的支付通道。
特定用途的可擴展性：雖然閃電網絡在一定程度上提升了比特幣的交易吞吐量，DLC則在處理比特幣網路上的復雜合約方面提供了更佳的擴展性。

盡管DLC在比特幣生態系統中具有顯著的優勢，但仍存在一些風險和問題，例如：

關鍵風險：存在Oracle私鑰和已提交的非重用號（nonces）泄露或丟失的風險，可能導致用戶資產損失。
集中信任風險：Oracle的集中化容易導致拒絕服務攻擊。
去中心化密鑰衍生問題：如果Oracle是去中心化的，Oracle節點只擁有私鑰的一部分份額。然而，去中心化的Oracle節點不能直接使用BIP32基於這些私鑰份額進行密鑰衍生。
串謀風險：如果Oracle節點之間或與某一方串謀，Oracle的信任問題仍未解決。需要一個可靠的監控機制來最小化對Oracle的信任。
固定面額變更問題：條件籤名要求在構建合約以構造交易之前，需要一個確定的、可枚舉的事件集，因此使用DLC進行資產重新分配有最小金額限制，導致固定面額變更的問題。

爲解決這爲解決這些問題，本文提出了幾種解決方案和優化思路，以降低與DLC相關的風險和問題，從而增強比特幣生態系統的安全性。

2.DLC原則解析

Alice和Bob就第（n+k）個區塊的哈希值是奇數還是偶數進行賭注。如果哈希值爲奇數，Alice獲勝並可在規定時間t內提取資金；如果爲偶數，則Bob獲勝並可在同一時間內提取資金。利用DLC技術，通過Oracle將第（n+k）個區塊的信息傳遞並構建條件籤名，確保真正的贏家能夠得到全部資產。

初始化階段：橢圓曲線的生成元爲G，其階爲q。

密鑰生成：

Oracle、Alice及Bob各自獨立生成私鑰與公鑰。
Oracle的私鑰爲z，相應的公鑰爲Z，滿足 Z=z⋅G；
Alice的私鑰爲x，公鑰爲X，滿足 X=x⋅G；
Bob的私鑰爲y，公鑰爲Y，滿足 Y=y⋅G。

資金交易：Alice和Bob共同創建資金交易，各自鎖定1 BTC於一個需要雙方籤名的多籤名輸出地址中，其中一個公鑰X屬於Alice，另一個Y屬於Bob。

合約執行交易（CET）： Alice和Bob分別創建兩個CET來使用之前的資金交易。

Oracle計算承諾後

然後計算S 和S′

並廣播（右,S,S′）。

Alice和Bob根據廣播信息各自計算相應的新公鑰。

結算：當第（n+k）個區塊產生後，Oracle根據該區塊的哈希值生成相應的s或s′。

如果哈希值爲奇數，Oracle廣播s；

如果哈希值爲偶數，Oracle廣播s′。

提款：根據Oracle廣播的s或s′，Alice或Bob可以提取鎖定的2 BTC。

如果廣播的是s，Alice通過新私鑰sk^{Alice}提取資金；

如果廣播的是s′，Bob通過新私鑰sk^{Bob}提取資金

分析： Alice計算出的新私鑰與新公鑰之間滿足離散對數關係

這樣，Alice的提現就成功了。

同樣，Bob計算出的新私鑰與新公鑰之間滿足離散對數關係

這樣，Bob的提現就會成功。

如果Oracle廣播了s，對Alice有利；相反，如果廣播了s′，則對Bob有利。未廣播的一方無法計算出對應的新私鑰。

此外，爲了確保操作在規定時間內完成，合約中應包含時間鎖設置。超過設定時間後，另一方可以使用原始私鑰進行提款。

3.DLC優化

3.1 密鑰管理

在DLC協議中，Oracle的私鑰及其承諾的隨機數（Nonce）是至關重要的。Oracle私鑰和承諾的隨機數的泄露或丟失可能會引發以下四個安全問題：

(1)Oracle丟失私鑰 z

若Oracle丟失私鑰，DLC將無法正常結算，此時必須執行DLC退款合約。爲此，DLC協議特別設計了一種退款交易，以防止因Oracle丟失私鑰而帶來的不良後果。

(2)Oracle私鑰 z 泄露Oracle私鑰 z 泄露

一旦Oracle的私鑰泄露，所有基於該私鑰的DLC面臨被欺詐結算的風險。竊取私鑰的攻擊者能籤署任何他想要的消息，從而完全控制所有未來合約的結果。更嚴重的是，攻擊者能夠發布矛盾的消息，例如同時聲明某個區塊的哈希值是奇數又是偶數。

(3) Oracle泄露或重用隨機數 k

如果 Oracle 泄露了隨機數k，那麼在結算階段，無論Oracle是否廣播s 或者s′，攻擊者都可以根據此推算出Oracle的私鑰 z 如下：

如果 Oracle 重用隨機數k，通過兩次結算後，攻擊者可以通過解析Oracle公開的籤名推導出其私鑰 z，可能出現四種情形

情況1：

案例2：

案例3：

案例4：

(4) Oracle丟失隨機數 k

Oracle如果丟失了隨機數 k，對應的DLC也無法結算，同樣需要執行DLC退款合約。

因此，爲提升Oracle私鑰的安全性，建議採用BIP32標準派生子密鑰或孫密鑰進行籤名。同時，爲了增強隨機數的安全性，建議將哈希值 k:=hash(z, 計數器) 用作隨機數 k，避免隨機數的重復使用或丟失。

3.2 去中心化的Oracle

在DLC中，Oracle的角色至關重要，因爲它提供了決定合約結果的關鍵外部數據。爲了增強這些合約的安全性，需要去中心化的Oracle。與集中式Oracle不同，去中心化的Oracle將提供準確且防篡改數據的責任分散到多個獨立節點，減少了單點故障的風險，並降低了操縱或針對性攻擊的可能性。通過去中心化的Oracle，DLC能夠實現更高程度的無需信任和可靠性，確保合約執行完全依賴於預設條件的客觀性。

去中心化的Oracle可以使用Schnorr閾值籤名來實現。Schnorr閾值籤名提供以下優點：

增強的安全性：通過分散密鑰管理，閾值籤名降低了單點故障的風險。即使部分參與者的密鑰被破壞或遭到攻擊，只要違規未超過預定義的閾值，整個系統仍然是安全的。
分散的控制：閾值籤名使得密鑰管理的控制權分散，消除了單一實體持有所有籤名權力的情況，從而減少了權力集中的風險。
提高的可用性：只要一定數量的Oracle節點同意，就可以完成籤名，增加了系統的靈活性和可用性。即使某些節點不可用，整個系統的可靠性也不會受到影響。
靈活性和可擴展性：閾值籤名協議可以根據需要設置不同的閾值，以滿足各種安全需求和場景。此外，它適合於大規模網路，具有良好的可擴展性。
責任追溯：每個Oracle節點基於其私鑰份額生成一個籤名份額，其他參與者可以使用相應的公鑰份額驗證這個籤名份額的正確性，實現了責任追溯。如果正確，這些籤名份額會累積生成完整的籤名。

因此，Schnorr閾值籤名協議在提高安全性、可靠性、靈活性、可擴展性和責任追溯方面，對於去中心化的Oracle具有顯著優勢。

3.3 去中心化與密鑰管理的結合

在密鑰管理技術中，Oracle擁有一個完整的密鑰z，並且使用BIP32和增量ω，可以衍生出許多子密鑰z+ω^{(1)}和孫子密鑰z+ω^{(1)}+ω^{(2)}。對於不同的事件，Oracle可以使用各種孫子私鑰z+ω^{(1)}+ω^{(2)}生成相應事件msg的對應籤名σ。

在去中心化的Oracle場景中，存在n個參與者，閾值籤名需要t+1個參與者，其中t<n。這n個Oracle節點中的每一個都擁有一個私鑰份額z_i，i=1,…,n。這些n個私鑰份額z_i對應於一個完整的私鑰z，但完整的私鑰z從未出現。在完整的私鑰z不出現的情況下，t+1個Oracle節點使用他們的私鑰份額z_i，i=1,…,t+1來生成消息msg′的籤名份額σ_i′，這些籤名份額σ_i′組合成一個完整的籤名σ′。使用完整公鑰Z的驗證者可以驗證消息-籤名對(msg′,σ′)的正確性。由於需要t+1個Oracle節點共同生成閾值籤名，因此提供了高安全性。

然而，在去中心化的Oracle場景中，完整的私鑰z不出現，因此無法直接使用BIP32進行密鑰衍生。換句話說，去中心化的Oracle技術和密鑰管理技術無法直接整合。

論文《多方管理區塊鏈數字資產的分布式密鑰衍生》提出了閾值籤名場景中的分布式密鑰衍生方案。其核心思想基於拉格朗日插值多項式，私鑰份額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：最小化對Oracle的信任

在DLC中，Alice和Bob之間的合約是基於Oracle籤名的結果執行的，因此需要對Oracle有一定程度的信任。因此，Oracle的正確行爲是DLC運行的主要前提。

爲了減少對Oracle的信任，研究人員已經探討了基於n個Oracle的結果執行DLC，從而減少對單個Oracle的依賴。

“n對n”模型涉及使用n個Oracle對合約進行籤名，並根據所有Oracle的結果執行合約。該模型要求所有Oracle在線籤名。如果任何Oracle掉線或對結果存在分歧，將影響DLC合約的執行。這裏的信任假設是所有Oracle都是誠實的。
“k對n”模型涉及使用n個Oracle對合約進行籤名，並根據任何k個Oracle的結果執行合約。如果超過k個Oracle串謀，將影響合約的公正執行。此外，“k對n”模型所需的條件執行交易（CETs）數量是單個Oracle或“n對n”模型的C_n^k倍。這個模型的信任假設是至少有k個中的n個Oracle是誠實的。

僅僅增加Oracle的數量並不能實現對Oracle的不信任，因爲在Oracle惡意行動之後，合約中的受害方沒有鏈上的追索權。

因此，我們提出了OP-DLC，它將樂觀挑戰機制納入到DLC中。在參與設置DLC之前，n個Oracle需要提前承諾並在鏈上構建一個無需許可的OP遊戲，承諾不進行惡意行爲。如果任何Oracle行爲惡意，那麼Alice、Bob、任何其他誠實的Oracle或任何其他第三方誠實觀察者都可以發起挑戰。如果挑戰者贏得遊戲，鏈上系統會通過沒收其押金來懲罰惡意的Oracle。此外，OP-DLC也可以採用“k對n”模型進行籤名，其中k值甚至可以是1。因此，信任假設減少到只需要網路中的一個誠實參與者發起OP挑戰並懲罰惡意的Oracle節點。

在基於第二層計算結果結算OP-DLC時：

如果Oracle籤署了錯誤的結果，導致Alice遭受損失，Alice可以使用正確的第二層計算結果來挑戰Oracle預先承諾的無需許可的鏈上OP遊戲。贏得遊戲後，Alice可以懲罰惡意的Oracle並補償她的損失。
同樣，Bob、其他誠實的Oracle節點和第三方誠實觀察者也可以發起挑戰。然而，爲了防止惡意挑戰，挑戰者也必須承諾。

因此，OP-DLC促進了Oracle節點之間的相互監督，將對Oracle的信任降到最低。這種機制只需要一個誠實的參與者，並具有99%的容錯率，有效地解決了Oracle串謀的風險。

3.5 OP-DLC + BitVM 雙橋方案

當DLC用於跨鏈橋時，資金分配必須在DLC合約結算時進行：

這需要通過條件執行交易（CETs）預設，意味着DLC的資金結算粒度受到限制，例如在Bison網路中爲0.1 BTC。這引發了一個問題：用戶的第二層資產互動不應受到DLC CETs資金粒度的限制。
當Alice想要結算她的第二層資產時，也強制使得Bob的第二層資產向第一層結算。這提出了一個問題：每個第二層用戶都應該有自由選擇他們的存款和取款，而不依賴於其他用戶的行爲。
Alice和Bob商議支出。這裏的問題是，它需要雙方願意合作。

因此，爲了解決上述問題，我們提出了OP-DLC + BitVM雙橋方案。這種解決方案使用戶可以通過BitVM的無需許可的橋梁以及通過OP-DLC機制進行存取款，實現任何粒度的變更並增強流動性。

在OP-DLC中，Oracle是BitVM聯盟，Alice作爲普通用戶，Bob作爲BitVM聯盟。設置OP-DLC時，構建的CETs允許Alice的輸出在第一層立即支出，而Bob的輸出包括一個帶有時間鎖的“DLC遊戲Alice可以挑戰”。當Alice想要提款時：

如果BitVM聯盟作爲Oracle正確籤名，Alice可以在第一層提取。然而，Bob可以在時間鎖之後在第一層提取。
如果BitVM聯盟作爲Oracle作弊，導致Alice損失，她可以挑戰Bob的UTXO。如果挑戰成功，可以沒收Bob的金額。注意：BitVM聯盟的另一個成員也可以發起挑戰，但作爲受害方的Alice最有動機這麼做。
如果BitVM聯盟作爲Oracle作弊，導致Bob損失，BitVM聯盟的一個誠實成員可以挑戰“BitVM遊戲”來懲罰作弊的Oracle節點。

此外，如果用戶Alice想要從第二層提款，但OP-DLC合約中預設的CETs與金額不匹配，Alice可以選擇以下方法：

通過BitVM提款，BitVM運營商在第一層預付金額。BitVM橋假設BitVM聯盟中至少有一個誠實參與者。
通過特定的CET在OP-DLC中提款，剩餘的變動由BitVM運營商在第一層預付。通過OP-DLC提款將關閉DLC通道，但DLC通道中的剩餘資金將轉移到BitVM第一層池，而不強制其他第二層用戶提款。OP-DLC橋假設通道中至少有一個誠實參與者。

因此，OP-DLC + BitVM雙橋提供以下優點：

BitVM解決了DLC通道的變更問題，減少了所需的CET數量，並且不受CET資金粒度的影響；
通過結合OP-DLC橋與BitVM橋，爲用戶提供了多個存取款渠道，改善了用戶體驗；
將BitVM聯盟設置爲Bob和oracle，利用OP機制，最小化了對oracle的信任；
將DLC通道的超額提款整合到BitVM橋池中，增強了資金利用。

4. 結論

在Segwit v1（Taproot）激活之前，DLC就已經出現，並且已經與閃電網絡（Lightning Network）整合，使得在同一DLC通道內更新和執行連續合約成爲可能。利用像Taproot和BitVM這樣的技術，可以在DLC中實現更復雜的鏈下合約驗證和結算。此外，通過整合OP挑戰機制，可以最小化對Oracle的信任。

聲明：

本文轉載自[medium]，原文標題“Bitlayer核心技術：DLC及其優化考慮”，著作權歸屬原作者[位層]，如對轉載有異議，請聯系Gate Learn團隊，團隊會根據相關流程盡速處理。
免責聲明：本文所表達的觀點和意見僅代表作者個人觀點，不構成任何投資建議。
文章其他語言版本由Gate Learn團隊翻譯，在未提及 Gate.io的情況下不得復制、傳播或抄襲經翻譯文章。

Konten