Merlin技术方案解读：它到底是怎么运转的？

作者：Faust，极客web3

从2023年的铭文之夏至今，比特币Layer2始终都是整个Web3的重头戏。虽然这一领域的兴起远晚于以太坊Layer2，但凭借着POW的独特魅力，以及现货ETF的顺利落地，无需顾忌“证券化”风险的比特币在短短半年时间里，就为Layer2这一衍生赛道吸引了动辄百亿美元的资本注意力。

而在比特币Layer2赛道中，坐拥数十亿美元TVL的Merlin，毫无疑问是体量最大、关注者最多的那一个。凭借着明确的质押激励和可观的收益率，Merlin几乎是在几个月之内突然拔地而起，打造了一个超越Blast的生态神话。随着Merlin的逐渐火热，关于其技术方案的探讨也成为越来越多人关注的话题。

在本文中，极客web3将聚焦于Merlin Chain技术方案，对其已公开的文档及协议设计思路进行解读，我们致力于让更多人理解Merlin的大致工作流程，对其安全模型有更清晰的认知，让大家以更直观的方式来理解这个“头部比特币Layer2”到底是怎么运转的。

Merlin的去中心化预言机网络：开放性的链下DAC委员会

对于所有的Layer2而言，无论是以太坊Layer2，还是比特币Layer2，DA与数据发布成本，都是最需要解决的问题之一。由于比特币网络本身存在诸多问题，天生不支持较大的数据吞吐量，该如何利用这寸土寸金的DA空间，成为了考验Layer2项目方想象力的难题。

有一个结论是显而易见的：如果Layer2“直接”把未经处理的的交易数据，发布到比特币区块里，既不能实现高吞吐量，也不能实现低手续费。最主流的解决方案，要么通过高度压缩，把数据尺寸压缩的尽可能小，再上传到比特币区块，要么就把数据直接发布在比特币链下。

采用第一种思路的Layer2中，最出名的可能是Citrea，它们打算把一段时间内Layer2的状态变化(state diff)，也就是多个账户上的状态变更结果，连同对应的ZK证明，一起上传到比特币链上。这种情况下，任何人都可以从比特币主网下载state diff 和ZKP，进而监测到Citrea状态的变化结果。这种方法可以把上链的数据尺寸压缩90%以上。

虽然这可以极大程度压缩数据尺寸，但瓶颈还是很明显。如果在短时间内，有大量的账户发生状态变更，Layer2要把这些个账户的变更情况，全部汇总上传到比特币链上，最终的数据发布成本无法压到很低，这一点在很多以太坊ZK Rollup身上可见一斑。

很多比特币Layer2干脆走第二种路径：直接用比特币链下的DA解决方案，要么自己搭建一个DA层，要么就用Celestia、EigenDA等。B^Square、BitLayer以及本文的主角Merlin，都沿用了这种链下的DA扩容方案。

在极客web3此前文章——《解析B^2新版技术路线图：比特币链下DA与验证层的必要性》中，我们提到，B^2直接模仿Celestia，在链下搭建了一个支持数据采样功能的DA网络，名为B^2 Hub。交易数据或state diff等“DA数据”存放于比特币链下，只向比特币主网上传datahash / merkle root 。

这其实是把比特币当做一个去信任的公告板：任何人都可以从比特币链上读取datahash。当你从链下的数据提供者那里获取DA数据后，可以检查它和链上的datahash是否对应，即 hash（data1) == datahash1 ？。如果两者之间存在对应关系，说明链下的数据提供者给你的数据没错。

（DA层存在于比特币链下的Layer2原理图

图源：极客web3）

上述流程可以保证链下节点提供给你的数据，与Layer1上的某些“线索”相关联，防止DA层恶意提供虚假数据。但这里有一个很重要的作恶场景：假如数据的源头——Sequencer，压根没有把datahash对应的data发出去，只把datahash发到了比特币链上，却故意扣住对应的data不让任何人读取，这种时候怎么办？

