YBB Capital：疯狂的多链宇宙，疯狂的OP Stack

原文作者：YBB Capital Researcher Ac-Core

前言

ETH 的主体叙事方向已由 Layer 1 转向了 Layer 2 ，如果还将其理解为“一键发币”的 ERC-20 叙事，我们不妨放大格局展开想象，一场属于 “一键发链” 的疯狂即将到来！ 依托目前无人能及的生态和居高不下的 TVL, Arbitrum 一直引领着 Layer 2 之间的战争，但这暂时的胜利能持续很久吗？与 Arbitrum Orbit 再上一层的 Layer 3 方案不同，OP Stack 是能够一键创建 Layer 2 的 “超级链”。本篇内容以 OP Stack 架构、OP 里的 ZK 元素、Rollup 的安全性问题三部分进行全面解析。

OP Stack 开启“超级链宇宙”

YBB Capital Researcher Ac-Core 自制

下轮牛市的叙事从哪开始？是从高性能的 Layer 1 ，继续堆高的 Layer 3 ，ZK 系的 Layer 2 ，还是 OP Stack 的超级链？这是一个非常有趣且值得深思的问题。以太杀手这个称号仍然是万众公链不可逾越的究极目标，而在这个庞大的巨人里还暗藏着很多不可忽视的超级内核，其中一个便是：OP Stack。

什么是 OP Stack？

OP Stack 可理解为一组开源的软件组件，使任何人都可以使用 Optimistic rollups 在以太坊之上构建自己的 Layer 2 区块链。它将大部分计算和存储移至链外，同时依赖以太坊来确保安全性和最终性，从技术层面来讲，Optimism 主要体现在它切实地为用户节省了大量链上费用。OP Stack 由四个主要组件组成：

• 主网：OP Mainnet 是一个廉价且快速的以太坊 Layer 2 网络，与以太坊虚拟机 EVM相兼容；

• 合约：实现 OP Stack 核心逻辑和功能的智能合约。OP 合约包括状态转换系统（STS）、欺诈证明者 (FP)、状态承诺链（SCC）以及规范交易链（CTC）；

• 服务：提供 Layer 1 和 Layer 2 之间的数据可用性、数据同步和通信服务；

• 工具：促进基于 OP Stack 的区块链的开发、测试、部署、监控和调试。

超强的开放性：

OP Stack 将被打造为可分叉模块化扩展区块链的基础设施，为实现这一远景需将各类 Layer 2 整合成一个单一的超级链（Superchain），把原本相互孤立的 Layer 2 集成到一个具备互操作性和组合性的系统中，启动 Layer 2 就像今天将智能合约部署到以太坊一样简单，让叙事变化由“一键发币”走向“一键发链”。本质上而言，超级链是一个可横向扩展的区块链网络，与各链之间共享以太坊的安全性、通信层以及开发套件。

YBB Capital Researcher Ac-Core 自制

OP Stack （Over Powered Stack）将成为超级链背后统一的模块化开发堆栈，且它们之间是无数可相互链接、可通信的区块链。OP Stack 堆栈由专门的 Optimism Collective 负责整体的开发和维护，并支持用于部署新汇总网络的共享开源系统。与此同时它也是一套标准化的开源模块。这样一听它岂不是一个完全基于以太坊安全性的 Cosmos！当初说好的 ETH 与 ATOM 两者互补，现在却让 OP Stack 成为了 Cosmos 杀手？接下来让我们把 OP Stack 的定义给拆解一下：

模块是任何开发人员可以插入 OP Stack 的数据位。而这套超级链的"标准化" 意味着对一个模块的标准有共识，并且它可以被所有人实现。同时完全开源意味着它可以免费提供给任何人进行开发迭代和消息请求。开发人员有能力在一个链的不同执行层、共识层、结算层和数据可用性层进行切换模块。

