本文作者聚焦于@MerlinLayer2技术方案，对其已公开的文档及协议设计思路进行解读，致力于让更多人理解Merlin的工作流程，对其安全模型有更清晰的认知 让大家以直观的方式理解这个“头部比特币Layer2”到底是怎么运转的
对于Layer2而言，DA与数据发布成本，是最需要解决的问题之一。比特币网络天生不支持较大的数据吞吐量，如何利用寸土寸金的DA空间，成为了考验Layer2项目方的难题 一个结论是显而易见的：最主流的DA解决方案，要么把数据尺寸压缩的尽可能小，再上传到比特币区块，要么就把数据直接发布在链下
采用第一种思路的Layer2中，最出名的可能是Citrea，它们把一段时间内Layer2的状态变化(state diff)，也就是多个账户上的状态变更结果，连同对应的ZK证明，一起上传到比特币链上 任何人都可以从比特币主网下载state diff 和ZKP，监测到Citrea状态的变化结果。这可以把上链的数据尺寸压缩90%以上
虽然这可以极大程度压缩数据尺寸，但瓶颈还是很明显。如果有大量账户发生状态变更，Layer2要把变更情况全部汇总上传到比特币链上，成本压不到太低，这在很多以太坊ZK Rollup身上可见一斑 很多比特币Layer2干脆走第二种路径：直接用比特币链下的DA解决方案，要么自己搭建一个DA层，要么就用Celestia等
B^Square、BitLayer以及Merlin，都沿用了链下的DA扩容方案 在极客web3此前文章中，我们提到，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数据 DAC节点会生成多签，只要满足阈值要求（如2/4），Layer1相关合约就默认，Sequencer通过了DAC检查，在链下发布了DA数据
以太坊Layer2的DAC委员会基本都遵循POA模式，只允许官方指定的节点加入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代币的资产质押实现灵活的质押机制
我们简述下Merlin的工作流程（图片在下面）： 1. 排序器接收到大量交易请求后，将其汇总并产生data batch（数据批次），传给Prover节点，以及Oracle节点（去中心化DAC） Merlin的Prover节点是去中心化的，采用了lumoz的Prover as a Service服务
2. Prover矿池收到多个data batch后，生成对应的零知识证明，之后，ZKP会发给Oracle节点，交由后者去验证 Oracle节点会验证Lmuoz的ZK矿池发来的ZK Proof，能否和Sequencer发来的data Batch相对应。若两者可以对应上，且不包含其他错误，则通过验证
3.去中心化的Oracle节点们会通过门限签名来生成多签，对外声明——排序器完整的发出了DA数据，且对应的ZKP是有效的，通过了Oracle节点的验证 排序器从Oracle节点处收集多签结果，当签名数量满足阈值要求后，就把这些签名信息发到比特币链上，附带DA数据（data batch）的datahash，交由外界去读取并确认
4. 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与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共同管理，通过机构的信用背书来保障提款桥的可靠性 随着项目的完善，提款桥可以引入BitVM与欺诈证明协议来更替为1/N信任假设的“乐观桥”（目前几乎所有的Layer2官方桥都依赖于多签）
整体来看，我们可以梳理下： Merlin引入了基于POS的DAC、基于BitVM的乐观ZK-Rollup、基于Cobo的MPC资产托管方案，通过开放DAC权限来解决DA问题； 通过引入BitVM及欺诈证明协议来保障状态转换的安全； 通过引入知名资产托管平台Cobo的MPC服务来保证提款桥的可靠性。
基于Lumoz的两步验证式ZKP提交方案 在Merlin的技术路线图中，还谈到了去中心化Prover 众所周知，Prover是ZK-Rollup架构中的一个核心角色，它负责为Sequencer发布的Batch生成ZKProof，而零知识证明的生成过程恰恰是非常消耗硬件资源的，是一个很棘手的问题
要加速ZK证明的生成，将任务并行化切分处理，是一个最基本的操作 所谓的并行化，其实就是把ZK证明的生成任务切分为不同的部分，由不同的Prover来分别完成，最后再由Aggregator聚合者把多段Proof聚合为一个整体
为了加速ZK证明的生成过程，Merlin将采用Lumoz的Prover as a service方案，实际上就是把大量的硬件设备聚在一起组建出一个矿池，然后把计算任务分配给不同的设备，并分配对应的激励，和POW挖矿有些类似 在这种去中心化的Prover方案中，存在一类攻击场景，俗称抢跑攻击：
某个聚合者组建好了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生成速度。
+ There are no comments
Add yours