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=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)} 和孙密钥 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 挑战机制，实现预言机信任最小化。

参考文献

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. BIP32 BIP44
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

    原文链接