超级链升级

Superchain 升级

Superchain 升级，也称为 forks 或 hardforks，实现了共识破坏性的变更。

一个 Superchain 升级需要节点软件支持到给定的协议版本。 该版本表明了支持，升级表明了新功能的激活。

本文档列出了 OP-Stack 的协议版本，从 Bedrock 升级开始，以及默认的 Superchain 目标。

网络升级的激活规则参数被配置为 Superchain 目标规范的一部分： 遵循相同 Superchain 目标的链会同步升级。

<!-- START doctoc generated TOC please keep comment here to allow auto update --> <!-- DON'T EDIT THIS SECTION, INSTEAD RE-RUN doctoc TO UPDATE --> 目录

• 协议版本
  • 协议版本格式
  • 构建标识符
  • 主版本
  • 次版本
  • 补丁版本
  • 预发布版本
  • 协议版本暴露
• Superchain 目标
  • Superchain 版本信令
  • ProtocolVersions L1 合约
• 激活规则
  • 基于 L2 区块号的激活（已弃用）
  • 基于 L2 区块时间戳的激活
• OP-Stack 协议版本
• Bedrock 后的网络升级
  • 风化层（Regolith）

<!-- END doctoc generated TOC please keep comment here to allow auto update -->

协议版本

协议版本记录了整套规范 OP-Stack 规范的进展。 OP-Stack 的组件实现了它们各自协议组件域的子集，达到给定的 OP-Stack 协议版本。

OP-Stack 的修改，即对 OP-Stack 的非规范扩展，不包含在协议的版本控制中。 相反，修改必须指定它们基于哪个上游协议版本以及在哪里进行了破坏性更改。 这确保了 OP-Stack 的工具可以与 OP-Stack 的修改共享和协作。

协议版本不是硬分叉标识符，而是表明了对定义良好的一组功能（在过去和未来的硬分叉中引入）的软件支持，而不是所述硬分叉的激活。

可以包含在预期协议版本中的更改可以作为提案包含在规范中，并明确告知它们基于的协议版本。 这使得能够迭代地集成到规范的规范集中， 但这并不保证提议的规范会成为规范。

请注意，协议版本仅适用于其中指定的 Superchain 目标的协议规范。 此版本控制独立于 OP Stack 智能合约中使用的 Semver 版本控制，以及 OP-Stack 的 Semver 版本参考软件。

协议版本格式

协议版本与 Semver 兼容。 它被编码为单个 32 字节长的 <protocol version>。 该版本必须以 32 字节的 DATA 编码在 JSON RPC 中使用。

编码是类型化的，以确保未来的兼容性。

<protocol version> ::= <version-type><typed-payload>
<version-type> ::= <uint8>
<typed-payload> ::= <31 bytes>

version-type 0:

<reserved><build><major><minor><patch><pre-release>
<reserved> ::= <7 zeroed bytes>
<build> ::= <8 bytes>
<major> ::= <big-endian uint32>
<minor> ::= <big-endian uint32>
<patch> ::= <big-endian uint32>
<pre-release> ::= <big-endian uint32>

协议版本的 <reserved> 字节保留供未来扩展使用。

不应直接比较具有不同 <version-type> 的协议版本。

构建标识符

在确定版本优先级时，Semver 定义的 <build> 标识符将被忽略。 <build> 必须为非零才能应用于协议版本。

OP-Stack 的修改应定义一个 <build> 以区别于规范协议功能集。 <build> 的更改可以编码在 <build> 本身中，以与上游协议保持一致。 主版本/次版本/补丁版本应与修改所基于的上游协议的版本对齐。 协议用户可以选择实现对替代的 <build> 的自定义支持， 但如果主要功能与上游协议版本的功能一致，则可以开箱即用。

如果 8 字节的 <build> 标识符的内容是字母数字，包括 - 和 .，则可以将其表示为字符串以提高可读性，如 Semver 格式规范中所述。 尾部的 0 字节可用于填充。否则，它可以表示为带有 0x 前缀的十六进制字符串。

