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 ？。如果两者之间存在对应关系，说明链下的数据提供者给你的数据没错。

上述流程可以保证链下节点提供给你的数据，与 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，交由外界去读取并确认。

• 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 等项目进行长期的跟进，对其技术方案进行更为深入的解析，大家敬请期待！