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

作者：Faust & Nickqiao，极客web3

摘要：

· ZK桥在A链上部署智能合约，直接接收验证B链区块头及相应零知识证明，确认跨链消息的有效性，属于安全级别最高的桥接方案；乐观/OP桥通过欺诈证明对无效的跨链消息进行链上挑战，只需存在1个可靠的挑战者，即可保证跨链桥资金池的安全；

·比特币主网因为存在技术上的限制，无法直接部署ZK桥，但可以通过BitVM和欺诈证明实现乐观桥。Bitlayer和Citrea等团队采用了BitVM桥的方案，引入预签名，结合了通道的思想，让用户在正式存款前，对存款执行后的处理流程进行限定，不给跨链桥官方挪用用户存款的机会。

· BitVM桥本质基于“垫付-报销”模式，有专门的Operator节点为提款用户打钱，Operator可以定期向公共存款地址申请报销。如果Operator存在不实的报销申请，可以被任何人挑战并Slash；

· BitVM桥在理论上不存在安全问题，但存在活性/可用性问题，而且不能满足特定用户对资金独立性和反洗钱的需求（本质还是资金池的模式）。Bitlayer对此增设了名为OP-DLC的桥接方案，该方案类似于DLC.link，在通道和DLC的基础上引入欺诈证明，防止DLC桥的预言机作恶。

· 由于BitVM和欺诈证明的落地难度大，DLC桥会率先落地并成暂时的替代物，只要解决预言机的信任风险，集成更为可靠成熟的第三方预言机，DLC桥可以在现阶段成为比多签桥更安全的提款验证方案。

导语：自去年的铭文热潮以来，比特币生态便以井喷之势步入高速增长期，短短半年时间，打着BTC Layer2旗号的项目便已达到近100家，简直成了一片乱象迭出、机会与骗局共存的新大陆。毫不夸张的说，现在的比特币生态已经是以太坊、Cosmos与Celestia、CKB和比特币native生态的“多民族大熔炉”，加之缺乏权威的声音，比特币生态体系简直就像19世纪的美国一样，成为了吸纳各路势力的新天地。这在为整个Web3叙事带来繁荣与活力的同时，也引入了巨大的风险。

许多项目在连技术方案都没发布的情况下，就开始肆意炒作，打着native layer2的名号，声称能完整继承比特币主网的安全性；更有甚者玩起了造概念的宣传手法，发明一堆光怪陆离的名词术语，作为宣扬自身优越性的台词。虽然自吹自擂已然是比特币生态的现状，但还是有不少顶级KOL发出了客观的呼声。

前不久，区块链浏览器Mempool创始人Monanaut公开批判了当下比特币生态的问题，他犀利的指出，如果一个比特币Layer2单纯采用多签形式的提款桥，无法以一种去信任的形式让用户把资产随时撤出，这样的项目就不是一个真正的Layer2。有趣的是，此前Vitalik也曾指出，Layer2在安全保障上至少应比单纯依赖于多签的系统更安全。

可以说，Monanaut和Vitalik直言不讳的指出了比特币Layer2在技术上的问题：很多L2的提款桥本质都是多签桥，要么是几个知名机构各执一道密钥，要么采用基于POS的去中心化签名，但无论如何，其安全模型都基于多数诚实假设，即默认大多数多签参与者不串谋作恶。

这种严重依赖于信用背书的提款桥方案绝非长久之计，历史已经告诉我们，多签桥迟早会出各种各样的问题，只有信任最小化或是趋于完全去信任的资产托管方式，才能经受住时间和黑客的考验。但比特币生态的现状是，很多项目方连提款桥技术路线图都没有发布，对于桥该如何去信任或是信任最小化，压根没有成型的设计思路。

但这并非比特币生态的全部。目前仍然有一些项目方针对提款桥优化思路发表了意见。在本文中，我们将对Bitlayer以及Citrea的BitVM桥进行简要解析，并介绍Bitlayer针对BitVM桥的不足而提出的OP-DLC桥，让更多人理解跨链桥的风险与设计思路，这对于广大比特币生态参与者而言，至关重要。