好比 dYdX 选择离开以太坊转向 Cosmos 应用链，其根本原因是他们希望自己链上的共识层有更大的模块化，我认为这是一个很好的开始，让更多独立的 Dapps 选择更符合自身的公链进行开发，其中最具有代表性的是 Luna，虽然出于一些原因它被毁灭了。值得庆幸的是 OP Stack 解决了这个问题，它的设计可以用更容易的方式进行代码分叉，让开发人员可以很容易地抽象出区块链的不同组成部分，并通过插入不同的模块来修改它。

OP Stack 设计原则：

• 效能：可以使用 OP Stack 构建任何东西并一键发行区块链；

• 简洁：利用可复用的代码和现成开发套件，以增强安全性和降低维护的复杂性，达到整体降低门槛的作用；

• 可扩展：Optimism Collective 将会完整开源 OP Stack 的主要代码。

在架构上，OP Stack 可自下而上分为六层，分别是 DA Layer 数据可用层、Sequencing Layer 排序层、Derivation Layer 衍生层、Execution Layer 执行层、Settlement Layer 结算层、Governance Layer 治理层。OP Stack 的每一层都是模块化的 API 组建，可以随意进行组合和解耦。其中最为关键的是 DA 数据可用层、执行层和结算层，三者构成了 OP Stack 的主要工作流程。

• DA 数据可用性层：是 OP Stack 的原始数据来源，可使用单个或多个数据可用性模块来获取输入数据，目前以太坊是最主要的 DA 层，但未来也会有更多的链加入进来；

• 执行层：OP Stack 中的状态结构，可为 EVM 或其他 VM 提供可能性，增加了在以太坊上发起的 Layer 2 交易的支持，同时为每笔交易增加额外的 Layer 1 数据费用，向以太坊发布交易的综合成本。

• 结算层：OP Stack 上 Layer 2 交易数据的去处，在 Layer 2 确认后将信息发送到目标区块链，以此最终结算。未来也有望接入 ZK 等有效性证明机制，以打通不同链之间的隔阂，甚至可以链接 OP 系 Layer 2 和 ZK 系 Layer 2 之间的孤岛。

我们观察到近期 OP 生态发展出了一些带有 ZK 元素的项目，不妨大胆想象一下，如某个 Optimistic rollup 想把自己改造成 ZK rollup，没问题！只要把它的欺诈证明模块换成结算层的有效性证明模块即可。如果某条链想把 Celestia 用于其数据可用性层。没问题！把以太坊换成 Celestia 就行。想把执行层的 EVM 换成另一种虚拟机，可惜的是这只能是 OP Stack 的一个技术可能性。正如这种超级链局面的出现而诞生出一个热梗——“Polygon：我要做 ZK Layer 2 的 Cosmos！Optimism：我要做 OP Layer 2 的 Cosmos! Cosmos：那我是谁？”

OP Stack 法则：

YBB Capital Researcher Ac-Core 自制

以太坊的无限区块空间是实现大规模应用的关键一步，但这种扩散也带来了分裂，无权限部署也迎来了新挑战，如今，每个新的 OP Stack 链都在自己的领域中独立生长，没有分享标准和改进的直接方法。用户和建设者也面临着巨大的挑战：根据安全性、质量和中立性对众多不同的链进行单独评估。为了实现超级链，需将 OP Stack 从独立、分散的区块空间转变为一个统一的链集体，共同致力于开放、去中心化的区块空间。“链法则”为乐观主义治理和超级链制定了指导原则。乐观主义治理从管理单个链转变为管理多个链共享的标准，从而定义了成为超级链一部分所需的属性，同时优先保护用户在超级链上进行交易。从根本上讲，“链法则”是一份社会契约（而非法律契约），因此积极的社区讨论至关重要。它的存在将使超级链能够保证以下特性：

• 确保区块空间保持同质、中立和开放： 对链法的承诺就是对保护链的用户、开发者和其他利益相关者的承诺。无论大小的链，如果是超级链的一部分，都可以在乐观主义治理的支持下，可信地证明其区块空间的同质性、中立性和开放性；

