# BitVM桥与OP-DLC：新一代比特币Layer2跨链桥的设计思路

By [BitSafe中文](https://paragraph.com/@bitsafe) · 2024-06-03

---

原文链接:

[https://mp.weixin.qq.com/s/LDUgh7EG1lHrw7ZA2gBE2w](https://mp.weixin.qq.com/s/LDUgh7EG1lHrw7ZA2gBE2w)

![](https://storage.googleapis.com/papyrus_images/0db5e020352edb0c1ef0c5268d71cc8a9f56920c89128eca280751df46896de5.png)

**（DLC原理图）**

**DLC：谨慎日志合约**

DLC（Discreet Log Contracts）名为谨慎日志合约，由MIT的Digital Currency Initiative提出，该技术最早用于在比特币上实现一种轻量级的智能合约，不需要把合约的内容上链，就可以通过链下交互式通讯和预签名等方法，在比特币链上实现出保护隐私的智能合约功能。**下面我们通过一个赌球案例来说明DLC的工作原理。**

假设Alice与Bob要对3天后举行的皇马和巴萨的比赛结果打赌，两人各出1个btc。如果皇马胜出，则Alice可以获得1.5 BTC，Bob只能收回0.5 BTC，这就相当于Alice赚0.5个BTC，Bob亏损0.5 BTC；如果巴萨胜出，Alice只能收回0.5 BTC，Bob则可以拿走1.5 BTC。如果平局，两人各自从拿回1个BTC。

如果我们要让上述对赌过程变得去信任化，就要想办法防止任何一方耍赖，如果单纯用2/2多签或是2/3多签，显然还不够去信任。DLC针对这一要点给出了自己的解决方案（要依赖于第三方预言机）。**其整个工作流程大体可以分为四部分。**

以前面的Alice和Bob为例，**首先，双方在链下创建一笔fund交易，这可以把彼此的1枚BTC锁在2/2多签地址上**，如果这笔fund交易生效，则该多签地址里的2枚BTC需要双方都授权，才能被花费。

当然，这笔Fund交易先不上链，只留存在链下的Alice和Bob客户端本地，他们都知道这笔交易生效后会有什么后果。**目前双方只是在进行理论推演，然后根据推演的结果达成一系列协议。**

在DLC创建的第一阶段，我们可以确定的是，**双方将在未来把各自的1枚BTC锁入一个多签地址中。**

![](https://storage.googleapis.com/papyrus_images/5d0bb0bb8810780b6a2e12ac11d6ec30369289938d979757c913b7604be3f01b.png)

第二步，双方继续推演未来可能发生的事件和结果：\*\*比如，当球赛结果公布后，可能是Alice赢Bob输、Alice输Bob赢、平局等多种可能，这会导致前述2/2多签地址中的比特币出现不同的分配结果。

不同的结果需要由不同的交易指令来触发，这些\*\*“可能在未来上链的交易指令”被称为CET\*\*，即合约执行交易（Contract Execution Transaction）。Alice和Bob要事先推演出所有的CET，生成包含全部CET的交易数据集。

例如，**根据前述Alice和Bob对赌的几种可能结果，Alice创建出以下几种CET：**

CET1：\*\*Alice可从多签地址获得1.5枚BTC，Bob可获得0.5枚BTC；

CET2：\*\*Alice可从多签地址获得0.5枚BTC，Bob可获得1.5枚BTC；

CET3：\*\*双方各自可获得1枚BTC。

**我们以CET1为例（Alice拿 1.5 BTC，Bob拿 0.5 BTC）：**

这笔交易的意思是，把多签地址中的1.5枚BTC，转移到一个由Alice和预言机输出结果共同触发的Taproot地址，另外0.5枚BTC转移给Bob的地址。此时对应的事件是：皇马胜出，Alice赢0.5BTC，Bob输0.5BTC。

当然

![](https://storage.googleapis.com/papyrus_images/bcd359cb2cb03d95d1df4a0d46ca394c55891b048a613eb5154afb1a209e0d01.png)

，**要花费这1.5枚BTC，Alice必须拿到预言机发送的“皇马胜出”结果签名**。换句话说，只有当预言机输出“皇马胜利”的消息后，Alice才能够把这1.5枚BTC转走。至于CET2和CET3的内容，我们可以以此类推，在此不赘述。

![](https://storage.googleapis.com/papyrus_images/f3641a0643c042198d7ec9668658c65abb422580198b063bfe5a681e5857ed8f.png)

需要注意的是，CET本质是一笔待上链待生效的交易，**如果Alice提前把CET1广播出去，或是在“巴萨胜出”的情况下，仍然把“皇马胜出”后才能顺利触发的CET1上链，会发生什么？**

前面的示意图中，我们提到，CET1上链后，会把原始多签地址中锁定的2枚BTC转走，0.5枚BTC转给Bob，1.5枚BTC转到一个Taproot地址中，预言机输出“皇马胜出”后，Alice方能解锁Taproot地址锁定的BTC。效果如下图所示。

同时，这个Taproot地址受到时间锁限制，**如果在时间锁规定的窗口期内，Alice无法成功提走1.5枚BTC，则Bob有权把这些钱直接拿走。**

所以，只要预言机是诚实的，Alice就无法拿走这1.5枚BTC，等时间锁期限耗尽，Bob可以把这1.5枚BTC拿走。再算上CET1上链时直接转给Bob的那0.5枚BTC，最后所有的钱都会归Bob所有。

![](https://storage.googleapis.com/papyrus_images/f3641a0643c042198d7ec9668658c65abb422580198b063bfe5a681e5857ed8f.png)

**对于Alice而言，无论自己最终是赢还是输，最有利的做法都是把正确的CET上链，把无效的CET上链会让自己输更多钱。**

其实上述CET在构建时，对Taproot的schnorr签名做了改进，可以理解为利用预言机的公钥+事件结果，针对不同结果构造出彼此独立的地址。之后，等预言机公布某个结果对应的签名，才能花费该结果对应的地址上锁定的BTC。

当然，这里面存在一种额外的可能。假如Alice知道自己输了，干脆不把自己构建的CET1上链，这个时候怎么办？这个很好解决，因为**Bob可以针对“alice输，Bob赢”一事构建出自定义的CET，这个CET达成的效果和Alice构建的CET基本一致，只是具体细节不一样，但结果是一样的。**

上面讲述的就是最关键的CET构建流程。而DLC的第三步，是Alice和Bob双方进行通讯，检查对方构建的CET交易，带上自己对该CET的签名，检查无误后，可以信任彼此，便各自出资1枚BTC，锁入最开始提到的那个Alice和Bob的2/2多签地址，然后等待某个CET被上链，触发后续的流程。

最后，等预言机公布结果，拿到预言机对结果的签名后，任意一方可以把正确的CET上链，让多签地址中锁定的2枚BTC被再分配，如果输家抢先把错误的CET上链，会让自己损失所有的钱，如果把正确的CET上链，输家还可以收回0.5BTC。

![](https://storage.googleapis.com/papyrus_images/f7f3c92acdfa5ade8eb18de7c72a10377f56f056bc3190ed9d0fa1fc66fadcbd.png)

可能有人会问，\*\*DLC与普通的2/3多签有何不同？\*\*首先，2/3多签下，任意两方串谋即可盗走全部资产，而DLC通过提前构建CET集合的方式，让对手方之间把全部的场景都限制住了，就算预言机参与串谋，造成的损失往往也有限。

其次，多签需要各方针对具体的待上链交易进行签名，而**在DLC的设定下，预言机只需要对特定事件的结果进行签名，不需要知道CET/待上链交易的内容，甚至完全不需要知道有Alice和Bob这两个人，只需要像普通的预言机那样和用户进行正常的交互即可。**

我们可以认为，\*\*DLC本质是把对多签参与方的信任转变成了对预言机的信任，\*\*只要预言机不参与作恶，就可以保证DLC的协议设计足够去信任。理论上来说，**DLC可以采用比较成熟完善的第三方预言机，来避免作恶**。而DLC.link利用了DLC的这种特性，把桥的信任问题转嫁给了第三方预言机。

---

*Originally published on [BitSafe中文](https://paragraph.com/@bitsafe/bitvm-op-dlc-layer2)*