Discreet Log Contracts (DLC)

什麼是 DLC？

Discreet Log Contracts（離散對數合約）由 Tadge Dryja 在 2017 年提出，是一種利用預言機簽章來執行條件支付的比特幣智能合約協議。

DLC 核心特點

* 隱私保護：預言機不知道合約存在或內容
* 無需託管：資金鎖定在 2-of-2 多簽，沒有第三方控制
* 鏈上隱私：執行後的交易看起來像普通支付
* 可擴展：可處理複雜的多結果合約

運作原理

基本概念

DLC 利用 Schnorr 簽章的數學特性，結合預言機的預先承諾（commitment）來建立合約：

關鍵角色

參與者：
┌─────────────────────────────────────────────────┐
│ Alice（合約方 A）                                │
│ * 提供資金                                       │
│ * 建構和簽署 CET（Contract Execution Tx）        │
└─────────────────────────────────────────────────┘

┌─────────────────────────────────────────────────┐
│ Bob（合約方 B）                                  │
│ * 提供資金                                       │
│ * 建構和簽署 CET                                 │
└─────────────────────────────────────────────────┘

┌─────────────────────────────────────────────────┐
│ Oracle（預言機）                                 │
│ * 發布事件公告和承諾點                           │
│ * 事件發生後發布簽章                             │
│ * 不知道有合約使用其簽章                         │
└─────────────────────────────────────────────────┘

Adaptor Signatures（適配器簽章）

DLC 的核心技術是 Adaptor Signatures，這是一種「不完整」的簽章，需要額外的秘密值才能變成有效簽章：

Adaptor Signature 原理

// Schnorr 簽章：s = k + H(R||P||m) * x
// 其中 k 是 nonce，x 是私鑰，R = k*G

// Adaptor Signature 加入一個「適配點」T = t*G
// 預簽章：s' = k + H(R+T||P||m) * x

// 完整簽章需要秘密 t：
// s = s' + t

驗證流程：
┌─────────────────────────────────────────────────┐
│ 1. 預言機發布承諾點 R_oracle                     │
│    R_oracle = k_oracle * G（k_oracle 保密）      │
│                                                 │
│ 2. 預言機為每個可能結果 i 計算：                 │
│    T_i = R_oracle + H(R_oracle||i) * P_oracle    │
│                                                 │
│ 3. Alice 和 Bob 使用 T_i 建立適配器簽章          │
│                                                 │
│ 4. 預言機發布結果 i 的簽章 s_oracle              │
│    此簽章揭露了秘密 t_i                          │
│                                                 │
│ 5. 知道 t_i 的一方可以完成交易簽章               │
└─────────────────────────────────────────────────┘

合約執行流程

完整流程

階段 1：預言機公告
┌─────────────────────────────────────────────────┐
│ Oracle 發布事件公告：                            │
│ * 事件 ID                                       │
│ * 可能結果列表 [outcome_1, outcome_2, ...]       │
│ * 承諾點 R_oracle                               │
│ * 預計公告時間                                   │
└─────────────────────────────────────────────────┘
         ↓
階段 2：合約建立
┌─────────────────────────────────────────────────┐
│ Alice 和 Bob 協商：                              │
│ * 選擇預言機和事件                               │
│ * 確定每個結果的支付分配                         │
│ * 各自投入的資金數量                             │
└─────────────────────────────────────────────────┘
         ↓
階段 3：Funding Transaction
┌─────────────────────────────────────────────────┐
│ 建立 Funding Tx：                                │
│ * 輸入：Alice 的 UTXO + Bob 的 UTXO             │
│ * 輸出：2-of-2 多簽（Alice + Bob）              │
│                                                 │
│ 注意：先建立 CET，再廣播 Funding Tx             │
└─────────────────────────────────────────────────┘
         ↓