类似的场景包括但不限于：只把ZK-Proof和StateRoot发布出来，却不发布对应的DA数据（state diff或Transaction data），人们虽然可以验证ZKProof，确定Prev_Stateroot到New_Stateroot的计算过程有效无误，但却不知道有哪些账户的state（状态）发生了变化。这种情况下，虽然用户的资产是安全的，但大家根本不能确定网络的实际状态，不知道有哪些交易被打包上链，哪些合约的状态发生了更新，此时的Layer2基本等同于停机。

这其实就是“数据扣留”，以太坊基金会的Dankrad曾经在2023年8月，于推特上简单讨论了类似的问题，当然他主要针对的是一个名为“DAC”的东西。

很多采用链下DA方案的以太坊Layer2，往往会设置几个具有特殊权限的节点，组成一个委员会，全称Data Availability Committee (DAC) 。这个DAC委员会充当了担保人的角色，对外声称：Sequencer的确在链下发布了完整的DA数据（transaction data或state diff）。然后DAC节点集体生成一个多签，只要多签满足阈值要求（比如2/4），Layer1上的相关合约就会默认，Sequencer通过了DAC委员会的检查，如实的在链下发布了完整的DA数据。

以太坊Layer2的DAC委员会基本都遵循POA模式，只允许少数经过KYC或官方指定的节点加入DAC委员会，这使得DAC成为了“中心化”、“联盟链”的代名词。此外，在某些采用DAC模式的以太坊Layer2那里，排序器只把DA数据发送给DAC成员节点，几乎不会再往其他地方上传数据，任何人要获取DA数据，必须得到DAC委员会的许可，和联盟链没有本质区别。

毫无疑问，DAC应该去中心化，Layer2可以不把DA数据直接上传至Layer1，但DAC委员会的准入权限应该对外开放，这样才能防止少数人串谋作恶。（对于DAC作恶场景的讨论，可以参考Dankrad此前在推特上的发言）

Celestia此前提出的BlobStream，本质是用Celestia替代中心化的DAC，以太坊L2的排序器可以把DA数据发布到Celestia链上，如果有2/3的Celestia节点为之签名，以太坊上部署的Layer2专属合约就认为排序器如实发布了DA数据，这实际是让Celestia节点作为担保人。考虑到Celestia有上百号Validator节点，我们可以认为这个大号DAC是比较去中心化的。

Merlin采用的DA解决方案，其实和Celestia的BlobStream比较接近，都是通过POS的形式开放DAC的准入权限，使之趋于去中心化。任何人只要质押足够的资产，就可以运行一个DAC节点。在Merlin的文档中，将上述DAC节点称为Oracle，并且指出，将支持BTC、MERL甚至是BRC-20代币的资产质押，实现灵活的质押机制，也支持类似于Lido的代理质押。（预言机的POS质押协议基本是Merlin接下来的核心叙事之一，提供的质押利率等都比较高）

在此我们简述下Merlin的工作流程（图片在下面）：

排序器Sequencer接收到大量交易请求后，将其汇总并产生data batch（数据批次），传给Prover节点，以及Oracle节点（去中心化DAC）。

Merlin的Prover节点是去中心化的，采用了lumoz的Prover as a Service服务。Prover矿池在收到多个data batch后，会生成对应的零知识证明，之后，ZKP会发给Oracle节点，交由后者去验证。

Oracle节点会验证Lmuoz的ZK矿池发来的ZK Proof，能否和Sequencer发来的data Batch相对应。若两者可以对应上，且不包含其他错误，则通过验证。在此过程中，去中心化的Oracle节点们会通过门限签名来生成多签，对外声明——排序器完整的发出了DA数据，且对应的ZKP是有效的，通过了Oracle节点的验证。

排序器从Oracle节点处收集多签结果，当签名数量满足阈值要求后，就把这些签名信息发到比特币链上，附带DA数据（data batch）的datahash，交由外界去读取并确认。

（Merlin工作原理图 图源：极客web3）

Oracle节点对其验证ZK Proof的计算过程进行特殊处理，生成Commitment承诺，发送到比特币链上，允许任何人对“承诺”进行挑战，这里面的流程和bitVM的欺诈证明协议基本一致。如果挑战成功，则发布Commitment的Oracle节点将受到经济惩罚。当然，Oracle要发布到比特币链上的数据，还包括当前Layer2状态的hash——StateRoot，以及ZKP本身，都要发布到比特币链上，让外界检测。