主版本

主版本更改表示对新的共识破坏性功能的支持。 主版本应保留对其先前主版本功能的支持，以便同步/索引历史链数据。 当存在可行的替代方案时，实现可以放弃对先前主版本的支持，例如用于 Bedrock 之前数据的 l2geth。

次版本

次版本更改表示对向后兼容扩展的支持，包括对 Superchain 目标中链集的向后兼容添加。 向后兼容性由现有最终用户是否需要升级节点和工具来定义。 次版本更改还可以包括可选的链下功能，例如其他同步协议。

补丁版本

补丁版本更改表示向后兼容的错误修复和改进。

预发布版本

协议的预发布版本是提案：这些不是生产用途的稳定目标。 预发布版本可能不满足其关联的普通版本表示的预期兼容性要求。 <pre-release> 必须为非零才能应用于协议版本。

节点软件可以支持预发布版本，但如果没有用户通过功能标志或配置更改明确选择加入，则不得激活任何协议更改。

预发布版本不是官方版本， предназначен для разработчиков протоколов для обмена экспериментальными наборами изменений до того, как набор изменений будет рассмотрен управляющими органами. Подверженные изменениям предварительные выпуски.

协议版本暴露

协议版本不会暴露给应用程序层环境： 硬分叉已经根据需要在激活时公开功能的更改，协议版本仅用于链下使用。 协议版本表示对功能的支持而不是激活。 但是，有一个例外：链上组件向链下组件发出信号。 有关此内容的更多信息，请参见 [Superchain 版本信令]。

Superchain 目标

对 L2 状态转换函数的更改通过激活规则确定性地转换到所有节点中。

对 L1 智能合约的更改必须与最新激活的 L2 功能兼容，并通过 L1 合约升级执行。

Superchain 目标定义了一组在 OP-Stack 链之间共享的激活规则和 L1 合约升级，以集体升级链。

Superchain 版本信令

每个 Superchain 目标跟踪协议更改，并在激活新的破坏性功能之前发出 recommended 和 required 协议版本信号。

• recommended：在网络升级之前发出的信号，以提醒协议用户为协议更改做好准备。 建议节点软件通过日志记录和指标向用户发出建议信号。
• required：在破坏性网络升级之前不久发出的信号，以提醒用户注意破坏性更改。 用户可以选择加入更高的警报级别或采取预防措施，以确保与升级保持一致。

信令通过 OP-Stack 软件监控的 L1 智能合约完成。 但是，并非 OP-Stack 的所有组件都需要直接监控 L1： 诸如 Engine API 之类的跨组件 API 可用于转发协议版本信号，以使组件与 L1 隔离。 请参阅 engine_signalOPStackVersionV1。

ProtocolVersions L1 合约

L1 上的 ProtocolVersions 合约使 L2 节点可以接收到超级链协议版本信号。

接口如下：

• 必需的存储槽：bytes32(uint256(keccak256("protocolversion.required")) - 1)
• 推荐的存储槽：bytes32(uint256(keccak256("protocolversion.recommended")) - 1)
• 必需的 getter：required() 返回 ProtocolVersion
• 推荐的 getter：recommended() 返回 ProtocolVersion
• 版本更新还会发出类型化的事件： event ConfigUpdate(uint256 indexed version, UpdateType indexed updateType, bytes data)

激活规则

以下基于 L2 区块的激活规则可以在两种情况下应用：

• Rollup 节点，通过 rollup 配置（也称为 rollup.json）指定，引用通过派生管道传递的 L2 区块（或区块输入属性）。
• 执行引擎，通过链配置（也称为 genesis.json 的 config 部分）指定，引用属于或应用于 L2 链的区块或输入属性。

对于这两种类型的配置，某些激活参数可能适用于超级链中的所有链，然后从超级链目标配置中检索。

基于 L2 区块号的激活（已弃用）

激活规则：x != null && x >= upgradeNumber

