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的工作流程（图片在下面）：

1. 排序器Sequencer接收到大量交易请求后，将其汇总并产生data batch（数据批次），传给Prover节点，以及Oracle节点（去中心化DAC）。
2. Merlin的Prover节点是去中心化的，采用了lumoz的Prover as a Service服务。Prover矿池在收到多个data batch后，会生成对应的零知识证明，之后，ZKP会发给Oracle节点，交由后者去验证。
3. Oracle节点会验证Lmuoz的ZK矿池发来的ZK Proof，能否和Sequencer发来的data Batch相对应。若两者可以对应上，且不包含其他错误，则通过验证。在此过程中，去中心化的Oracle节点们会通过门限签名来生成多签，对外声明——排序器完整的发出了DA数据，且对应的ZKP是有效的，通过了Oracle节点的验证。
4. 排序器从Oracle节点处收集多签结果，当签名数量满足阈值要求后，就把这些签名信息发到比特币链上，附带DA数据（data batch）的datahash，交由外界去读取并确认。

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

1. Oracle节点对其验证ZK Proof的计算过程进行特殊处理，生成Commitment