乐观桥：基于欺诈证明的桥接验证方案

其实，跨链桥的本质很简单，就是向B链证明A链上的确发生了某事件。比如说，你从ETH往Polygon上跨资产，要让跨链桥帮你证明，你确实向ETH链上的特定地址转入了资产，然后你可以在Polygon链上接收等量资金。

传统的跨链桥一般采用见证人多签，他们会在链下指定几个见证人，见证人要运行各条公链的节点，监测是否有人向跨链桥收款地址充入了资金。

这类跨链桥的安全模型和多签钱包基本一致，要按照多签设置方式比如M/N来判定其信任模型，但最终基本都遵循诚实多数假设，就是默认多数公证人都是无恶意的，容错率比较有限。此前发生过的多起大数额的跨链桥被盗案，基本都发生在这类多签桥身上，要么是监守自盗，要么是被黑客攻击。

相比之下，基于欺诈证明协议的“乐观桥”，和基于ZK的“ZK桥”，要安全的多。以ZK桥为例，它会在目标链上设置专用的验证器合约，直接在链上验证提款证明，免去对链下见证人的依赖。

比如说，一个横跨ETH和Polygon的ZK桥，会在Polygon上部署一个验证者合约，暂且记作Verifier。ZK桥的Relayer节点会将最新的以太坊区块头，及证明有效性的ZK Proof转发给Verifier，由后者验证。这相当于让Verifier合约在Polygon链上同步并验证最新的以太坊区块头。区块头上记录的merkle root与区块内包含的交易集合有关联性，可以用于验证区块中是否包含某笔交易。

如果在区块高度为101的以太坊区块内，包含10笔从ETH到Polygon的跨链转账声明，Relayer会生成与这10笔交易相关的Merkle Proof，向Polygon链上的Verifier合约提交证明：

101号以太坊区块内包含10笔ETH到Polygon的跨链交易。当然，ZK桥可以把Merkle Proof进行ZK化，直接向Verifier合约提交ZK Proof。这整个流程中，用户只需要信任跨链桥的智能合约没有漏洞，以及零知识证明技术本身安全可靠，不需要像传统多签桥那样引入过多的信任假设。

而“乐观桥/Optimistic Bridge”要略为不同，一些乐观桥保留了类似于见证人的设定，但是会引入欺诈证明和挑战窗口期，见证人对跨链消息生成多签后，虽然会提交至目标链上，但其有效性不会被立刻认可，要度过一个窗口期且无人提出质疑，才能被判定为有效。这其实和Optimistic Rollup（乐观Rollup）的思路有些类似。当然，乐观桥还有其他的产品模式，但归根结底，安全性是靠欺诈证明协议来保障的。

M/N多签桥的信任假设是N-(M-1)/N，你要假设网络中的恶意者数量最多只有M-1个，则诚实者数量至少为N-(M-1)。ZK桥的信任假设可以忽略不计，而基于欺诈证明的乐观桥，信任假设为1/N，N个见证人中只需要有一个诚实，愿意对提交至目标链的无效跨链消息进行挑战，便可保证桥的安全。

目前，由于技术上的限制，只能实现比特币向Layer2存款方向的ZK桥，而如果方向相反，从Layer2向比特币链上提款，只支持多签桥或乐观桥，或是类似于通道的模式（下文要讲述的OP-DLC桥更像是通道）。要在比特币链上实现乐观桥，就要引入欺诈证明，bitVM为这一技术的实现创造了良好条件。

在此前的文章《极简解读BitVM：如何在BTC链上验证欺诈证明》，我们曾简单介绍过，BitVM的欺诈证明，本质是把链下进行的复杂计算任务，拆解为大量的简单步骤，再挑出某一步放在比特币链上直接验证。这种思路和Arbitrum、Optimism等以太坊乐观Rollup比较类似。

当然，上述说法还是比较晦涩，但相信大多数人早就对欺诈证明的含义有所了解。在今天的这篇文章中，受限于整体篇幅，我们不打算对BitVM和欺诈证明协议的技术实现细节进行解读，因为这涉及到一系列复杂的交互流程。

