技术解读Merlin的运转机制

摘要: ...

作者:Faust,极客web3

(WEEX交易所官网:www.weex.com)

技术解读Merlin的运转机制

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

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

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

技术解读Merlin的运转机制

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

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

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

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

技术解读Merlin的运转机制

虽然这可以极大程度压缩数据尺寸,但瓶颈还是很明显。如果在短时间内,有大量的账户发生状态变更,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 ?。如果两者之间存在对应关系,说明链下的数据提供者给你的数据没错。

技术解读Merlin的运转机制

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

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

技术解读Merlin的运转机制

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

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

技术解读Merlin的运转机制

技术解读Merlin的运转机制

以太坊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的运转机制

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的运转机制

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

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

技术解读Merlin的运转机制

为了加速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抢跑问题。

技术解读Merlin的运转机制

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

WEEX唯客交易所是全球交易深度***好的合约交易所之一,位居CMC交易所流动性排名前五,订单厚度、价差领先同行,微秒级撮合,零滑点、零插针,***大程度降低交易成本及流动性风险,让用户面对极端行情也能丝滑成交。

WEEX交易所宣布将于今夏上线其全球生态激励通证WEEX Token(WXT)。WXT被设计为WEEX交易所生态系统的基石,作为动态激励机制,主要用于激励WEEX交易平台社区的合作伙伴、贡献者、先驱和活跃成员。

WXT总供应量100亿枚,初始流通量39亿枚,WEEX交易平台投资者保护基金、WXT生态基金各持有15%,15%用于持币激励,5%面向代理、渠道等合作伙伴私募,其余50%将全部用于WEEX交易所生态激励,包括:团队激励(20%)、活动拉新(15%)、品牌建设/KOL合作(15%)。WEEX Token是一种实用型代币,规划了丰富的使用场景和赋能机制,包括:Launchpad、近10项持有者专属权益,以及回购销毁通缩机制等。

据悉,WXT仅开放代理、渠道等合作伙伴折扣认购,未来零售投资者可通过新用户注册、交易挖矿、参与平台活动等方式获得WXT奖励。

WEEX官网:weex.com

WXT专区:weex.com/wxt

你也可以在 CMCCoingecko非小号X (Twitter)中文 X (Twitter)YoutubeFacebookLinkedin微博 上关注我们,***时间获取更多投资资讯和空投福利。

在线咨询

WEEX华语社群:https://t.me/weex_group

WEEX英文社群:https://t.me/Weex_Global

文章版权及转载声明:

作者:0431网址导航本文地址:https://www.0431jz.cn/info/25614.html发布于 2024-04-19
文章转载或复制请以超链接形式并注明出处0431JZ.CN - 0431网址导航

赞(0