• 受益于不断改进： 共享升级意味着超级链可以始终获得最好的技术，而无需自己操心维护；

• 提供更好更可用的基础设施： 由于超级链中的所有链都可信地致力于一个标准，因此它们可以共同努力，确保索引和排序等关键服务的可用性和经济性。

值得思考的问题：

OP Stack 能否反哺 OP？

OP Token 到底有什么用途，如果以 Basechain 的方式，他们会把一部分收入反哺给到 Optimism Collective，那么“国库”的收入来源会依托自身的“价值”，依靠创造更多的叙事来最终反馈到币价上，使得 OP 在二级市场的表现逻辑与 ATOM 类似，但这种方案或许是目前最优的，如有更多的链条效仿 Basechain 的方式进行反哺，Optimism Collective 终将受益。这种感觉是否让我们想到 UNI？两者项目本身都具有雄厚实力但 Token 自身除了投票和治理外并没有其他价值用途。与此不同的是，目前 Layer 2 都面临着中心化排序器问题，即使 Layer 2 代币仅用于某种形式的领导者选择（而非共识投票），但排序权的价值仍会累积到 Rullop 代币上。

与此同时 OP 团队在 7 月 25 日的时候发布了 Law of Chain 提案，所有采用 OP Stack 的链启动共享治理模型和排序器，希望将“利润反哺”这个模式进行规范化，从而为整个 OP 系带来更多收益（如上述 OP Stack 法则），这相比于 Cosmos 的共享安全模型，堪称异曲同工之妙。

OP Stack 和 ZK Stack 的区别：

OP Stack：多链单选择

通过上文我们不难发现 OP Stack 采用的与 Cosmos 相似的多链模式，但选择方面只有一个，因为 OP Stack 追求各个链都需验证其他链的交易，否则就需要在 Layer 1 上等待数天才会有结果，所以单一且共享的排序器，集中式的 MEV 分配以及受法约与管理的保护是唯一让 Optimistic rollups 在不同链之间实现无缝互操作性的可能。

ZK Stack：多链多选择

与 OP Stack 不同的是，ZK Stack 同样可以多个链，但它可有多种选择，可选自己的排序器，按自己方式去处理 MEV，且受数学和代码的保护（注意：OP Stack 是受法约与管理的保护）。这是因为如果 ZK 采用指定共享或极少量的线程集，那它们彼此之间单依数学即可盲目的信任，使零知识证明失去价值。

OP Stack 里的 ZK 元素

YBB Capital Researcher Ac-Core 自制

OP Stack 是一套完全开放的架构，会让生态里出现 zkvm、zkmips、zkwasm、zkevm 成为可能，但相比于 “ 正统的 ZK ” ，OP Stack 里也产生了一些不一样的 ZK 元素。这让我们情不自禁地联想到，也许在不久的将来能出现一次 OP rollup 与 ZK rollup 的梦幻联动。

为 OP 实现零知识证明（ZKP）：

根据最新的进展，Mina 的背后团队计划采用他们自己的 plonk 系统 + kzg 承诺 + folding 算法 nova 来实现 OP Stack 上的 zkmips vm 。虽然这仅是一个最新提案会存在较多不成熟的地方，但这也是非常值得我们去探索的。该项目团队的使命是让 Layer 2 与 Layer 1 及 OP 各个链之间通过零知识证明来实现安全低延迟的跨链通信。这是一个针对良好支持的指令集架构（ISA）的零知识证明（ZKP），它可以证明 Optimism 容错程序的行为，为能够证明任何基于 OP Stack 的区块链系统奠定了基础。

YBB Capital Researcher Ac-Core 自制