这种基于区块号的方法通常在 L1 中使用，直到 Bellatrix/Paris 升级（也称为 The Merge），该升级通过特殊规则进行了升级。

此方法与超级链不兼容，因为激活参数是特定于链的（不同的链在同一时刻可能具有不同的区块高度）。

从 block.number == x 的 block 的 L2 开始，升级规则适用。 如果在配置中未指定升级区块号 x，则忽略升级。

这适用于 L2 区块号，而不适用于 L1-origin 区块号。 这意味着 L2 升级可能处于非活动状态，然后处于活动状态，而无需更改 L1-origin。

基于 L2 区块时间戳的激活

激活规则：x != null && x >= upgradeTime

这是首选的超级链升级激活参数类型： 它在所有 L2 链之间同步，并且与 L1 中基于时间戳的合并后链升级兼容。

从 block.timestamp == x 的 block 的 L2 开始，升级规则适用。 如果在配置中未指定升级区块时间戳 x，则忽略升级。

这适用于 L2 区块时间戳，而不适用于 L1-origin 区块时间戳。 这意味着 L2 升级可能处于非活动状态，然后处于活动状态，而无需更改 L1-origin。

在 Bellatrix/Paris 升级（也称为 The Merge）之后，这种基于时间戳的方法已成为 L1 上的默认方法， 因为它可以通过信标链纪元和槽进行规划。

请注意，L2 版本不限于与 L1 信标链槽或纪元匹配的时间戳。 可以选择一个时间戳与 L1 上的特定槽或纪元同步， 但是在 L2 上激活时可能不存在匹配的 L1-origin 信息。

OP-Stack 协议版本

• v1.0.0: 2021 年 1 月 16 日 - 主网软启动，基于 OVM。 (公告)
• v1.1.0: 2021 年 8 月 19 日 - 社区启动。 (公告)
• v2.0.0: 2021 年 11 月 12 日 - EVM 等效更新，也称为 OVM 2.0 和链再生。 (公告)
• v2.1.0: 2022 年 5 月 31 日 - Optimism Collective。 (公告).
• v3.0.0-1: 2023 年 1 月 13 日 - Bedrock 预发布版本，部署在 OP-Goerli 上，后来部署在 Base-Goerli 上。
• v3.0.0: 2023 年 6 月 6 日 - Bedrock，包括风化层硬分叉的改进，首先部署在 OP-Mainnet 上。

Bedrock 后的网络升级

风化层（Regolith）

Regolith 升级，以一种最适合描述为“沉积在基岩层顶部的灰尘”的材料命名， 基于 Sherlock 审计竞赛的报告和 Bedrock Optimism Goerli 测试网中的发现，对存款处理进行了较小的更改。

更改摘要：

• isSystemTx 布尔值已禁用，系统交易现在使用与常规存款相同的 gas 记账规则。
• 实际的存款 gas 使用量记录在存款交易的回执中，并从 L2 区块 gas 池中扣除。 但是，存款的未使用 gas 不会以 ETH 退还，因为它是在 L1 上烧毁的。
• 交易状态转换之前的存款发送方帐户的 nonce 值记录在一个新的可选字段 (depositNonce) 中，该字段扩展了交易回执（即，Regolith 之前的回执中不存在）。
• 记录的存款 nonce 用于更正 RPC 响应中的交易和回执元数据，包括部署合约的存款的 contractAddress 字段。
• gas 和 depositNonce 数据作为回执的共识表示的一部分提交，使数据能够在独立的 L2 节点之间安全地 同步。
• L1 成本函数已得到纠正，可以更紧密地匹配 Bedrock 之前的行为。

存款规范 更详细地指定了 Regolith 升级的存款更改。 执行引擎规范 指定了 L1 成本函数的差异。

Regolith 升级使用 L2 区块时间戳 激活规则，并在 rollup-node (regolith_time) 和执行引擎 (config.regolithTime) 中指定。

• 原文链接： github.com/ethereum-opti...
• 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～