我们将从产品与机制设计的角度简要介绍BitLayer和Citrea、BOB乃至于BitVM官方设计的原生BitVM桥，以及Bitlayer如何通过OP-DLC桥来缓解BitVM桥的瓶颈，向大家展示如何在比特币链上设计出更优越的提款桥方案。

Bitlayer和Citrea的BitVM桥原理简析

下文中，我们以Bitlayer和Citrea、Bob已公布的BitVM桥方案作为素材，来阐明BitVM桥的大体运作流程。

在其官方文档和技术博客中，上述项目方比较清晰的解释了BitVM提款桥的产品设计思路（目前处于理论阶段）。首先，当用户通过BitVM桥提款时，需要借助Layer2上的Bridge合约生成提款声明，提款声明中会指定以下关键参数：

• 提款人需在L2销毁的映射版BTC数量（如1个BTC）；
• 提款人打算支付的跨链手续费（假设为0.01个BTC）；
• 提款人在L1的收款地址：L1_receipt；
• 提款人的收款金额（即1 — 0.01 = 0.99BTC）

之后，上述提款声明会被包含进Layer2的区块中。BitVM桥的Relayer节点会同步Layer2区块，监听其中包含的提款声明，并将其转发给Operator节点，由后者为提款用户打款。

这里需要注意的是，Operator是先自掏腰包在比特币链上为用户打款，也就是替BitVM桥“垫付”资金，之后再向BitVM桥的资金池申请补偿。

Operator在申请报销时，需要提供自己在Bitcoin链上的垫付证明（就是证明自己在L1上向提款用户指定的地址打款了，要把包含在比特币区块中的特定转账记录抽出来）。同时，Operator还要出具提款人在L2生成的提款声明（通过Merkle Proof，证明出具的提款声明来自于L2区块中，而不是自己凭空捏造的）。之后，Operator需要证明如下事项：

Operator替BitVM桥垫付给提款人的资金，等于提款人在声明中要求的收款金额；

Operator申请报销时，报销金额不多于提款人在Layer2销毁的映射版BTC金额；

Operator的确把一段时间内的L2-L1提款声明全部处理了，每一笔提款声明都能匹配到比特币链上的提款转账记录；

这本质是对Operator谎报垫付金额，或是拒绝处理提款声明的惩罚（可以解决提款桥的抗审查问题）。Operator需要在链下对垫付证明和提款声明的关键字段进行对比验证，证明两者涉及的BTC数额相等。

而如果提款桥Operator谎报垫付金额，就是指Operator声称在L1上的payment proof，和L2提款人发出的Withdrawal Statement相匹配，但实际情况却是两者并不匹配。

这样一来，证明Payment Proof = Withdrawal Statement 的ZKP一定是有错误的。只要这个ZKP被发布出去，Challanger就可以指出其中哪一步有错，并通过BitVM2的欺诈证明协议进行挑战。

需要强调的是，Bitlayer和Citrea、BOB、ZKBase等都采用了最新的BitVM2路线，也就是新版的BitVM方案，这种方案会把链下的计算任务ZK化，也就是说，为链下进行的计算过程生成ZK Proof，然后对Proof进行验证，之后把验证ZKP的过程转化为适配于BitVM的形式，便于后续的挑战。

同时，通过采用Lamport和预签名，可以把原始BitVM的多轮交互式挑战，优化为单轮非交互式挑战，极大程度降低了挑战的难度。

BitVM的挑战流程需要用到一种称为“承诺”的东西，即Commitment。我们解释下什么是“承诺”。一般而言，在比特币链上发布“承诺”的人会声称，某些存放在链下的数据/发生在链下的计算任务是准确无误的，而发布到链上的相关声明就是“承诺”。

我们可以近似的把Commitment理解为一大批链下数据的hash。承诺Commitment本身的尺寸往往被压缩的很小，但其可以通过Merkle Tree等方式，与大量的链下数据相绑定，而这些被关联的链下数据无需上链。

在BitVM2和Citrea、BitLayer的BitVM桥方案中，如果有人认为提款桥Operator在链上发布的承诺有问题，该承诺关联了无效的ZKP验证流程，就可以发起挑战，而且挑战权限是Permissionless的。（里面的交互流程比较复杂，在此不展开解释）