完成这项任务意味着需要实现一个零知识证明（ZKP）系统，该系统可以使用 golang 编译器（如 MIPS、RISC-V 或 WASM）支持的指令集架构（ISA）来证明 OP 防错程序 [ 2 ] 。此外，该证明系统还必须证明标准配置 OP Stack 链的两个区块之间状态转换，从而证明其在实践中是可行的。除了证明 ISA 的标准执行轨迹外，对防错程序的支持还引入了额外的要求[ 1 ] 。

具体来说，防错程序引入了 Pre-image Oracle [ 3 ] 的概念，它使用特殊的 System call [ 4 ] 将外部数据加载到程序中。每个 Fault Proof VM [ 5 ] 都负责实现某种机制，通过这种机制，某些数据的哈希值被放置在内存中的特定位置，且被系统调用被执行，然后该哈希值的预映像被加载到内存中供程序使用。Pre-image Oracle 也用于引导程序的初始输入。

去中心化排序器的尝试：

Espresso Systems 于 2023 年 7 月 21 日发推文官宣关于构建 OP Stack 领导选举的去中心化排序验证的提案已被接受，并成为 OP Stack 和 Superchain 的贡献者。其中该项目的主要协议 HotShot 是一种高速的共识协议，可使用重新抵押来使以太坊验证者能够参与该协议，旨在达到与以太坊验证器集相同的规模。同时该项目还开发了 Espresso Sequencer ，这与功能齐全的 Zk-rollup 实现了集成，特别是 Polygon zkEVM 的分支。

什么是领导选举？

领导选举[ 6 ]是指在分布式系统中使用不同的领导者负责创建下一个规范状态转换的能力。在区块链中，领袖选举可以让不同的区块生产者在不同的时间产生区块，同时领导选举算法可以是竞争性的也可以是无竞争性的。

在工作量证明情况下，竞争性领导选举算法是指在同一时间内有许多潜在的单位争相成为领导者。无竞争领导者选举算法是指在某一特定时间点只有一个已知的领导者，在以太坊 Gasper 的情况下，无竞争性领导选举算法是指在特定时间点只有一个已知的单位，并没有其他方式让另一个潜在单位在那个时间成为领导者。

在将提议者网络和构建者网络分离的情况下（即区块构建者网络只负责选择交易排序，提议者网络只负责签署区块），会将原本负责在某一时刻产生区块的单一实体转变为许多可能存在的实体，且让它们在竞争这某一时刻内构建者网络中最具盈利的潜力区块，与此同时由于 MEV 的存在，会导致这种竞争性再次回归。

我们在理解不同的 OP Stack 链之间领导选举机制的各种二阶效应是非常困难的。就目前而言，把领导选举作为一种机制是最受欢迎的，因为它可以让排序更加的去中心化。需注意的是这种方案也无法保障排序器是绝对去中心化，所以在考虑去中心化排序器问题时要额外的小心谨慎。

Rollup 们真的安全嘛？

以太坊的工作原理：

以太坊的原理是，每个节点都存储且执行用户提交给它的每笔交易，这种高级别的安全方式也导致整个网络十分昂贵，所以需要为整个网络扩容而采取了 Rollup 解决方案。简单来说 Rollup = Layer 1 的一组合约 + Layer 2 的自身网络节点，即链上智能合约 + 链下聚合器，将结算，共识，数据可用性均依赖以太坊，自己仅负责执行 Rollup。

• 链上智能合约，表示了它的信任模型就是以太坊上的一个智能合约，借用了以太坊的安全性；

• 链下聚合器，表示它会链下执行并聚合交易，将大批量的交易进行压缩，并最终放上以太坊主网，达成更快且更便宜的目的。

Layer 2 网络节点又有很多部分组成，其中排序器（Sequencer）组件最为重要。它负责接收 Layer 2 上的交易请求，以此决定他们的执行次序并将交易序列进行打包批次（Batch），最终传送给 Rollup 项目在 Layer 1 上的合约。需要注意的是在开始下文前需明确一个事实：如下图参考，目前以太坊所有 Layer 2 Rollups 的排序器都是中心化的。

图源：官方推文截图