参考资料：《极简解读BitVM：如何在BTC链上验证欺诈证明》

这里面还有几个需要阐述的细节，首先Merlin路线图中提到，未来会让Oracle把DA数据备份到Celestia上，这样一来，Oracle节点可以适当的淘汰掉本地的历史数据，不需要把数据永存在本地。同时，Oracle Network生成的Commitment，其实是一棵Merkle Tree的root，光对外披露root还不行，要把Commitment对应的完整数据集全部公开，这就需要寻找一个第三方的DA平台，这个平台可以是Celestia或EigenDA，也可以是其他的DA层。

参考资料：《解析B^2新版技术路线图：比特币链下DA与验证层的必要性》

安全模型分析：乐观的ZKRollup+Cobo的MPC服务

上面我们简述了Merlin的工作流程，相信大家已经对其基本构造有所掌握。我们不难看出，Merlin与B^Square、BitLayer、Citrea，基本都遵循相同的安全模型——乐观的ZK-Rollup。

初读这个词，可能让很多以太坊爱好者感到怪异，什么叫“乐观的ZK-Rollup”？在以太坊社区的认知里，ZK Rollup的“理论模型”完全建立在密码学计算的可靠性上，不需要引入信任假设，而乐观一词，恰恰就引入了信任假设，这意味着，人们在大多数时候，要乐观的认为Rollup没有出现错误，是可靠的。而一旦出现错误，可以通过欺诈证明的方式去惩罚Rollup运行者，这就是乐观Rollup——Optimistic Rollup，又名OP Rollup的命名由来。

对于Rollup大本营的以太坊生态而言，乐观的ZK-Rollup可能有些不伦不类，但这恰恰贴合了比特币Layer2的现状。由于技术上的限制，比特币链上无法完整的验证ZK Proof，只能在特殊情况下验证ZKP的某一步计算过程，在这种前提下，比特币链上实际只能支持欺诈证明协议，人们可以指出ZKP在链下验证过程中，某一个计算步骤有错误，并通过欺诈证明的方式进行挑战，当然这无法向以太坊式的ZK Rollup看齐，但已经是目前比特币Layer2所能企及的最可靠、最稳妥的安全模型。

在上述乐观的ZK-Rollup方案下，假设Layer2网络中存在N个有权限发起挑战的人，只要这N个挑战者中有1人是诚实可靠的，随时能够检测出错误并发起欺诈证明，Layer2的状态转换就是安全的。当然，完成度比较高的乐观Rollup需要确保其提款桥也受到欺诈证明协议的保护，而目前几乎所有的比特币Layer2都无法实现这个前提，需要依赖于多签/MPC，那么该如何选用多签/MPC方案，就成为了与Layer2安全性息息相关的问题。

Merlin在桥接方案上选择了Cobo的MPC服务，采用冷热钱包隔离等措施，桥接资产由Cobo和Merlin Chain共同管理，任何提款行为需要Cobo和Merlin Chain的MPC参与者共同处理，本质上是通过机构的信用背书来保障提款桥的可靠性。当然这只是目前阶段的权宜之计，随着项目的逐渐完善，提款桥可以通过引入BitVM与欺诈证明协议来更替为1/N信任假设的“乐观桥”，只是这样做的落地难度会比较大（目前几乎所有的Layer2官方桥都依赖于多签）。

整体来看，我们可以梳理下，Merlin引入了基于POS的DAC、基于BitVM的乐观ZK-Rollup、基于Cobo的MPC资产托管方案，通过开放DAC权限来解决DA问题；通过引入BitVM及欺诈证明协议来保障状态转换的安全；通过引入知名资产托管平台Cobo的MPC服务来保证提款桥的可靠性。

基于Lumoz的两步验证式ZKP提交方案

前面我们梳理了Merlin的安全模型，介绍了乐观ZK-rollup的概念。在Merlin的技术路线图中，还谈到了去中心化Prover。众所周知，Prover是ZK-Rollup架构中的一个核心角色，它负责为Sequencer发布的Batch生成ZKProof，而零知识证明的生成过程恰恰是非常消耗硬件资源的，是一个很棘手的问题。