由于Operator是替BitVM资金池垫付资金来给提款人打款，之后再向资金池申请报销，在申请时，Operator要发布一个Commitment，证明自己在L1上给提款人转的钱，等于提款人在L2上声明要收到的钱。如果这个Commitment经过了欺诈证明窗口期仍然没有被挑战，Operator就可以取走自己需要的报销金额。

这里我们要解释下BitVM桥的公共资金池是如何维护的，而这恰恰是跨链桥最关键的部分。大家都知道，跨链桥能兑付给提款人的资金，来源于存款人或是其他LP贡献的资产，而Operator垫付出去的钱，最终都要从公共资金池抽走，所以单纯看资金的转移结果，BitVM桥吸收的存款人Deposit金额，应等于提款人Withdraw的金额。那么如何保管Deposit的资金，就是一个很重要的问题。

在大多数比特币Layer2的桥接方案中，往往通过多签来管理公共资产，用户的存款被汇总到一个多签账户中，当需要给提款人打款时，就由这个多签账户负责打款，这种方案显然是存在巨大的信任风险的。

而Bitlayer和Citrea的BitVM桥，采用了类似于闪电网络和通道的思想，用户在存款前，会先和BitVM联盟进行通讯，让后者进行预签名，以达成以下效果：

用户向充值地址转入存款后，这些钱会直接锁定在一个Taproot地址上，只能由桥的Operator来领取。而且，Operator只有向用户垫付了提款资金后，通过申请报销的方式，向上述存款的Taproot地址申领资金。挑战期结束后，Operator才能把一定额度的用户存款取走。

在BitVM桥方案中，存在由N个成员组建的BitVM联盟（BitVM Federation），由他们对用户的存款进行调度。但这N个成员无法私自挪用用户的存款，因为用户在向指定地址打款前，会要求BitVM联盟先进行预签名，确保这些存款只能被Operator合法申领。

高度概括，BitVM桥采用了类似于通道和闪电网络的思想，让用户“verify by yourself”，通过预签名的方式让BitVM联盟无法擅自操纵存款池，存款池的钱只能用于为Operator报销资金。如果Operator谎报垫付金额，任何人都可以发布欺诈证明并进行挑战。

如果上述方案可以落地，届时BitVM桥将成为最安全的比特币提款桥之一：这种桥不存在安全问题，仅存在可用性/活性问题。用户在尝试向BitVM存入资金时，可能遭到BitVM联盟的审查或拒绝配合，导致无法顺利存入资金，但这与安全无关而属于活性/可用性问题。

但BitVM桥的落地难度比较大，而且也无法满足一些对资金透明度要求比较高的大户的需求：这些人可能涉及到反洗钱问题，不太希望把自己的资金与别人的资金混到一起，但BitVM桥会统一收纳存款者的钱，某种程度上是一个混杂很多钱的池子。

为了解决上述BitVM桥的活性问题，以及为有特定需求的人提供独立干净的资金出入通道，BitLayer团队额外增设了名为OP-DLC的跨链桥方案，在BitVM2的乐观桥之外，采用了类似于DLC.link的DLC桥，为用户提供BitVM桥和OP-DLC桥两个出入口，以此降低对BitVM桥乃至于BitVM联盟的依赖。

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锁入一个多签地址中。

第二步，双方继续推演未来可能发生的事件和结果：比如，当球赛结果公布后，可能是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。

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

需要注意的是，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所有。

对于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。

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

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

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

此外，Bitlayer的DLC桥还支持自建的预言机节点，在此之上加上了一层欺诈证明，当自建的预言机把无效的CET上链时，允许任何人对其进行挑战。关于其OP-DLC桥的原理，我们将在下面展开简述。

OP-DLC桥：DLC通道+欺诈证明

我们从存取款的全流程来解释OP-DLC桥的运转原理。假设现在Alice通过OP-DLC桥向L2存款1枚BTC，根据两步交易机制，ALice先生成一个pre-fund交易，如下图：

