以太坊协议升级流程

ethereum
发布于 2025-04-15 18:32
阅读 8

本文档详细描述了以太坊协议升级的流程，包括从开发网络、测试网络到主网络的升级管理，以及安全审查、分叉准备、测试协议和沟通策略。旨在标准化升级过程，从而提高网络的安全性和稳定性，并概述了在升级失败情况下的事件响应计划，确保问题能够得到迅速解决。

## 以太坊协议升级流程

### 摘要
本文档规定了以太坊协议升级的检查清单和事件响应流程。它概述了管理跨开发网络（devnets）、测试网络（testnets）和主网（mainnet）升级的程序，包括安全审查、分叉准备、测试协议和沟通策略。本文档旨在标准化升级流程，以进一步提高网络安全性和稳定性。

### 动机
以太坊会定期进行协议升级，从而为协议引入性能、安全性和功能增强。鉴于这些升级的内在复杂性以及多个团队和系统的参与，标准化的方法可降低升级出错或事件响应不佳的可能性。本文档解决了对清晰、系统的框架的需求，以有效地管理升级过程、降低风险并在必要时促进快速事件响应。

### 时间线

#### 总则
- 不得在重大节假日或活动期间安排升级。
- 不应提前安排多次升级，并且不得将主网升级与其他升级捆绑在一起。
    - 如果提前安排了多次升级，则每次测试网升级之间必须至少间隔 14 天。
    - 如果安排了多次测试网升级，并且第一次测试网升级未被认为是成功的，则下一次测试网升级将自动取消。在第一次事件得到解决之前，不得安排下一次测试网。此时，最早的时间点是从 ACD 电话会议达成一致意见后 14 天。