要加速ZK证明的生成，将任务并行化切分处理，是一个最基本的操作。所谓的并行化，其实就是把ZK证明的生成任务切分为不同的部分，由不同的Prover来分别完成，最后再由Aggregator聚合者把多段Proof聚合为一个整体。

为了加速ZK证明的生成过程，Merlin将采用Lumoz的Prover as a service方案，实际上就是把大量的硬件设备聚在一起组建出一个矿池，然后把计算任务分配给不同的设备，并分配对应的激励，和POW挖矿有些类似。

在这种去中心化的Prover方案中，存在一类攻击场景，俗称抢跑攻击：假设某个聚合者Aggregator组建好了ZKP，它把ZKP发送出去以期获得奖励。其他聚合者看到了ZKP的内容后，抢跑在他前面发布相同的内容，声称这个ZKP是自己先生成的，这种情况该怎么解决？

可能大家想到的一个最本能的解决方案，就是给每个Aggregator分配指定的任务号码，比如说，任务1只有Aggregator A可以接，其他人就算完成了任务1也拿不到奖励。但这种方法存在一个问题，就是不能抵御单点风险。假如Aggregator A出现了性能故障或是掉线了，任务1就一直卡着没法完成。而且，这种把任务分配给单一实体的做法，无法以竞争性的激励机制提升生产效率，不是一个很好的办法。

Polygon zkEVM曾在一篇博客中提出名为Proof of efficiency的方法，其中指出，应该以竞争性的手段促使不同的Aggregator之间展开竞争，以先到先得的方式来分配激励，最先把ZK-Proof提交上链的Aggregator可以获得奖励。当然他这里面没有提到该怎么解决MEV抢跑问题。

Lumoz采用了两步验证的ZK证明提交方式，某个Aggregator生成了ZK证明后，先不用把完整的内容发出去，而只发布ZKP的hash，换言之，发布hash（ZKP+Aggregator Address）。这样一来，就算其他人看到了hash值，也不知道对应的ZKP内容，无法直接抢跑；

如果有人干脆把整个hash复制一份抢先发布出去，也没有意义，因为hash里面包含了特定聚合者X的地址，聚合者A就算抢先发布这个hash，等hash的原像被揭露时，大家也会看到其中包含的聚合者地址是X的，而不是A的。

通过这种两步验证式的ZKP提交方案，Merlin（Lumoz）可以解决ZKP提交过程中存在的抢跑问题，进而实现高度竞争性的零知识证明生成激励，从而提高ZKP的生成速度。

Merlin's Phantom：多链互操作

按照Merlin的技术路线图，他们还会支持Merlin与其他EVM链之间的互操作，其实现路径与此前Zetachain的思路基本一致，假如以Merlin作为源链，其他EVM链作为目标链，当Merlin节点感知到用户发出的跨链互操作请求后，会在目标链上触发后续的工作流程。

比如，可以在Polygon上部署一个由Merlin网络控制的EOA账户，当用户在Merlin Chain上发布跨链互操作指令后，Merlin网络先解析其内容，生成一笔在目标链上执行的交易数据，再由Oracle Network对该笔交易进行MPC签名处理，生成交易的数字签名。之后Merlin的Relayer节点在Polygon上释放这笔交易，通过Merlin在目标链上EOA账户中的资产完成后续操作如。

当用户要求的操作完成后，对应的资产将直接转发给用户在目标链上的地址，理论上也可以直接跨到Merlin Chain中。这种方案有一些比较明显的好处：可以避免传统资产跨链时与跨链桥合约产生的手续费磨损，而且是直接由Merlin的Oracle Network保障跨链操作的安全性，不需要再依赖于外部的基础设施。只要用户信任Merlin Chain，就可以默认此类跨链互操作行为是没有问题的。

总结

在本文中，我们对Merlin Chain大体的技术方案进行了简要解读，相信可以让更多人理解Merlin的大致工作流程，对其安全模型有更清晰的认知。考虑到当前比特币生态的如火如荼，我们认为，此类技术科普行为是有价值且为广大群众所需要的，我们将在日后对Merlin及bitLayer、B^Square等项目进行长期的跟进，对其技术方案进行更为深入的解析，大家敬请期待！