Bitlayer核心技术：DLC及其优化考虑
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的情况下不得复制、传播或抄袭经翻译文章。
相关文章
如何质押 ETH？
Bitlayer核心技术：DLC及其优化考虑
一、引言
离散对数合约（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的情况下不得复制、传播或抄袭经翻译文章。
相关文章
如何质押 ETH？