主要组件： Onchain MIPS.sol: EVM implementation to verify execution of a single MIPS instruction. Offchain mipsevm: Go implementation to produce a proof for any MIPS instruction to verify onchain. 链上部分，MIPS.sol实现了big-endian 32-bit MIPS指令集，模拟Linux内核的最小子集，为Go程序提供支持，但是不包含并发相关的系统调用。 链下部分，mipsevm用Go语言模拟MIPS.sol的执行过程， It's Go code …that runs an EVM …emulating a MIPS machine …running compiled Go code …that runs an EVM 简而言之，Cannon在链上就是在EVM用MIPS去跑MINI Geth(GETH的MIPS编译)，即ETH的Golang版本。 op-challenger op-challenger负责处理与dispute game相关的流程。 挑战是先选中一个tx执行后的state root发出质疑，之后tx将分解为多个instruction，每个instruction执行后产生新状态，形成S1, S2, … Sn的状态序列。 为了提高效率，挑战双方需要轮流执行steps，分为Attack与Defend两类。 Attack: 争议的前一个状态作为输入，期待争议状态作为输出。DAG中需要有对前一个状态的承诺。 Defend: 争议状态作为输入，争议后一个状态作为输出。DAG中需要有对后一个状态的承诺。 举例而言，假设有1-9999个instruction，产生S1-S10000状态序列，先检验第5000个状态，如果相同，attack step，向左二分；如果不同，defend step，向右二分。 最终通过二分法将争议锁定在单个指令的前后状态上，再交由VM处理单个指令的状态验证。 模块的工作流程 正常流程（不包含Challenge） source: Cypher Capital 用户提交交易，可以通过L2 RPC在L2上提交，或者在L1上直接提交（可以绕过op-batcher，有更强的抗审查能力，也可作为紧急逃生装置）。 op-node启动的RPC server接收到交易后，进行排序并发送给op-batcher与op-geth op-batcher对sequenced tx进行压缩，生成batch，提交到DA层（L1）。 op-geth执行sequenced tx，将执行后的新状态传递给op-proposer op-proposer将L2的output root作为对于L2状态的承诺发送到L1进行存储，当挑战期结束，状态被视为finalized。 op-node中的driver会从L1中获取交易数据以及其他信息，derive出canonical L2 block。在L1上finalized的block中batch tx derive出的L2 block被视为finalized，在L1上被confirmed但未finalized的batch tx derive出的L2 block被视为safe，为降低延迟直接由L2生成的L2 block可以通过P2P提前传播，被视为unsafe。 Challenge流程 source: optimism 用户开启interactive dispute game Cannon (VM)在MIPS虚拟机上运行op-program（Written in Go），以便追踪每步执行的状态变化 op-program通过PreImageOracle提供的Rollup Inputs的承诺复现L2状态的计算过程，记录execution trace，无状态地验证dispute op-challenger使用二分法，将争议定位到单个指令 Cannon为执行该指令前后的状态变化生成证明，在L1上的智能合约MIPS.sol上进行验证。 OP Stack+ZKP 根据上面的流程介绍，我们容易发现，Challenge模块与其他模块的耦合度很低，对基本交易流程的影响很低，只有在出现欺诈行为的情况下（自2021年12月OP Mainnet上线至今尚未出现）才需要Challenge模块的介入。 为了缩短当前Optimism七天的退出确认时间，也为OP Stack提供更多模块化的选择，Optimism积极拥抱ZKP技术，希望为OP Stack带来能够证明Optimism fault proof program并且支持知名ISA的ZKP，O(1) Labs与Risc-0团队的方案通过了Foundation Mission (RFP) Application。 O(1) Labs方案 source: O(1) Labs O(1) Labs作为Mina Protocol的开发团队，计划沿用Mina Protocol采用的Kimchi作为MIPS VM的proof system，仅作了一些小的改动。 Kimchi是一个Halo2-like PLONKish system currently configured with an inner-product-argument style polynomial commitment scheme. It supports verifiable computation using traditional turing-machine-based instruction sets. Kimchi的后端可交换，当前的实现定义在Pasta curves using an inner-product-argument-based polynomial commitment scheme (Pasta-IPA)上，与EVM所用的密码学体系不兼容，在EVM上验证成本较高。于是O(1) Labs计划将Pasta-IPA改为KZG commitment scheme using the bn128 curves (bn128-KZG)，可以使用EVM现成的precompile，效率更高。 原来输入fault proof MIPS系统的输入现在输到bn128-kzg Kimchi系统，ZK-Prove执行路径。pre-image系统调用沿用OP Stack的Cannon，最终proof发送到L1上的智能合约，验证通过后在L1更新状态。 RISC Zero方案 RISC Zero团队计划沿用当前实现的Groth16后端的基于RISC-V ISA的zkVM（augmented with accelerated co-processors for common cryptographic tasks including hashing and ECDSA signature verification）， 对基于Reth的Ethereum ZK Client进行修改以进一步适配Optimism，在zkVM中实现L1-L2的derivation logic以证明交易序列是由Optimism sequencer生成的。 ZK Client由zkVM guest program和host library两个部分组成，类比OP labs方案中的op-program和cannon，zkVM guest program负责计算状态转移，host library负责获取计算数据转移所需的数据，协调zkVM guest program的执行，并生成交易执行状态转移的zkp。 OP Stack的ZKP可能性探究 目前一家叫做ZKM的团队实现了ZKMIPs的EVM，即将EVM转译为MIPs指令集并进行零知识证明。目前反馈为，很慢，但是可用。 考虑到Mina和Risc0都拥有相对成熟的开发，经验，我们有理由相信，OP Stack支持ZKP只是时间问题。但是同时，考虑到OP Stack的ZKP开发启动较晚，且不是原生支持，未来的性能如何依然无法预测。 OP Stack, Layer2的通用架构 OP Stack以其优秀的代码实现、宽容的开源协议以及模块化的架构设计获得了许多知名团队的采用，唯一为人所诟病的在于所采用的Optimistic Rollup技术确定性时间过长，技术先进性不如ZK Rollup。如今，借助第三方专业团队的力量，OP Stack开始了迈向ZKP未来的尝试。考虑到当前OP Stack尚未支持Fault Proof，OP Stack有可能跳过Fault Proof阶段，直接使用ZK Proof来获取更快的确定性与更高的安全性。 对于未来的Layer2开发者而言，OP Stack将成为通用的Layer2架构，开发者可以启动自己的Layer2时，依据应用所需要的安全性和实效性，灵活的选择乐观证明，或者零知识证明。可以预见的是，乐观证明的Layer2会更加廉价，零知识证明的Layer2则会更加安全。 来源：金色财经lg...
北美站