- 在代表活跃权重 90% 的客户端通过所有[共识](https://github.com/ethereum/consensus-specs/)和[执行](https://github.com/ethereum/execution-spec-tests)测试并保持稳定之前，不得进行升级。
- 必须在所有核心开发者 (ACD) 中进行评估，以评估是否需要升级协议外部的基础设施才能使升级得以进行。
- 如果升级失败，则必须进行事件回顾，以了解出了什么问题，以及如何证明或强烈推断它不会在下一个测试网上发生。
- 如有必要，ACD 可以覆盖本文档的某些部分，例如在有争议的分叉事件中，主网验证者超过 10% 的客户端可能会阻止该过程。

#### EIP
- 必须评估任何 EIP 及其客户端实现是否应接受外部审查。
- 必须遵循 [EIP-7723](https://eips.ethereum.org/EIPS/eip-7723#scheduled-for-inclusion) 中的 SFI 要求，例如确保测试向量被覆盖。
- 必须设置将以太坊改进提案 (EIP) 最后纳入升级的日期。
- 如果包含的 EIP 存在需要更改 EIP 的重大问题，则在升级过程继续之前，必须完成额外的测试、安全评估以及 ACD 的协议。

#### Devnets
- Devnets 预计会出现问题，生命周期短，并且在相关时应启动一个新的。鉴于它们生命周期短，因此被认为超出此过程的范围。

#### Testnets
- 客户端版本准备就绪与第一个测试网上线之间必须有 30 天的间隔。
    - 这是为了提供时间进行内部安全审查、将升级特定代码包含在漏洞赏金计划中以及潜在的外部安全审查。

#### Mainnet
- 在所有测试网都已升级之前，不得设置主网的升级日期。
- 升级必须至少经过两次测试网。
- 在最终测试网验证成功升级后，不得在 30 天内设置主网的升级日期。这是为了确保有足够的时间来测试和发现潜在问题，然后再在主网上线，并允许下游项目规划其升级。L2 需要时间来制定 DAO 提案、组织自己的升级等。

### 验证与审查
#### 内部审查
- 必须在 Eth R&D Discord 上为升级中的每个 EIP 设置一个频道，以确保客户端开发人员、测试工程师和安全研究人员之间的协调。
- 应该认为每个已分配 CFI 的 EIP 都为每个团队分配了一个或多个核心开发人员。
- 应该认为每个已分配 SFI 的 EIP 都为每个团队分配了一个或多个核心开发人员。
    - 测试目标：
        - 验证 EIP 是否按照规范实施并通过测试。
    - 安全目标：
        - 验证 EIP 本身的安全性。
        - 验证 EIP 是否按照规范实施。
        - 从安全角度不断审查 EIP 的客户端实现。
- 通知潜在问题的责任方（即，客户端问题的客户端团队），并跟进。

#### 外部审查
- 从历史上看，当编写智能合约代码时，会触发外部审计，但其他领域也可能需要外部审计。
- 如果认为外部审查是适当的，则应使用提案请求 (RFP) 从各种提供商处收集提案。
- 任何发现都必须通知负责修复该发现的当事方（即，客户端漏洞的客户端团队）并由其签署。

#### 通知生态系统
- 在测试、内部和外部审查完成后，应发布一篇博客文章，描述该过程和任何发现。

#### 将新代码库纳入漏洞赏金计划
##### 以太坊基金会漏洞赏金计划
- 一旦客户端版本准备好进行第一次测试网升级，就应将升级特定代码包含在漏洞赏金计划中。

##### 漏洞赏金竞赛
- 可能会举办漏洞赏金竞赛来众包发现问题，但不得早于：
    - 内部审查已完成。
    - 外部审查已完成（如果正在进行）。
    - 客户端团队已发布其测试网版本。
- 漏洞赏金竞赛的结束时间不得晚于主网升级前三周，以确保及时完成潜在客户端版本的协调工作。

### 升级验证
#### Devnets
- 必须对每个 EIP 进行有针对性的测试，以确认功能，并记录结果。
- 必须验证开发网络中客户端之间的互操作性。
- 必须生成大量交易、边缘案例操作和网络分区，以查看客户端如何处理意外负载或网络分裂。
- 应该进行涵盖非终结性时期的测试。

#### Testnets
- 必须验证所有客户端在升级过程中是否保持共识。
- 必须对每个 EIP 进行有针对性的测试，以确认功能，并记录结果。
- 必须监控来自所有客户端的日志和指标。
- 必须密切监控分叉后的最终确定、验证者参与和区块生产至少 32 个 epoch，然后才能定义成功。
- 必须在升级后继续进行 48 小时的扩展监控，以确保在正常使用情况下的稳定性。

#### Mainnet
- 遵循与测试网相同的程序。

### 事件响应计划
#### 角色分配
- 每次升级都必须有一个事件响应团队，其中包括：
  - 客户端团队协调员（每个客户端团队一名）：客户端团队的主要联系人，确保客户端团队诊断并解决客户端错误。
  - DevOps 协调员：确保完成基础设施和调试。
  - 测试协调员：确保完成测试。
  - 沟通协调员：确保核心开发人员收到相关更新，并完成社区沟通。
  - 安全协调员：确保完成安全协调。
- 谁在特定升级中担任这些角色应由 ACD 决定，并且每个角色都必须分配一名专门的人员，包括一名备用人员，必要时必须接任。
    - 必须对最合适的备份进行评估。例如，这可能是拥有一个不同时区的备份，或者一个在单独的组织或团队中的备份。
- 这些角色并不需要独自完成所有事情，而是负责确保在事件期间履行职责，或者在他们无法再履行职责时将职责转移给其他人。
- 这些角色应通过 Signal 上的事件响应团队群组分享他们的电话号码。
- 这些角色必须在升级激活后的 48 小时内待命，以防止升级在最初被归类为成功后失败。
- 如果发生事件，事件响应团队有责任确保尽快解决事件，并成功履行其职责。

#### 客户端团队协调员
- 确保在 `默认沟通` 频道中实时分享进度/问题。
- 确保将信息转发给各自的团队或用户。

#### DevOps 协调员
- 确保正在监控网络指标（例如，区块生产、最终确定率、节点运行状况）。
- 确保对基础设施问题进行分类。
- 确保将异常情况传达给默认沟通频道。

#### 测试协调员
- 确保如果在升级期间发现问题，则进行测试工作。

#### 沟通协调员
- 在 Signal 上创建 `$fork-$network-incident_response_team` 群组。
- 确保在升级发生时（激活、最终确定、任何问题）在 `状态网站` 上发布更新。
- 确保在需要时分发紧急更新或补丁。
- 确保在必要时召开紧急核心开发人员会议。
- 确保如果发生事件，则至少每 120 分钟提供一次社区更新。
- 确保在升级完成后，发布分叉后摘要。

#### 安全协调员
- 确保在发现与升级相关的漏洞时遵循安全程序。
- 确保与外部研究人员和漏洞赏金报告者协调调查结果。
- 确保定义事件的严重性。

#### 升级程序
- 利用 Discord 上的```#$fork-$network-upgrade``` Eth R&D 频道（默认沟通频道）。
    - 此频道具有权限，因此任何人都可阅读，但只有核心开发人员可以写入。
- 如果需要共享敏感信息，事件响应团队的成员应协助设置安全的沟通频道。

#### 事件严重性级别
- 低：小错误，没有直接风险。修复程序包含在下一个计划的版本中。
- 中：可能的节点崩溃或部分网络降级。带外修复。
- 高：关键共识缺陷、链停止或安全漏洞。全体人员紧急响应。

#### 决策框架
- 对于高严重性问题（例如，链分裂、最终确定失败），事件响应团队负责确保采取适当的措施来尽快解决事件。
- 在默认沟通频道之外做出的决定应记录在案。

### 模板
* 这些模板应添加到每次升级的 ```$fork-pm.md``` 文件中，例如，https://github.com/ethereum/pm/blob/master/Pectra/pectra-pm.md

```markdown
## Holesky 升级和事件响应团队计划

### 升级信息
- **升级日期：**

### 升级/事件响应团队

#### 客户端团队协调员
| 客户端团队 | 主要 | 备份 |
|-------------|---------------------|--------------------|
| Besu | [姓名] | [姓名] |
| Erigon | [姓名] | [姓名] |
| Geth | [姓名] | [姓名] |
| Grandine | [姓名] | [姓名] |
| Lighthouse | [姓名] | [姓名] |
| Lodestar | [姓名] | [姓名] |
| Nimbus | [姓名] | [姓名] |
| Nethermind | [姓名] | [姓名] |
| Prysm | [姓名] | [姓名] |
| Reth | [姓名] | [姓名] |
| Teku | [姓名] | [姓名] |

#### 协调员
| 角色 | 主要 | 备份 |
|------|---------|----------------------------|
| DevOps 协调员 | [姓名] | [姓名] |
| 测试协调员 | [姓名] | [姓名] |
| 沟通协调员 | [姓名] | [姓名] |
| 安全协调员 | [姓名] | [姓名] |

### 沟通渠道
- **主要沟通：** Discord `#$fork-upgrade` (Eth R&D)
- **状态更新：** `状态页面`

### 升级后升级验证
- [ ] EIP-XXXX
    - [ ] 测试用例 1
    - [ ] 测试用例 2
    - [ ] ...
- [ ] 所有客户端在整个升级过程中都保持共识
- [ ] 链已最终确定
- [ ] 验证者参与和区块生产（监控至少 32 个 epoch）
- [ ] 验证了升级后 48 小时的网络稳定性。
```

```markdown
## Sepolia 升级和事件响应团队计划

### 升级信息
- **升级日期：**

### 升级/事件响应团队

### 沟通渠道
- **主要沟通：** Discord `#$fork-upgrade` (Eth R&D)
- **状态更新：** `状态页面`

```markdown
## Hoodi 升级和事件响应团队计划

### 升级信息
- **升级日期：**

### 升级/事件响应团队

### 沟通渠道
- **主要沟通：** Discord `#$fork-upgrade` (Eth R&D)
- **状态更新：** `状态页面`

```markdown
## 主网升级和事件响应团队计划

### 升级信息
- **升级日期：**

### 升级/事件响应团队

### 沟通渠道
- **主要沟通：** Discord `#$fork-upgrade` (Eth R&D)
- **状态更新：** `状态页面`

>- 原文链接： [github.com/ethereum/pm/b...](https://github.com/ethereum/pm/blob/master/processes/protocol-upgrade.md)
>- 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～