技术解读：Merlin Chain是如何运转的？

原文作者：Faust，极客web3

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

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

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

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

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

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

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

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

很多比特币 Layer 2 干脆走第二种路径：直接用比特币链下的 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（data 1) == datahash 1 ？。如果两者之间存在对应关系，说明链下的数据提供者给你的数据没错。

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