中心化的排序器问题：

Layer 2 的全节点可以通过两种方式获得交易序列：一是直接从排序器获取，二是读取排序器发送到 Layer 1 的交易批次（Batch）但后者拥有更强的不可修改属性。由于交易执行会改变区块链账本的状态，为确保一致性，Layer 2 全节点除了需要获得交易次序，还必须与排序器同步账本状态。因此，排序器的任务不仅是将交易批次发送到 Layer 1 的 Rollup 合约，还要将交易执行后的状态更新结果 StateRoot/StateDiff 传送至 Layer 1 ，通俗来讲排序器的工作是将交易处理和排序为添加到区块链中的块，负责批量处理交易并将其发布到 Layer 1 智能合约。

对于 Layer 2 的全节点来说，只要获取了 Layer 1 上 Rollup 的交易序列和最初的 StateRoot，就能够还原出 Layer 2 的区块链账本，并计算得出最新的 StateRoot。反之，Layer 2 全节点自己计算得到的 StateRoot 与排序器发布到 Layer 1 的 StateRoot 不一致，就意味着排序器存在欺诈行为。综上相比 Layer 2 自身的网络，Layer 1 会更加去中心化、去信任（Trustless）和更安全。

YBB Capital Researcher Ac-Core 自制

OP Stack:

那么问题来了，Layer 2 可不可以伪造一些不存在或是一些错误的交易，好比将 Layer 2 的 Token 资产转移到排序器的运行者地址，再将这些 Token 资产转移到 Layer 1 上，从而盗取用户资产？答案是：如果想这样做完全是可以的。所以在面对排序器可能存在的欺诈风险时，不同类型的 Rollup 采用了不同方式的应对措施。

我们拿 Optimistic Rollup 举例，它允许 Layer 2 全节点提供欺诈证明（Fraud Proof），证明排序器在 Layer 1 发布的数据是错误的。但对于没有欺诈证明的 Optimism 来说，如果它真想通过排序器来盗走 Layer 2 的用户资产，只需让排序器运行者伪造交易指令，并将其他人在 Layer 2 的资产转移至自己的地址，最后通过 Rollup 自带的 Bridge 合约，来把盗来的币转移至 Layer 1 。

为解决这种可能存在的问题，目前解决方案一是靠社区成员和社交媒体等舆论监督达成所谓的“共识”，二是依靠 OP 做为官方的信用背书。所以综上理论，OP Rollup 的安全性至少依靠要有一个能发布欺诈证明的诚实 Layer 2 全节点来保证，既上文“OP Stack 和 ZK Stack 的区别”小节中提到的：OP Stack 是多链单选择。

YBB Capital Researcher Ac-Core 自制

ZK Stack：

下面我们来探讨一下 ZK Stack，在 ZK rollup 网络中，存在着 Prover 节点，它专门负责为排序器发布交易批次，同时生成有效性证明。这些有效性证明在 Layer 1 上有专门的验证合约。只要交易批次及其对应的 StateRoot/StateDiff 的证明通过 Verifier 合约验证，交易便得到最终确认。它与 OP Stack 有所不同的是，ZK rollup 在解决排序器欺诈问题时除了依赖 Layer 2 全节点外，还利用了 Validity Proof（有效性证明）。ZK rollup 的官方桥梁也只会允许通过有效性证明验证的提款交易执行，从安全性方面来看，这显然比 Optimism 要可靠得多，即上文中“OP Stack 和 ZK Stack 的区别”小节中提出的：ZK Stack 是多链多选择。

从理论来考虑，ZK rollup 的安全由 Layer 1 上的 Verifier 合约保证或可以说是由 Layer 1 节点完成交易最终确认。与 OP rollup 的安全性靠最少单个能发布欺诈证明的诚实 Layer 2 全节点相对比，他们都是继承了 Layer 1(ETH)的安全性，但事实或许严格意义来讲并非如此，不过这已是目前最优解决方案，相比于其他公链，以太坊经历这么多年的发展历程，安全性毋庸置疑是最值得信赖的。

