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

从 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 基本等同于停机。

很多采用链下 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 是比较去中心化的。