階段 4：Contract Execution Transactions (CET)
┌─────────────────────────────────────────────────┐
│ 為每個可能結果建立 CET：                         │
│                                                 │
│ CET_outcome_1:                                  │
│   輸入：Funding Tx 輸出                          │
│   輸出：Alice 得 X BTC，Bob 得 Y BTC            │
│   需要：adaptor_sig_1 + oracle_sig_1            │
│                                                 │
│ CET_outcome_2:                                  │
│   輸入：Funding Tx 輸出                          │
│   輸出：Alice 得 A BTC，Bob 得 B BTC            │
│   需要：adaptor_sig_2 + oracle_sig_2            │
│                                                 │
│ ... 更多結果 ...                                │
└─────────────────────────────────────────────────┘
         ↓
階段 5：事件發生
┌─────────────────────────────────────────────────┐
│ Oracle 發布結果簽章：                            │
│ * 觀察真實世界事件                               │
│ * 發布對應結果的簽章 s_oracle                    │
│ * 不知道有 DLC 使用此簽章                        │
└─────────────────────────────────────────────────┘
         ↓
階段 6：合約執行
┌─────────────────────────────────────────────────┐
│ 任一方可以：                                     │
│ 1. 取得 oracle 簽章                             │
│ 2. 計算完整的 CET 簽章                          │
│ 3. 廣播對應的 CET                               │
│ 4. 根據結果分配資金                              │
└─────────────────────────────────────────────────┘

實際範例：BTC/USD 價格合約

價格對賭合約

場景：Alice 和 Bob 對 BTC 價格打賭
* 目前價格：$50,000
* 到期日：30 天後
* Alice 認為會漲，Bob 認為會跌
* 各投入 1 BTC

結果定義（簡化為 5 個區間）：
┌─────────────────────────────────────────────────┐
│ 結果      │ 價格區間        │ Alice │ Bob    │
│───────────│─────────────────│───────│────────│
│ outcome_1 │ < $40,000       │ 0 BTC │ 2 BTC  │
│ outcome_2 │ $40,000-$50,000 │ 0.5   │ 1.5    │
│ outcome_3 │ $50,000-$60,000 │ 1     │ 1      │
│ outcome_4 │ $60,000-$70,000 │ 1.5   │ 0.5    │
│ outcome_5 │ > $70,000       │ 2 BTC │ 0 BTC  │
└─────────────────────────────────────────────────┘

Oracle 公告：
{
  "event_id": "btc_usd_2024_01_30",
  "outcomes": ["<40k", "40k-50k", "50k-60k", "60k-70k", ">70k"],
  "maturity": "2024-01-30T00:00:00Z",
  "oracle_pubkey": "02abc...",
  "nonce_point": "03def..."
}

30 天後，BTC = $65,000
Oracle 發布 outcome_4 的簽章
Alice 可以廣播 CET_4，獲得 1.5 BTC

數值結果處理

對於連續數值（如價格），為每個可能值建立 CET 不切實際。 DLC 使用數字分解技術來處理：

數字分解（Digit Decomposition）

// 假設價格範圍 0-99999，精度為 1 美元
// 直接方式需要 100,000 個 CET！

// 數字分解：使用 base-10 表示
// 價格 65432 = [6, 5, 4, 3, 2]
// 只需要 5 個 Oracle 簽章點，每個 10 種可能

Oracle 為每個數字位發布承諾：
┌─────────────────────────────────────────────────┐
│ digit_0 (萬位): R_0, outcomes [0,1,2,3,4,5,6,7,8,9]
│ digit_1 (千位): R_1, outcomes [0,1,2,3,4,5,6,7,8,9]
│ digit_2 (百位): R_2, outcomes [0,1,2,3,4,5,6,7,8,9]
│ digit_3 (十位): R_3, outcomes [0,1,2,3,4,5,6,7,8,9]
│ digit_4 (個位): R_4, outcomes [0,1,2,3,4,5,6,7,8,9]
└─────────────────────────────────────────────────┘

CET 數量計算：
* 5 位數字 x 10 種值 = 50 個 adaptor points
* 使用區間優化後可進一步減少
* 比 100,000 個 CET 高效得多！