如同区块链三角问题，一个“产品”的综合用户体验似乎也存在着一个三角问题：安全，简单，高效。ZK Stack 相比 OP Stack，它更加相信依靠数学和代码来提升整体的安全性质，因此大幅提升了整体的复杂性。所以关于 ZK 也存在几点老生常谈的话题：

YBB Capital Researcher Ac-Core 自制

• 延迟问题：ZK rollup 还需要解决 Layer 2 节点向 Layer 1 发布数据的延迟问题。类似于快递运输需要准备包装盒一样，所以每次排序器或 Prover 向 Layer 1 发送数据都会产生固定的成本；

• 速度问题：ZK rollup 面临着一个挑战，即生成有效性证明的速度较慢。尽管排序器可以在 1 秒内执行数千笔交易，但为这些交易生成有效性证明可能需要几个小时的时间；

• 成本问题：为了降低整体成本，很多 ZK rollup 方案采取了“聚合多个 Proof，再一次性发到 Layer 1 上”的策略。这意味着 Prover 不会立即在生成一个 Proof 后就发送到 Layer 1 ，而是等待多个 Proof 都生成完毕后，将它们聚合在一起，并一次性发给 Layer 1 上的 Verifier 合约；

• 数量问题：如果发起的交易笔数不够多，排序器可能会延迟向 Layer 1 发布数据。举个例子，在市场不活跃的时期，某些 Rollup 网络可能每半小时才向 Layer 1 发送一次交易批次。

关于更适合的去中心化的排序器解决方案问题，模块化或许是最优的解决方式，因为模块化等同于更大的可定制化，在目前的去中心化工具中主要以以下五种为主：

- Single Sequencer & POA

- Based rollup 

- DVT x Sequencer

- Shared Sequencer

- Bootstrap a New Sequencer Set

我们相信在不仅的将来，以上诸多问题可以通过技术来进一步解决。好比降低有效性证明的生成时间，Optimism 承诺近期会发布欺诈证明系统，以及以太坊的 Danksharding 方案也将大幅降低 Rollup 的数据成本，去中心化排序器难题也在会攻克，共同为上述问题提供出有效的解决方案。

结尾：叙事走向

YBB Capital Researcher Ac-Core 自制

超链和超扩展一直是被大家所重点关注的扩展方向，虽目前而言，各个项目仍处于早期发展阶段，但整体都为以太坊带来了更为强大的故事叙事。我们现在可以看到，OP Stack 已经获得了较多的采用，众多明星公链也加入其中，比如 Coinbase、opBNB、Zora、Worldcoin 等众多公链都给予了 OP Stack 很好的品牌背书。包括近期在 6 月 26 日晚，zkSync 宣布推出用于构建定制   ZK rollup 的模块化开源框架 ZK Stack ，这也被许多人认为是 zkSync 团队用来对付 OP Stack 头号的杀手锏。一边是具有先发优势的 OP Stack，一边是具有数学优势的 ZK Stack，总而言之 Layer 2 的任何价值都可以积累到 Rollup 的代币中来，Layer 2 扩容之战才刚刚开始，关于 Layer 2 这场没有硝烟的战争你是如何看待呢？

解释文献：
[ 1 ]https://github.com/ethereum-optimism/optimism/blob/develop/specs/fault-proof.md#fault-proof-program

[ 2 ]https://github.com/ethereum-optimism/ecosystem-contributions/issues/61

[ 3 ]https://github.com/ethereum-optimism/optimism/blob/develop/specs/fault-proof.md#pre-image-oracle

[ 4 ]https://en.wikipedia.org/wiki/System_call

[ 5 ]https://github.com/ethereum-optimism/optimism/blob/develop/specs/fault-proof.md#fault-proof-vm

[ 6 ]https://github.com/ethereum-optimism/ecosystem-contributions/issues/63