【英文长推】OP Succinct 简介：从 OP Stack Chain 到全面 ZK Rollup 的转变

OP Stack Chains 通过将压缩的交易数据作为数据块发布到 L1 来运作。独立节点读取这些数据以推导状态。在某种频率下，代表 L2 状态的哈希也被发布到 L1，允许用户证明提款并领取他们的 L1 资金。在 OP 当前系统中，这个哈希通过一个故障争议游戏被验证为诚实。为了实现零知识证明，我们用单一要求替换了这个游戏：任何人都可以发布下一个状态，但他们需要提供一个其有效性的 ZK 证明。这需要对 OP 栈进行三项更改：1）最简单的更改是更新链上合约以验证每个新根的 ZK 证明；2）将状态发布到 L2OutputOracle 合约的程序称为 op-proposer。 通常，它的工作相当简单。获取状态。发布它。没有复杂的逻辑；3）但这个 zk-proposer 如何甚至请求证明呢？这就是项目的核心所在。 zk-proposer 与一个服务器并行运行，该服务器使用 Optimism 的 Kona 项目执行任何请求证明的两步过程：首先，它运行在「见证模式」。它在 L1 上运行 OP 的衍生管道（生成给定区块的执行负载），然后在 L2 上执行这些区块。在这个过程中，它保存了执行这些计算所需的所有见证数据，在无需外部信息的情况下重新运行计算。我们所说的见证是什么？在一个区块中访问的所有数据都可以某种方式证明与区块头相关。如果我们保存了遍历试验并证明这些数据所需的所有哈希原像，我们将能够重新运行计算，而无需任何外部信息。有了这些生成的数据，我们将所有内容发送到 SP1 的证明网络。它验证所有数据（在上面的哈希示例中，它会重新哈希所有原像以证明它们是有效的），然后在 zkVM 内重新执行相同的程序。【原文为英文】\n原文链接