Oracle 發布：
s_0 = sign(6)  // 萬位
s_1 = sign(5)  // 千位
s_2 = sign(4)  // 百位
s_3 = sign(3)  // 十位
s_4 = sign(2)  // 個位
// 組合得到 65432

多預言機支援

為了降低單一預言機風險，DLC 支援多種多預言機配置：

N-of-N

所有預言機必須同意。提供最高安全性，但任一預言機離線會導致合約無法執行。

K-of-N

需要 K 個預言機同意。例如 2-of-3 提供容錯能力，同時維持去中心化。

多預言機實作

// 2-of-3 預言機配置
oracles = [Oracle_A, Oracle_B, Oracle_C]

// 建立 CET 需要任意兩個預言機的簽章組合
combinations = [
  (Oracle_A, Oracle_B),
  (Oracle_A, Oracle_C),
  (Oracle_B, Oracle_C)
]

// 每個結果需要 3 組 adaptor signatures
// CET 可以用任意一組完成

// 容錯：即使一個預言機離線或作惡，
// 合約仍可用其他兩個執行

應用場景

金融衍生品

期貨、期權、差價合約（CFD）。用戶可以對資產價格進行對沖或投機，無需信任交易對手或中央清算所。

預測市場

對選舉、體育賽事、天氣等事件結果進行預測。預言機報告結果，資金自動分配給正確預測者。

保險合約

參數化保險，如航班延誤、天氣災害保險。當觸發條件發生時自動理賠，無需傳統保險流程。

託管服務

條件託管，當預言機確認條件滿足時釋放資金。可用於跨境交易、里程碑付款等。

與其他方案比較

特性	DLC	傳統託管	以太坊智能合約
託管風險	無	高	智能合約風險
隱私性	高	低	低
預言機知情	否	是	是
鏈上足跡	最小	中等	大
靈活性	中等	高	最高
預先定義結果	必須	不需要	不需要

實作工具

rust-dlc

Rust 實作的 DLC 函式庫，提供完整的協議支援。


github.com/p2pderivatives/rust-dlc

bitcoin-s

Scala 比特幣函式庫，包含 DLC 支援和錢包功能。


github.com/bitcoin-s/bitcoin-s

DLC.Link

提供 DLC 基礎設施，簡化開發者整合。

dlc.link

標準規格

DLC 有一套正在發展的標準規格，類似閃電網路的 BOLT：

DLC 規格列表

* DLC Spec 0：介紹和術語定義
* DLC Spec 1：Oracle 公告和簽章格式
* DLC Spec 2：合約協商協議
* DLC Spec 3：交易結構（Funding, CET, Refund）
* DLC Spec 4：P2P 訊息格式
* DLC Spec 5：數值結果處理

規格文件：github.com/discreetlogcontracts/dlcspecs

挑戰與限制

目前挑戰

1. 預言機可用性：需要可靠的預言機服務，且預言機必須在預定時間發布簽章
2. 資本效率：資金在合約期間被鎖定，無法用於其他用途
3. CET 數量：複雜合約可能需要大量 CET，增加協商時間
4. 用戶體驗：需要雙方同時在線進行協商
5. 預言機審查：預言機可能拒絕發布簽章（但無法知道合約內容）

未來發展

Taproot 整合

使用 Taproot 可以大幅減少 CET 的鏈上足跡，讓 DLC 交易看起來完全像普通支付。

閃電網路 DLC

在閃電網路通道內執行 DLC，實現即時結算和更高的資本效率。

總結

DLC 代表了比特幣智能合約的重要進展。透過巧妙運用密碼學，它實現了無需信任的條件支付，同時保護所有參與方（包括預言機）的隱私。

雖然 DLC 不如以太坊智能合約靈活，但它提供了更強的安全性和隱私保障。隨著工具和基礎設施的成熟，DLC 有望成為比特幣生態系統中重要的金融基礎設施。