DLC原理解析及其优化思考

文章转载来源： Bitlayer Labs

原文标题：《Bitlayer Core Technology: DLC and Its Optimization Considerations》

作者: lynndell & mutourend, Bitlayer Research Group

原文链接：https://medium.com/@Bitlayer/bitlayer-core-technology-dlc-and-its-optimization-considerations-6fc5ebaae92c

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