这其实是先把1枚BTC转移到Alice和BitVM联盟成员共同控制的Taproot地址中，然后开启创建CET的一系列流程。如果BitVM桥联盟成员拒绝配合Alice的存款请求，Alice可以等时间锁结束后，把钱立刻抽回去。

如果BitVM联盟成员愿意配合Alice，双方便通过链下通讯的方式，先生成正式的Fund存款交易（先不上链），以及提款场景下全部的CET，待CET生成和检验结束后，双方才把Fund交易提交上链。

在Fund交易的Witness/签名数据里，Alice会指定自己在Layer2的收款地址；Fund交易上链后，Alice可以向Layer2上的桥合约提交上述fund交易数据，证明自己在比特币链上完成了存款动作，有资格让L2桥合约向指定的收款地址释放Token。

Fund交易触发后，存款实际上还是被锁定于Alice和BitVM联盟成员共同控制的Taproot多签地址中。但要注意，该多签只能通过CET来解锁该地址锁定的BTC，BitVM联盟不能平白无故把钱转走。

接下来我们来解析Alice和BitVM联盟事先构建好的CET。这些CET用来满足未来提款时的潜在场景，比如Alice可能存入了1枚BTC，但她初次提款时只提走0.3枚BTC，剩下的0.7枚BTC交由BitVM联盟的公共资金池来支配，但要再提款就只能通过前文讲过的BitVM桥；

或者干脆用这0.7枚BTC发起一次新的pre-fund存款，当做是一笔新充入DLC桥的资产，可以重复前面提过的fund交易和CET构建流程。

上述流程不难理解，其实就是让存款人Alice和bitVM联盟互相充当对手方，为不同金额的提款事件创建CET，然后让预言机读取Alice在Layer2发起的提款声明，判断Alice想触发哪一个CET（想提多少钱）。

这里面的风险在于，预言机可能和BitVM联盟串谋，比如Alice声明要提款0.5枚BTC，预言机却伪造了提款声明，最终使得“Alice收回0.1BTC，BitVM联盟收到0.9BTC”的错误CET上链。

对此的解决方法有好几种，首先就是可以采用在设计上比较完善的第三方预言机，防止此类串谋行为（此时BitVM联盟要和预言机串谋的拉拢难度极高），或者让预言机进行质押，预言机需要定期在比特币链上发布Commitment，声明自己诚实的处理了提款人的提款请求。任何人都可以通过BitVM的欺诈证明协议对Commitment进行挑战，如果挑战成功，就Slash作恶的预言机。

在OP-DLC桥的设计下，用户可以始终对自己的资产“参一手”，防止资产被BitVM联盟挪用，而且这种类似于通道的设计方案，为用户带来了更多的自主权，也不需要让自己的资金和其他人的资金混到一起，更像一种P2P点对点的存取款方案。

此外，考虑到BitVM方案要过一段时间才能落地，在其落地前，相比于单纯的多签方案，DLC桥都是更可靠的桥接处理模型。这种方案也可以作为与BitVM桥并行使用的两大存取款出入口，其中一个出了故障后，用户可以走另一个出入口，也不失为一种好的容错方法。

总结

BitLayer和Citrea的BitVM桥方案，本质是“垫付-报销”模式，有专门的Operator节点为提款用户打钱，Operator可以定期向公共存款地址申请报销。如果Operator存在不实的报销申请，可以被任何人挑战并Slash。

BitVM2的方案引入预签名，结合了通道的思想，让用户在正式存款前，对存款执行后的处理流程进行限定，不给跨链桥官方挪用用户存款的机会。

这种桥在理论上不存在安全问题，但存在活性/可用性问题，而且不能满足特定用户对资金独立性和反洗钱的需求（本质还是资金池的模式），落地难度也很大。

为此，Bitlayer增设了名为OP-DLC的桥接方案，该方案类似于DLC.link，在通道和DLC的基础上引入欺诈证明，防止DLC桥的预言机作恶。

但由于BitVM的落地难度太大，DLC桥会率先落地并成暂时的替代物，只要解决预言机的信任风险，集成更为可靠成熟的第三方预言机，DLC桥可以在现阶段成为比多签桥更安全的提款验证方案。