以太坊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接下来的核心叙事之一，提供的质押利率等都比较高）
Oracle节点对其验证ZKProof的计算过程进行特殊处理，生成Commitment承诺，发送到比特币链上，允许任何人对承诺进行挑战，这里面的流程和bitVM的欺诈证明协议基本一致。如果挑战成功，则发布Commitment的Oracle节点将受到经济惩罚。当然，Oracle要发布到比特币链上的数据，还包括当前Layer2状态的hashStateRoot，以及ZKP本身，都要发布到比特币链上，让外界检测。
这里面还有几个需要阐述的细节，首先Merlin路线图中提到，未来会让Oracle把DA数据备份到Celestia上，这样一来，Oracle节点可以适当的淘汰掉本地的历史数据，不需要把数据永存在本地。同时，OracleNetwork生成的Commitment，其实是一棵MerkleTree的root，光对外披露root还不行，要把Commitment对应的完整数据集全部公开，这就需要寻找一个第三方的DA平台，这个平台可以是Celestia或EigenDA，也可以是其他的DA层。
上面我们简述了Merlin的工作流程，相信大家已经对其基本构造有所掌握。我们不难看出，Merlin与B^Square、BitLayer、Citrea，基本都遵循相同的安全模型乐观的ZK-Rollup。
初读这个词，可能让很多以太坊爱好者感到怪异，什么叫乐观的ZK-Rollup？在以太坊社区的认知里，ZKRollup的理论模型完全建立在密码学计算的可靠性上，不需要引入信任假设，而乐观一词，恰恰就引入了信任假设，这意味着，人们在大多数时候，要乐观的认为Rollup没有出现错误，是可靠的。而一旦出现错误，可以通过欺诈证明的方式去惩罚Rollup运行者，这就是乐观RollupOptimisticRollup，又名OPRollup的命名由来。
对于Rollup大本营的以太坊生态而言，乐观的ZK-Rollup可能有些不伦不类，但这恰恰贴合了比特币Layer2的现状。由于技术上的限制，比特币链上无法完整的验证ZKProof，只能在特殊情况下验证ZKP的某一步计算过程，在这种前提下，比特币链上实际只能支持欺诈证明协议，人们可以指出ZKP在链下验证过程中，某一个计算步骤有错误，并通过欺诈证明的方式进行挑战，当然这无法向以太坊式的ZKRollup看齐，但已经是目前比特币Layer2所能企及的最可靠、最稳妥的安全模型。
在上述乐观的ZK-Rollup方案下，假设Layer2网络中存在N个有权限发起挑战的人，只要这N个挑战者中有1人是诚实可靠的，随时能够检测出错误并发起欺诈证明，Layer2的状态转换就是安全的。当然，完成度比较高的乐观Rollup需要确保其提款桥也受到欺诈证明协议的保护，而目前几乎所有的比特币Layer2都无法实现这个前提，需要依赖于多签/MPC，那么该如何选用多签/MPC方案，就成为了与Layer2安全性息息相关的问题。
Merlin在桥接方案上选择了Cobo的MPC服务，采用冷热钱包隔离等措施，桥接资产由Cobo和MerlinChain共同管理，任何提款行为需要Cobo和MerlinChain的MPC参与者共同处理，本质上是通过机构的信用背书来保障提款桥的可靠性。当然这只是目前阶段的权宜之计，随着项目的逐渐完善，提款桥可以通过引入BitVM与欺诈证明协议来更替为1/N信任假设的乐观桥，只是这样做的落地难度会比较大（目前几乎所有的Layer2官方桥都依赖于多签）。
整体来看，我们可以梳理下，Merlin引入了基于POS的DAC、基于BitVM的乐观ZK-Rollup、基于Cobo的MPC资产托管方案，通过开放DAC权限来解决DA问题；通过引入BitVM及欺诈证明协议来保障状态转换的安全；通过引入知名资产托管平台Cobo的MPC服务来保证提款桥的可靠性。
前面我们梳理了Merlin的安全模型，介绍了乐观ZK-rollup的概念。在Merlin的技术路线图中，还谈到了去中心化Prover。众所周知，Prover是ZK-Rollup架构中的一个核心角色，它负责为Sequencer发布的Batch生成ZKProof，而零知识证明的生成过程恰恰是非常消耗硬件资源的，是一个很棘手的问题。
要加速ZK证明的生成，将任务并行化切分处理，是一个最基本的操作。所谓的并行化，其实就是把ZK证明的生成任务切分为不同的部分，由不同的Prover来分别完成，最后再由Aggregator聚合者把多段Proof聚合为一个整体。
为了加速ZK证明的生成过程，Merlin将采用Lumoz的Proverasaservice方案，实际上就是把大量的硬件设备聚在一起组建出一个矿池，然后把计算任务分配给不同的设备，并分配对应的激励，和POW挖矿有些类似。
在这种去中心化的Prover方案中，存在一类攻击场景，俗称抢跑攻击：假设某个聚合者Aggregator组建好了ZKP，它把ZKP发送出去以期获得奖励。其他聚合者看到了ZKP的内容后，抢跑在他前面发布相同的内容，声称这个ZKP是自己先生成的，这种情况该怎么解决？
可能大家想到的一个最本能的解决方案，就是给每个Aggregator分配指定的任务号码，比如说，任务1只有AggregatorA可以接，其他人就算完成了任务1也拿不到奖励。但这种方法存在一个问题，就是不能抵御单点风险。假如AggregatorA出现了性能故障或是掉线了，任务1就一直卡着没法完成。而且，这种把任务分配给单一实体的做法，无法以竞争性的激励机制提升生产效率，不是一个很好的办法。
PolygonzkEVM曾在一篇博客中提出名为Proofofefficiency的方法，其中指出，应该以竞争性的手段促使不同的Aggregator之间展开竞争，以先到先得的方式来分配激励，最先把ZK-Proof提交上链的Aggregator可以获得奖励。当然他这里面没有提到该怎么解决MEV抢跑问题。
Lumoz采用了两步验证的ZK证明提交方式，某个Aggregator生成了ZK证明后，先不用把完整的内容发出去，而只发布ZKP的hash，换言之，发布hash（ZKP+AggregatorAddress）。这样一来，就算其他人看到了hash值，也不知道对应的ZKP内容，无法直接抢跑；
如果有人干脆把整个hash复制一份抢先发布出去，也没有意义，因为hash里面包含了特定聚合者X的地址，聚合者A就算抢先发布这个hash，等hash的原像被揭露时，大家也会看到其中包含的聚合者地址是X的，而不是A的。
以上就是Merlin币是什么？Merlin(梅林链)怎么运行的？Merlin币空投教程的全部内容，望能这篇Merlin币是什么？Merlin(梅林链)怎么运行的？Merlin币空投教程可以帮助您解决问题，能够解决大家的实际问题是非常好学习网一直努力的方向和目标。