Pectra网络升级Meta讨论串 - 魔法师 / 流程改进
- ethereum-magicians
- 发布于 2023-11-29 18:24
- 阅读 12
这篇文章是关于以太坊 Prague/Electra 升级的讨论和提案追踪，以及后续的 Osaka 和 F-Star 升级计划，讨论了 Meta EIPs 的重要性，并提议对 "Considered for Inclusion" 状态进行改进，同时列出了 Prague/Electra 升级中包含和考虑包含的多个 EIP。
5月22日更新
来自EIP-7600: Hardfork Meta - Pectra:
包含的EIP
- EIP-2537: BLS12-381曲线运算的预编译
- EIP-2935: 在状态中保存历史区块哈希
- EIP-3074: AUTH 和 AUTHCALL 操作码
- EIP-6110: 在链上提供验证者存款
- EIP-7002: 执行层可触发的退出
- EIP-7251: 增加 MAX_EFFECTIVE_BALANCE
- EIP-7549: 将委员会索引移到 Attestation 之外
- EIP-7685: 通用执行层请求
考虑包含的EIP
其他 Pectra 提案
- EIP-3068: BN256 HashToCurve 算法的预编译
- EIP-5806: Delegate transaction
- EIP-5920: PAY 操作码
- EIP-6404: SSZ 交易根
- EIP-6465: SSZ 提款根
- EIP-6466: SSZ 收据根
- EIP-6493: SSZ 交易签名方案
- EIP-6913: SETCODE 指令
- EIP-6914: 重用验证器索引
- EIP-7702: 为一次交易设置 EOA 账户代码
- EIP-7212: secp256r1 曲线支持的预编译
- EIP-7377: 迁移交易
- EIP-7545: Verkle 证明验证预编译
- EIP-7553: 分离的付款人交易
- EIP-7557: 区块级别预热
- EIP-7594: PeerDAS - 对等数据可用性采样
- EIP-7609: 降低常见情况下的 TLOAD/TSTORE 定价
- EIP-7623: 增加calldata成本
- EIP-7664: Access-Key 操作码
- EIP-7667: 提高哈希函数的gas成本
NONREENTRANT&REENTRANT操作码
4月10日更新
注意: 我在3月28日的更新中不小心从提案列表中删除了EOF。已在4月5日修复。还包括了最近提出的EIP-7667到列表中。
来自EIP-7600: Hardfork Meta - Pectra:
包含的EIP
- EIP-2537: BLS12-381曲线运算的预编译
- EIP-6110: 在链上提供验证者存款
- EIP-7002: 执行层可触发的退出
- EIP-7251: 增加 MAX_EFFECTIVE_BALANCE
- EIP-7549: 将委员会索引移到 Attestation 之外
考虑包含的EIP
- EIP-7547: 包含列表
其他 Pectra 提案
- EOF ( megaspec, 实现矩阵)
- EIP-2935: 在状态中保存历史区块哈希
- EIP-3068: BN256 HashToCurve 算法的预编译
- EIP-3074: AUTH 和 AUTHCALL 操作码
- EIP-5806: Delegate transaction
- EIP-5920: PAY 操作码
- EIP-6404: SSZ 交易根
- EIP-6465: SSZ 提款根
- EIP-6466: SSZ 收据根
- EIP-6493: SSZ 交易签名方案
- EIP-6913: SETCODE 指令
- EIP-6914: 重用验证器索引
- EIP-7212: secp256r1 曲线支持的预编译
- EIP-7377: 迁移交易
- EIP-7545: Verkle 证明验证预编译
- EIP-7553: 分离的付款人交易
- EIP-7557: 区块级别预热
- EIP-7594: PeerDAS - 对等数据可用性采样
- EIP-7609: 降低常见情况下的 TLOAD/TSTORE 定价
- EIP-7623: 增加calldata成本
- EIP-7664: Access-Key 操作码
- EIP-7667: 提高哈希函数的gas成本
Pectra 之后的提案
执行层: Osaka
来自 EIP-7607: Hardfork Meta - Osaka:
考虑包含
共识层: F-Star
可能专注于 EIP-7594: PeerDAS - 对等数据可用性采样
2024年2月5日更新
-
- 包含 EIPs 6110, 7002 和 7549
- EIP-2537 CFI’d
-
Verkle Tries 包含在 Prague 之后的 EL 分叉 Osaka 中
-
EIP-4444 的工作将与网络升级并行进行
-
其他 EL 提案，按此处出现的顺序排列：
- EVM 对象格式 (EOF)
- EIP-3074: AUTH 和 AUTHCALL 操作码
- EIP-3068: BN256 HashToCurve 算法的预编译
- EIP-6913: SETCODE 指令
- 将代码大小限制增加到
2**16 - EIP-7251: 增加 MAX_EFFECTIVE_BALANCE
- EIP-7377: 迁移交易
- EIP-7547: 包含列表
- EIP-7212: secp256r1 曲线支持的预编译
- EIP-5920: PAY 操作码
- EIP-7553: 分离的付款人交易
- EIP-5806: Delegate transaction
- EIP-7609: 降低常见情况下的 TLOAD/TSTORE 定价
- EIP-6404: SSZ 交易根
- EIP-6465: SSZ 提款根
- EIP-6466: SSZ 收据根
- EIP-7557: 区块级别预热
-
- *
2024年1月15日更新
2024年1月15日更新
到目前为止的提案，按出现顺序排列，高亮显示它们是用于 [EL]、[CL] 还是 [EL+CL]：
- [EL] EIP-2537: BLS12-381曲线运算的预编译
- [EL] EVM 对象格式 (EOF)
- [EL+CL] EIP-7002: 执行层可触发的退出
- [EL] Verkle 树
- [CL] EIP-7549: 将委员会索引移到 Attestation 之外
- [EL] EIP-3074: AUTH 和 AUTHCALL 操作码
- [EL] EIP-3068: BN256 HashToCurve 算法的预编译
- [EL+CL] EIP-6110: 在链上提供验证者存款
- [EL] EIP-6913: SETCODE 指令
- [EL] 将代码大小限制增加到
2**16 - [CL] EIP-7251: 增加 MAX_EFFECTIVE_BALANCE
- [EL] EIP-7377: 迁移交易
- [EL+CL] EIP-4444: 绑定执行客户端中的历史数据
- [EL+CL] EIP-7547: 包含列表
- [EL] EIP-7212: secp256r1 曲线支持的预编译
- [EL] EIP-5920: PAY 操作码
- [EL] EIP-7553: 分离的付款人交易
- [CL] EIP-7594: PeerDAS
此外，以下是来自 CL Github issue 的额外提案：
2023年12月19日更新
12月19日更新
鉴于此处的活动，我将按出现顺序编译迄今为止的提案，高亮显示它们是用于 [EL] 、[CL] 还是 [EL+CL]：
- [EL] EIP-2537: BLS12-381曲线运算的预编译
- [EL] EVM 对象格式 (EOF)
- [EL+CL] EIP-7002: 执行层可触发的退出
- [EL] Verkle 树
- [CL] EIP-7549: 将委员会索引移到 Attestation 之外
- [EL] EIP-3074: AUTH 和 AUTHCALL 操作码
- [EL] EIP-3068: BN256 HashToCurve 算法的预编译
- [EL+CL] EIP-6110: 在链上提供验证者存款
- [EL] EIP-6913: SETCODE 指令
- [EL] 将代码大小限制增加到
2**16 - [CL] EIP-7251: 增加 MAX_EFFECTIVE_BALANCE
- [EL] EIP-7377: 迁移交易
- [EL+CL] EIP-4444: 绑定执行客户端中的历史数据
此外，以下是来自 CL Github issue 的额外提案：
原始帖子
随着 Dencun 的结束，现在是开始考虑 Prague/Electra 升级的时候了。与 Cancun 类似，我建议使用此线程来讨论升级的总体过程和范围。
EIP 倡导者可以使用 prague-candidate 标签来表示他们希望包含在升级中。请注意，共识层团队已经有 一个 Github issue 来跟踪提案。
至于更大的流程调整，我的首要建议是 恢复 Meta EIP。
目前没有一个好的地方可以在网络升级部署并在博客文章中宣布之前跟踪其完整范围。
对于 Dencun，我们有一个 难以找到的 markdown 文件 中的 EL EIP，以及作为 Beacon Chain 规范一部分的 CL EIP。
这并不好，因为这些都有点难以找到，它们都使用单独的 “格式”，并且会导致重复。随着 ERC 和 EIP 现在分开，我建议（回到）使用 Meta EIP 来跟踪包含在网络升级中的 EIP。
对于耦合升级，EL + CL 可以共享单个 Meta EIP，对于解耦升级，它们可以各自拥有自己的 Meta EIP。如果升级从耦合变为解耦，反之亦然，我们可以简单地创建一个新的 Meta EIP，它取代之前的那个。
最后，作为一个“扩展目标”，我们应该就如何处理 “考虑包含” 达成一致。创建这种“原型状态”是为了让 EIP 倡导者更容易了解哪些 EIP 可能 包含在升级中。也就是说，可以认为与 CFI 相关的承诺不足反而会引起更多混乱。此外，CFI 仅在执行层上使用。
如果它没有用，我们应该考虑修改或删除它，或者可能协调其在 EL 和 CL 流程中的定义和使用。
- AllCoreDevs、网络升级和 EthMagicians 流程改进
- EIP-7600: Hardfork Meta - Prague/Electra
- BLS 的预编译
- EIP-7723: 网络升级包含阶段
- 重新配置 AllCoreDevs
- 原文链接： ethereum-magicians.org/t...
- 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～
- 翻译
- 学分: 0
- 分类: 以太坊
- 标签: Prague/Electra升级 EIP Meta EIP Execution Layer Consensus Layer Osaka F-Star
