坎昆升级的前生、今生和未来

前世

为什么需要坎昆升级？

• 以太坊的愿景为：在去中心化的前提下变得更具有可扩展性且更安全。当前以太坊的升级也致力于解决这个三难问题，但是一直面临着很大的挑战。

• 以太坊的问题：

• 目前出现了TPS 和性能较低，gas 费高且拥堵严重的情况，同时，运行一个以太坊客户端所需的磁盘空间也在快速增长，在底层，确保以太坊安全和去中心化的工作量共识算法对整个环境的影响也愈发显著。

• 所以，在去中心化的前提下，如何传输更多的数据并降低 gas，来增强可拓展性，如何优化共识算法，来保障安全性，都是以太坊目前正在做的努力。

• 为了解决安全、去中心化和拓展性这个三难困境，以太坊曾利用PoW 转 PoS 机制来进一步降低节点门槛，也准备利用信标链随机分配验证者来优化安全性，在可拓展性方面，以太坊考虑使用分片这个方式来减轻节点的工作量，这也能使以太坊可以同时创建多个区块，增强其可拓展性。

• 当前以太坊每一个区块的空间大概是 200~300 KB，每个交易最小大约是 100 个字节，约 2000 笔交易，除以区块时间12秒，以太坊的 TPS 上限就被限制在100 左右。这个数据明显无法满足以太坊的需求。

• 因此，以太坊 Layer2 关注如何能把大量数据放到 block space里去，通过欺诈证明和有效性证明保证安全，这也是为什么 DA 层决定了安全上限的原因，这也是坎昆升级的核心内容。

• 以太坊生态的迭代路线，无法构建对标 Solana 的性能（在延迟和吞吐量方面），短期也看不到 Near 的分片性能，也没有 Sui 和 Aptos 的并行执行性能， 短期内以太坊只能构建以 Rollup 为核心的多层结构，因此坎昆升级解决 TPS 、 gas fee 和开发者体验对于以太坊路线图来说至关重要。

以太坊路线图怎么规划的？

最近几次重要的升级及其目标

• 2020年12月1日 信标链正式发布，为POS升级做了铺垫

• 2021年8月5日 伦敦升级，EIP1559改变了以太坊的经济模型；

• 2022年9月15日 巴黎升级（The Merge），完成了POW切换POS；

• 2023年4月12日 上海升级，解决了质押提款问题；

• 完成了经济模型和POS相关的升级，接下来几次升级解决了以太坊的性能、TPS和开发者体验的问题；

• 下一步重点是以太坊路线图中的 The Surge 。

• 目标： Rollup 中实现 10 万+的 TPS 。

• 主要有2个方案，链上和链下：

• 链下方案：指 Layer2，包括 rollup 等，

• 链上方案：指直接在 L1 中进行更改，也就是热门的分片方案，分片简单理解就是将所有节点划分成不同片区，完成每个片区的任务，这将有效提升速度；

• 分片方案解析：

• 分片（Sharding）方案的困境：曾经的 Sharding 包括状态分片，交易分片等，但是出现不同分片之间的同步是个难题，目前想要完成大范围的网络节点数据同步，技术难度大，不仅无法解决 MEV 的情况，且可能需要大量补丁来弥补可能出现的各类问题，短期无法实现。

• Danksharding 是为以太坊提出的新分片设计， 其核心思想为中心化的出块 + 去中心化的验证 + 抗审查性，这也与下文将要提到的数据可用性采样（DAS）、出块者-打包者分离（PBS）和抗审查清单（Crlist）有关。Danksharding 核心思想的最大意义，在于把以太坊L1变成了一个统一的结算（settlement）和数据可用性（Data Availability）层。

分片方案分为2步，目前看分为Proto- danksharding 和Fully-Rollup。

• Proto- danksharding：

• 介绍： 通过引入 blob 帮助 L2 降费并增加吞吐量 ，同时作为 danksharding 的前置方案为实现完全分片（sharding）铺平道路。预期 proto-danksharding 后， danksharing 的落地需2-5年时间。

• 内容：proto-danksharding 的主要特性是引入新的 blob 交易类型，Blob 具有容量大且便宜的特点，给以太坊外接此类数据包，能让 rollup 的数据全部存入 blob，大大缓解主链的存储压力，同时也能降低 rollup 的费用。

• Fully-Rollup

• 介绍：rollup 全面扩容，重点在于数据可用性的利用。

• 内容：

• DAS 的 P2P 设计：涉及数据分片网络连接问题的一些工作以及研究；

• 数据可用性采样客户端：开发轻量级客户端，可以通过对几千字节的随机采样快速判断数据是否可用；

• 有效的 DA 自我恢复：能够在最恶劣的网络条件下有效地重建所有数据（比如，恶意验证者攻击、或者大块节点的长时间停机）。

以太坊核心开发者会议

以太坊的每一次升级都依赖于核心开发者会议，通过核心贡献者的共同讨论，根据开发者们的一系列提案，决定未来的发展方向

• 定义：核心开发者会议是以太坊开发社区每周举行的一次电话会议，来自不同组织的核心贡献者共同讨论技术问题并协调以太坊的未来工作。它们决定了以太坊协议的未来技术走向，同时也是真正进行以太坊升级决策的权力机构，负责决议，EIP 是否被纳入升级，是否需要进行路线图变更等重要事项。

• 核心流程：以 EIP 为中心的升级流程大致如下，首先在核心开发者会议（简称 ACD）上初步接纳一个 EIP，然后客户端团队无论该 EIP 被纳入升级与否，都对其进行测试，并在最终测试完后进行再一次回顾，再根据探讨决定最终是否纳入实际升级中。

• 会议分2类，分别是共识层会议和执行层会议，两者隔周交替举行：

• 共识层会议（All Core Developers Consensus - ACDC），关注以太坊共识层（权益证明、信标链等）；

• 执行层会议（ All Core Developers Execution - ACDE），后者关注以太坊的执行层（EVM、Gas 时间表等）。

• 以太坊核心维护者有 3 类，主要是一些讨论提案的官方组织或者志愿者论坛：

• AllCoreDevs：代码维护者，负责ETH1网络客户端，升级，维护以太坊代码和核心架构；

• “项目管理”部分：支持以太坊开发人员、协调硬分叉、监控 EIP等，以及直接帮助AllCoreDevs 负责通信和运营；

• Ethereum Magicians：一个希望围绕 EIP 和其他技术主题进行讨论的“论坛”。

坎昆升级相关会议的时间线

按照讨论内容划分，本次坎昆升级可粗略分为5个阶段。

第一个阶段——引入升级主题

引出新任务proto-danksharding、EOF和“selfdestruct”操作码，粗浅讨论上海升级内容

• 以太坊在22年9月15日完成合并后，开发者会议暂停4周，为开发者留取一个月的时间查看后续升级所讨论的 EIP；

• 22年10月28日，合并后的第一次开发者会议，首次提出 proto-danksharding、EOF 的实现和“selfdestruct”操作码，此时， proto-danksharding 的具体范围未确定，有开发者初步认为，可以将上海升级分为几步小型的升级，如先启用质押的 ETH 提款，然后再升级 EIP 4844，但另外一部分开发者认为一步到位实施更大的升级更有意义。

第二个阶段——确定时间范围和KZG仪式的准备

2022年底，以太坊会议主要围绕EOF和EIP 4844 进行讨论，同时持续推进EIP 4844 所需的前期可信设置仪式——KZG仪式，开发者们将在23年1月正式确定4844将在哪个升级中露面

• 22年11月，在以太坊所有核心开发者电话会议#149中，已经提及 EOF 或 proto-danksharding，此时开发者们仍考虑将其放置在上海升级中；

• 22年12月2日的共识层会议中，以太坊生态系统负责人 Trent Van Epps 更新了 EIP 4844 实施所需的可信设置仪式的进展情况，该仪式旨在生成一段将在 EIP 4844 中使用的安全代码。Van Epps 希望该仪式将成为加密领域有史以来规模最大的仪式之一，收集 8000 至 10000 份 contribution，该仪式的公众贡献期将持续大约 2 个月，并于 12 月的某个时候开始；

• 同日的核心开发者会议中，围绕 EOF 和停用 selfdestruct 操作码进行了一定的讨论，以太坊基金会的某位开发人员反对将 EOF 推迟到坎昆，认为如果代码更改不包含在上海，它进入坎昆的可能性很小，关于 selfdestruct 代码，当时有开发人员主张推进 EIP 4758，不过直接停用此操作码将会破坏某些应用程序，开发人员认为在创建一个边缘案例来保护此类型合约之前，该 EIP 应再次权衡一段时间；

• 22年12月9日的核心开发者会议中，关于坎昆升级方面推进了KZG 仪式的实施，目前 EIP 4844 所需的可信设置仪式已准备就绪；

• 22年12月16日的共识层会议中，关于 EIP 4844 的主题，开发人员讨论了将两个不同的拉取请求 (PR) 合并到 proto-danksharding 的规范中，一个与节点如何处理数据修剪后超出特定点的数据可用性有关，一个是当某个块上缺少关于 blob 的信息时，将引入新的错误代码来提醒节点；

• 23年1月5日的核心开发者会议中，开发者们就从上海升级中移除与 EOF 实现有关的代码修改达成共识，Beiko 此时建议在两周之后再决定是否应将 EOF 包括在坎昆升级中；

第三个阶段——初步讨论提案的范围

23年1月底，EOF在被从上海升级移出后移入坎昆升级，此后2个月内主要围绕除了EOF与EIP 4844 之外的其他提案进行讨论，与此同时，EOF又被提议移出坎昆。这段时间主要在划定坎昆升级的提案范围。

• 23年1月20日的核心开发者会议中，EOF 被移入坎昆升级；

• 23年3月6日的核心开发者会议中，关于坎昆升级的初步提案为：EIP 4788（公开信标链状态根）、EIP 2537（高效执行 BLS 签名验证和 SNARKs 验证等操作）、EIP-5920（引入新的操作码 PAY），以及 EIP 6189（用于使 SELFDESTRUCT 与 Verkle 树兼容）与 EIP-6190（更改 SELFDESTRUCT 函数以仅导致有限数量的状态更改）的结合实施；

• 23年3月16日的核心开发人员会议里，除了 EOF 与 EIP 4844 之外，下列提案被考虑纳入坎昆：SSZ 格式、SELFDESTRUCT 删除、EIP 2537、EVMMAX、EIP 1153、无限制的 SWAP 和 DUP 指令、引入PAY 代码和 EVM 中的信标状态根；

• 23年3月30日的核心开发人员会议中，首次提出关于停用 SELFDESTRUCT的提案 EIP-6780，这也是坎昆最后确定使用的停用 SELFDESTRUCT的提案。但是关于 EOF 的实施，来自 Erigon (EL) 客户团队的某位开发人员表示 EOF “变化太大”，无法在即将到来的坎昆升级中与以太坊改进提案 EIP 4844 相结合，有人提议在坎昆升级后不久在硬分叉中实施 EOF；

第四个阶段——确定明确的提案升级方向，删除无关提案

23年4月，对于坎昆升级应覆盖的提案有了清晰的方向，重点节点在4月13日的开发者会议，此会议提出了9个EIP，以及tim本人对于候补提案也有了较为深入的讨论，在4月27日的会议中，EIP 6780、EIP 6475 和EIP 1153 被确定纳入坎昆，同时EOF和EVMMAX（与EOF实现相关的EIP子集）被从坎昆升级中删除，EOF升级主要可以帮助EVM进行版本控制，并且可以同时运行多套合约规则，有助于以太坊后续的拓展性，但是考虑到整次升级的可实现度，EOF升级可能在后续随着日常升级进行推进

• 23年4月12日，以太坊上海升级已完成；

• 23年4月13日的核心开发者会议中，开发人员讨论了EIP 4844（用于在 EL 中公开有关 CL 状态根的数据），除此之外，还有至少九个其他 EIP被考虑纳入升级，分别是EIP 4844、SELFDESTRUCT 移除（EIP-6780、EIP 4758、EIP 6046、EIP 6190）、EIP 5920、EIP 1153、EIP 2537、EIP 4788、EVMMAX EIPs（EIP 6601和 EIP 6690）、SSZ changes（EIP 6475、EIP 6493、EIP 6465、EIP 6404 和EIP 6466 ）、EIP 5656 和 EIP 6193；

• 23年4月27日的核心开发者会议里，重点划分了几个的进度和取舍。首先，EIP4844 继续确定纳入坎昆升级，同时增加了以下 EIP：EIP 6780（更改 SELFDESTRUCT 操作码的功能）、EIP 6475（一种新的简单序列化（SSZ）类型来表示可选值）、EIP 1153（添加新的操作码来操作status）；其次，正在考虑但尚未正式纳入升级的 EIP 为 EIP 6913（引入 SETCODE 指令）、EIP 6493（为 SSZ 编码交易定义签名方案）、EIP 4788（在 EL 块头中公开信标链块根）、EIP 2537（添加 BLS12-381 曲线作为预编译）和 EIP 5656（引入新的 EVM 指令用于复制内存区域）；最后，EOF 和 EVMMAX（与 EOF 实现相关的 EIP 子集）被从坎昆升级中删除。EOF 升级曾在2023年1月初的以太坊开发者大会中被移出上海升级，后续从23年1月底至4月初，都被默认将在坎昆升级中出现，但23年4月29日的开发者会议中，EOF 被再次移除。

第五个阶段——最后的提案确定和细节完善

23年5月主要针对最后的提案细节进行精简和完善，SSZ-> RLP 的变化将意味着不再需要坎昆的两个SSZ EIPs，因此EIPs 6475和6493将被移出坎昆升级。同时在26日的核心会议中，Tim Beiko 建议未来围绕扩大坎昆范围的对话仅限于以下五个EIP：EIP-5920、5656、7069、4788和2530。开发者目前已确定坎昆升级的全部范围。

• 23年5月5日的以太坊核心共识会议，讨论了上次提及的 EIP 4788，同时增加了对 EIP 6987和 EIP 6475的讨论，这两个提案分别有关验证者和 SSZ 交易；

• 23年5月11 日的第 161 次以太坊执行层会议中，Tim Beiko 表示，未来几周内仍然可以对坎昆升级范围进行修改，但如果没有来自开发者的明确建议，坎昆升级的范围将保持「默认」状态，且有关 EIP-4844的讨论中显示，开发者同意将 SSZ 从 EIP-4844 的 EL 实现中移除，但目前仍未影响到 6475 的持续推进。除此之外，开发人员也简要讨论了两个 EIP 供坎昆考虑，分别是 EIP 6969（EIP 1559 的修改版本）和 EIP 5656（用于复制内存区域的高效 EVM 指令）；

• 23年5月18日的开发者共识会议中简要讨论了4844的进展，如允许 EL 上的智能合约应用程序验证 CL 状态的证明；

• 2023年5月25日，第162次以太坊核心会议中讨论了停用 SELFDESTRUCT、EIP-4844 规范更改、操作码管理和潜在的最终 Cancun 添加等内容。Tim Beiko 建议未来围绕扩大坎昆范围的对话仅限于以下五个 EIP：EIP-5920、5656、7069、4788 和 2530。开发者会在未来几周内会确定 Dencun（Deneb + Cancun）的全部范围；

• 2023年6月1日第 110 次以太坊共识层会议，以太坊基金会某位研究员介绍了一项关于以太坊主网节点传播大量数据的能力的数据实验结果，由此结果，该研究员建议将 EIP 4844 规范从每个块最多 4 个 blob 增加到 6 个。同时开发者们正考虑将 EIP 4788 纳入坎昆升级；

• 2023年6月13日的核心开发者会议中，开发者们正式确认了升级范围，包括EIP 4844、EIP 1153、EIP 5656、EIP 6780、EIP 4788；

• 2023年6月15日的共识会议中，讨论了在Deneb中包含哪些以 CL 为中心的EIP，其中，EIP-6988、EIP-7044、EIP-7045被提议加入，以及 CL 客户端团队同意在下一个EIP-4844测试网 Devnet6 上测试增加的 blob 数量，并在两周内就此事做出最终决定，同时以太坊基金会研究员Michael Neuder提出取消32枚ETH质押上限，以帮助减少活跃验证者集的增长；

• 2023年6月22日的会议中，tim 提议将4844的预编译地址移动到0xA，将他们打包并移动BLS到另一个地址，虽然该预编译通过 EIP 2537 引入，但在坎昆中不会考虑此方案；

• 2023年6月29日的共识会议中，开发人员继续讨论了 blob 数量，将目标 blob 限制 从 2 上调到 3，将最大 blob 限制从 4 上调到 6，同时4844的测试网 Devnet #7 即将上线。

今生

• 核心内容是 EIP 4844，即Proto-Danksharding

• 此次坎昆升级最终确定的 EIP 范围为：EIP 4844、EIP 1153、EIP 5656、EIP 6780、EIP 4788。同时在6月19日的第111次以太坊 ACDC 会议中，开发者们继续讨论了 EIP 6988、 EIP 7044、EIP 7045，以便在 Deneb 中纳入。开发者们表示，计划在未来几周内将上述三个 EIP 合并到 Deneb 规范中。

重点EIP的分析

EIP 4844

• 简介：

• EIP4844提案的名称为Proto-Danksharding，是完整版分片扩容Danksharding的前置方案，整套分片方案其实就是围绕着Rollup来进行链上扩容的。方案目的是为了扩展第 2 层 Rollup——通过帮助L2降费并增加吞吐量 ，同时为实现完全分片（sharding）铺平道路。

• 23年2月的电话会议中，以太坊开发人员将 EIP 4844 升级命名为 Deneb，这是天鹅座中的一颗一等星的名称，即以后相关 GitHub 版本上 EIP 4844 的命名将更新为 Deneb；在23年6月1日的会议中，以太坊的下一次升级规范有一些变化，在 CL 端称为 Deneb，在 EL 端称为 Cancun；

• 23年6月23日的开发者会议中，开发人员准备更新 EIP 4844 的预编译地址。目前，、核心开发人员已向EVM 添加了 9 个预编译，并将通过激活 EIP 4844 和 4788 分别在“0xA”和“0xB”地址下创建两个预编译。6月29日的共识会议中，已经准备推出 EIP 4844 的专用短期测试网络 Devnet #7。

• EIP-4844引入了一种全新的交易类型——Blob Transcation。

• Blob简介：

• Blob ，类似一个外挂数据包，开始只有 128 KB 的存储空间，在该提案讨论初期，Blob 的 target 和 limit 为2/4，在23年6月9日的开发者会议中，被调整为3/6。即目前以太坊中每一笔交易可以最多携带三个Blob交易，即 384 KB，每一个区块的 target Blob 容量为 6 个，即 768 KB，最大可承载 16 个 Blob，即2MB；

• 可能会对网络稳定性产生一定影响，但是以太坊开发团队仍决定先行测试，避免后续需要硬分叉来拓展 blob 块。

• Blob 以 KZG commit Hash 作为 Hash，用于数据验证，作用和 Merkle 类似；

• 节点同步链上的 Blob Transaction 后，Blob 部分会在一段时间后过期删除，存储时间为三周。

• Blob作用——提高以太坊的TPS，同时降低成本

• 目前整个以太坊总数据量大小只有1TB左右，而Blob可以给以太坊每年带来2.5～5TB的额外数据量，直接远超账本本身好几倍；

• 对于节点来说，一个区块多下载1MB～2MB左右的Blob数据并不会造成带宽负担，在存储空间上也仅仅是增加了固定的200~400GB左右一个月的Blob数据量，这些并不会影响到整个以太坊节点的去中心化，但围绕着Rollup实现的扩容是极大的提高；

• 且节点本身其实是不需要去存储全部的Blob数据的，因为Blob其实是个临时的数据包，那么其实对于节点来说只需要下载固定三周的数据量即可。

• EIP-4844的作用——开启Danksharding叙事的前章

• 高扩容：目前EIP-4844可以初步扩容L2，完整版Danksharding可以将EIP-4844中的Blob数据量从1MB～2MB扩展至了16MB～32MB，在确保了去中心化和安全性的同时实现了更高的扩容；

• 低费用：bernstein分析师表明，Proto-dank-sharding可以将第2层网络的费用降低到当前水平的10-100倍；

• 实际数据：

• Opside 测试网部署了4844，目前观察可以降低 rollup 的 50%成本；

• EigenLayer 的 DA 技术方案没有披露太多，无法评估其数据；

• Celestia 严格意义上来说和以太坊关系不大，其 DA 花费现在也无法评估，取决于其具体技术方案；

• Ethstorage 的方案是上传其Layer2存储证明，其 DA 成本可能会降低至原先的5%；

• Topia 预期降低100~1000倍成本，因为主网 Danksharding 还要兼顾安全性和兼容 Layer1 层面的 P2P 网络广播。

• DA解决方案：Danksharding（以太坊扩容的分片解决方案）目前若继续扩容可能会节点负担过大（16mb以上）和数据可用性不足（30天有效期）的问题。解决方式：

• 数据可用性采样（Data Availability Sampling）——降低了节点负担

• 将 Blob 中的数据切割成数据碎片，并且让节点由下载 Blob 数据转变为随机抽查 Blob 数据碎片，让 Blob 的数据碎片分散在以太坊的每个节点中，但是完整的 Blob 数据却保存在整个以太坊账本中，前提是节点需要足够多且去中心化；

• DAS采用了两个技术：纠删码（Erasure Coding）和 KZG 多项式承诺（KZG Commitment）；

• 提议者-打包者分离（PBS）——解决了节点的工作分工问题，让性能配置高的节点负责下载全部数据进行编码分发，让性能配置低的节点来负责抽查验证。

• 性能配置高的节点可以成为打包者（Builder），打包者只需要负责下载 Blob 数据进行编码并创建区块（Block），然后广播给其他的节点来进行抽查，对于打包者（Builder）来说，因为同步数据量和带宽要求较高，所以会相对中心化；

• 性能配置较低的节点可以成为提议者（Proposer），提议者只需要验证数据的有效性并创建和广播区块头（Block Header），但对于提议者（Proposer）来说，同步数据量和带宽要求较低，所以会去中心化。

• 抗审查清单（crList）——解决了对于打包者而言因其审查权力过大，就可以故意忽略掉某些交易并且随意排序并插入自己想插入的交易去获取 MEV的问题。

• 在打包者（Builder）打包区块交易之前，提议者（Proposer）会先公布一个抗审查清单（crList），这个 crList 中包含着 mempool 中的所有交易；

• 打包者（Builder）只能选择打包并对 crList 里的交易进行排序，这意味着打包者不能插入自己的私有交易去获取 MEV，也不能去故意拒绝某个交易（除非 Gas limit 满了）；

• 打包者（Builder）打包好之后将最终版本的交易列表 Hash 广播给提议者（Proposer），提议者选择其中一个交易列表生成区块头（Block Header）并广播；

• 节点同步数据时会从提议者（Proposer）那获取区块头，然后从打包者（Builder）那获取区块 Body，确保区块 Body 是最终选择的版本。

• 双槽 PBS——解决了中心化的打包者通过获取 MEV 越来越中心化的问题

• 用竞标的模式来决定出块：

• 打包者（Builder）拿到 crList 后创建交易列表的区块头并出价；

• 提议者（Proposer）选择最终竞标成功的区块头和打包者（Builder），提议者无条件获得中标费（不管是否生成有效区块）；

• 验证委员会（Committees）确认中标的区块头；

• 打包者（Builder）披露中标的区块 Body；

• 验证委员会（Committees）确认中标的区块 Body 并进行验证投票（通过则出块，如果打包者故意不给区块 Body 则视为区块不存在）。

• 意义：

• 首先，打包者（Builder）拥有更大权力打包交易，但是上文提到的 crList 首先就限制了其临时插入交易的可能，其次，若打包者（Builder）想通过更改交易顺序获利，则其需要在一开始就付出很大的竞标成本来保证自己可以获得区块头资格，那么其获得的MEV利润就进一步被缩小，整体下来对于其获得MEV的手段和实际价值都有所影响；

• 但是，初期可能会导致仅有少部分人成为打包者（考虑到节点性能问题），而大部分人仅成为提议者，这有可能导致进一步中心化，同时，在打包者数量本身就很少的情况下，某些具有 MEV 能力的经验丰富的矿工将更有可能竞标成功，这将更加影响实际的MEV解决效果；

• 对于某些采用 MEV 拍卖方式的 MEV 解决方案来说有一定影响。

• 意义：

• EIP 4844 实际上是一个超级简化版的 Danksharding：它提供了一个跟 Danksharding 一样的应用接口，包括一个新的 opcode 叫 Data Hash；以及新的一个数据对象叫 Binary Large Objects，也就是 Blob；

• proto-danksharding 是用来实现完整 Danksharding 规范的“支架” (即交易格式和验证规则) 提案：不过目前还没实现任何分片，所有验证者和用户仍需要直接对完整数据的可用性进行直接验证；

• 为什么长期角度选择 proto-danksharding 而非 EIP 4488 的直接让 layer2 降费，因为这样未来升级成完整分片时仅需小幅调整：

• EIP 4488 与 proto-danksharding 的主要实际区别在于，EIP-4488 试图将今天以太坊所需做出的变更降到最低，而 proto-danksharding 则对今天以太坊做出更多的变更，以便在未来升级到完整版分片时只需做出很少的变更；

• 虽然实现完整分片 (有数据可用性采样等) 是一项很复杂的任务，而且实现 proto-danksharding 后还有很复杂的工作，但这些复杂性都会控制在共识层上。一旦 proto-danksharding 部署了，执行层客户端团队、rollup 开发者和用户在过渡到完整分片时都不需要做任何额外的工作了。

• 要实现完整分片，需要完成 PBS、委托证明和数据可用性采样的实际实现，不过此类修改都将集中于 CL 层，无需开发者进行再调整：目前 4844 实现了一种新的交易类型，与完整分片里需要的交易格式、共识交叉验证逻辑和执行层逻辑等完全相同，也衍生出了用于 blob 的、自我调整的独立 gas 定价，未来要实现完整分片，需要完成PBS、委托证明和数据可用性采样的实际实现，不过这些修改仅在 CL 层，不需要 EL 层或 rollup 开发者进行修改，便利开发者。

其次是SELFDESTRUCT removal，EIP-6780最终被确定为最适合的方案，但26日的开发者会议中tim提议在此提案中增加另一个操作码SETCODE，以允许程序性账户仍然可以更新

SELFDESTRUCT removal EIP-6780：X

• 背景：

• 在21年3月，Vitalik 就提出 SELFDESTRUCT 对以太坊生态弊大于利，主要原因在于它是唯一一个能在单个区块中变更无限个状态对象、导致合约代码变动、能未经账户同意就能修改账户余额的操作码，对于以太坊安全中有很大隐患；

• 在链上唯一移除一个合约的办法就是SELFDESTRUCT。如果在合约里面调用：selfdestruct 函数即可自毁合约。存在合约中的以太坊将会发送到设计好的地址里。剩下的代码和存储变量将会在状态机中被移除。其实合约销毁这个动作理论上听上去是个好主义，但实际上是很危险的。selfdestruct函数虽然能在紧急情况下帮助开发人员删除智能合约并将合约内的余额转移到指定的地址，但这一特性也被不法分子利用，使它成为了攻击手段。

• 23年4月13日的核心开发者会议中，引入了四个有关 SELFDESTRUCT 的提案参与讨论，分别是6780、4758、6046和6190，后续 EIP 6780被定为最终提案。

• 简介：selfdestruct是智能合约的紧急按钮，销毁合约并将剩余ETH转移到指定账户。

• EIP 6780：停用 SELFDESTRUCT，除非他们在合约里的同一交易中。

• 更新：5月26日，tim 提议除了删除 SELFDESTRUCT 之外，还要增加另一个操作码—— SETCODE，以允许程序性账户仍然可以更新。（即加入了更新功能，通过更新/升级的方式将智能合约内的财产等进行update），此处是吸取了 EIP 4758 的优势，其可以让 dapp 有升级空间。

• 原因：原先操作SELFDESTRUCT码需要对帐户状态进行大量更改，如删除所有代码和存储。这在未来对使用 Verkle 树带来了困难：每个帐户将存储在许多不同的帐户密钥中，这些密钥不会明确连接到 root 帐户。

• 更改：此 EIP 实现了更改，删除 SELFDESTRUCT，以下两种情况除外

• 仅用于SELFDESTRUCT取回资金的应用程序仍然可以使用；

• 在合约里的同一交易中使用的SELFDESTRUCT也无需更改。

• 意义：提高安全性

• 之前主网上存在有合约存在用SELFDESTRUCT限制谁可以通过合约发起交易的情况；

• 防止用户在 SELFDESTRUCT 一个金库后继续往其中存入款项并交易，那么这个金库在反复利用中可能导致任何人都可以窃取金库中的代币。

下方三个提案为后续删除的有关SELFDESTRUCT的提案，在23年4月28的核心开发者会议中正式选择6780，其余三个提案被弃用，原因为以太坊开发团队最终想完全删除SELFDESTRUCT操作码，而下列三个提案更多是采用替换的方式进行修正。

• EIP-4758（弃用）：通过将 SELFDESTRUCT 更改为 SENDALL 来停用 SELFDESTRUCT，这可以向调用者恢复所有资金（将帐户中的所有以太币发送给调用者），但不会删除任何代码或存储。

• 原因：同上，原先操作SELFDESTRUCT码需要对帐户状态进行大量更改，如删除所有代码和存储。这在未来对使用 Verkle 树带来了困难：每个帐户将存储在许多不同的帐户密钥中，这些密钥不会明确连接到 root 帐户。

• 更改：

• 操作码SELFDESTRUCT重命名为SENDALL，现在只将账户中的所有 ETH 移动到调用者方，该方案不再破坏代码和存储，或改变随机数；

• 相关的所有退款SELFDESTRUCT均已删除

• 意义：

• 相较于EIP-6780保存了原先的功能，因为有的应用程序仍在/需要使用SELFDESTRUCT码。

• EIP-6046（弃用）：将 SELFDESTRUCT 替换为 DEACTIVATE。将 SELFDESTRUCT 更改为不删除存储密钥，并在帐户随机数中使用特殊值来表示停用

• 原因：同上，使用 Verkle 树，帐户将以不同方式组织：帐户属性（包括存储）将具有单独的密钥，但是不可能遍历并找到所有使用过的密钥。而原先操作SELFDESTRUCT码需要对帐户状态进行大量更改，这使得SELFDESTRUCT在 Verkle 树中继续使用非常困难。

• 更改：

• 改变EIP-2681引入的规则，使常规的nonce增加受到2^64-2而不是2^64-1的约束；

• SELFDESTRUCT被更改为：

• 不删除任何存储密钥并将帐户保留在原处；

• 将账户余额转移到target ，设置账户余额为0.

• 将帐户随机数设置为2^64-1。

• 自EIP-3529以来不予退款；

• EIP-2929的相关规则SELFDESTRUCT保持不变。

• 意义：

• 该提案相比于其他的直接删除SELFDESTRUCT的行为拥有了更多灵活性。

• EIP-6190（弃用）：改变SELFDESTRUCT，与 Verkle 兼容，使其只引起有限数量的状态变化

• 原因：同上，使用 Verkle 树，帐户将以不同方式组织：帐户属性（包括存储）将具有单独的密钥，但是不可能遍历并找到所有使用过的密钥。而原先操作SELFDESTRUCT码需要对帐户状态进行大量更改，这使得SELFDESTRUCT在 Verkle 树中继续使用非常困难。

• 更改：不是在交易结束时销毁合约，而是在调用它的交易结束时发生以下情况：

• 合约代码设置为0x1，随机数设置为2^64-1。

• 合约的0第 th 个存储槽设置为合约使用CREATE操作码 ( keccak256(contractAddress, nonce)) 时将发布的地址。随机数始终为2^64-1。

• 如果调用被一个或多个别名合约转发后合约自毁，则将别名合约的第0th 个存储槽设置为步骤 2 中计算的地址；

• 合约的余额将全部转移到堆栈顶部的地址；

• 堆栈的顶部被弹出。

• 意义：

• 旨在让SELFDESTRUCT可以后续形成Verkle 树，同时进行最少的更改；

• 应用了EIP-2929的 gas 成本增加。

接着是EIP 1153，节省gas的同时，为未来的存储设计铺路

EIP 1153X

• 简介：瞬态存储操作码，添加用于操作与存储行为相同但在每次交易后丢弃的状态的操作码。

• 原因：

• 在以太坊中运行交易可以生成多个嵌套的执行框架，每个框架由CALL（或类似的）指令创建。可以在同一笔交易中重新输入合约，在这种情况下，不止一个框架属于一个合约。

• 目前，这些框架可以通过两种方式进行通信：通过CALL指令传递的输入/输出，以及通过存储更新。如果存在属于另一个不受信任的合约的中间框架，则通过输入/输出进行的通信是不安全的。

• 以 reentrancy lock 为例，它不能依赖中间帧来传递锁的状态：SSTORE通过存储的通信SLOAD很昂贵，而瞬态存储是解决帧间通信问题的专用且 gas 高效的方案。

• 改变：EVM 中添加了两个新的操作码，TLOAD( 0xb3) 和TSTORE( 0xb4)。

• 瞬时存储对于拥有它的合约来说是私有的，就像持久存储一样，只有拥有合同框架才能访问其临时存储。当访问存储时，所有帧都会访问同一个临时存储，其方式与持久存储相同，但与内存不同。

• 潜在用例：

• reentrancy lock；

• 链上可计算 CREATE2 地址：构造函数参数从工厂合约中读取，而不是作为初始化代码哈希的一部分传递；

• 单笔交易EIP-20批准，例如#temporaryApprove(address spender, uint256 amount)；

• 转账费用合约：向代币合约支付费用以在交易期间解锁转账；

• “Till”模式：允许用户执行所有操作作为回调的一部分，并在最后检查“till”是否平衡；

• 代理调用元数据：在不使用调用数据的情况下将额外的元数据传递给实现合约，例如不可变代理构造函数参数的值。

• 意义：

• 节省 gas，拥有更简单的 gas 计费规则；

• 解决帧间通信问题；

• 不改变现有操作的语义；

• 使用后无需清除存储槽；

• 未来的存储设计（例如 Verkle 树）不需要考虑瞬时存储的退款问题。

接着是4788，能减少对质押池的信任假设

EIP 4788：X

• 简介：EVM 中的信标块根。

• 更新：在23年6月15日的开发者会议中，开发者提出进行代码更改以改善质押者体验，该 EIP 将公开信标链区块的根，其中包含 EVM 内部链状态信息，供 DApp 开发者的信任最小化访问。

• 改变：在相应的执行负载头中提交每个信标链块的哈希根，同时将这些根存储在一个处于执行状态的合约中，并添加一个读取该合约的新操作码。

• 意义：这是一项代码修改提案，提议修改以太坊虚拟机（EVM）以使其能够公开合约层（CL）状态根在执行层（EL）的数据，可以使以太坊网络中不同协议和应用程序之间的通信更加高效和安全。允许质押池、桥接和 restaking 协议有更多无需信任的设计。

最后是5656，提供了一种高效的新的内存复制操作码，但是考虑到其测试带宽，目前处于暂时被包括进升级的状态

EIP 5656X

• 简介：MCOPY - 内存复制指令。

• 更新：23年6月9日，开发团队表示最初对 MCOPY 存在分歧，因为虽然其解决了安全问题，但仍担心将它添加到升级所需的实施 + 测试带宽，但是最后仍同意包含该 EIP，但是如果开发者在测试或客户端遇到容量问题，就会考虑将其删除。因此，MCOPY处于暂时被包括进坎昆升级中的状态。

• 更改：提供了一种高效的 EVM 指令来复制内存区域。

• 意义：内存复制是一个基本操作，但在EVM上实现它需要成本。

• 随着 MCOPY 指令的可用性实现，可以更精确地复制代码词句，将提高约 10.5% 的内存副本性能，对于各种计算量大的操作非常有用；

• 对编译器生成更有效和更小的字节码也将会很有用；

• 可以节省一定的身份预编译的 gas 费用，但是并不能起到实际推进此部分实现的作用。

候选名单EIP

23年6月15日，开发者共识会议讨论了在Deneb中包含哪些以CL为中心的EIP，其中，EIP 6988、EIP 7044、EIP 7045 被提议加入。

EIP 6988：X

• 简介：防止被罚没的验证者被选为区块提议者。

• 意义：加大了违规节点的惩罚，将利好 DVT。

EIP 7044：X

• 简介：确保签名的验证器退出永久有效。

• 意义：可以一定程度上改善质押者体验。

EIP 7045：X

• 简介：将 attestation slot 包含范围从一个 epoch 的滚动窗口扩展到两个 epoch。

• 意义：加强网络安全性。

删除EIP的分析

在23年4月29日的第160次以太坊ACDE会议中，EVMMAX和EOF被确认移出本次升级，与EOF相关的改动可能会在后续的日常升级中引入

EVMMAX EIPs：

• 简介：EVMMAX 旨在为以太坊上的算术运算和签名方案带来更大的灵活性。目前，有两种 EVMMAX 提案，一种带有 EOF，另一种不带 EOF。

• EIP 6601：EVM 模块化算术扩展 (EVMMAX)

• 改变：是EIP 5843的迭代，与EIP 5843的区别在：

• 6601引入了一个新的EOF部分类型，存储模数、预计算的Montgomery参数、将被使用的值的数量（仍然支持运行时可配置的模数）；

• 6601为EVMMAX值使用一个单独的内存空间，用新的加载/存储操作码在EVM<->EVMMAX内存之间移动值；

• 6601支持对高达4096位的模数的操作（EIP中提到的暂定限制）。

• 意义：EIP-5843 为以太坊虚拟机引入高效模块化加法、减法和乘法，EIP-6601在此基础上进一步升级，通过引入设置部分、单独的内存空间和新的操作码，为模块化算术运算提供更好的组织和灵活性，同时支持更大的模数，提高 EVM 的性能。

• 作为 EVM 合约，在各种曲线（包括 BLS12-381）上启用椭圆曲线算术运算；

• MULMOD与现有操作码相比，将对高达 256 位的值进行操作的 gas 成本降低 90-95% ADDMOD；

• 允许将 modexp 预编译实现为 EVM 合约；

• 显着降低代数哈希函数（例如 MiMC/Poseidon）和 EVM 中的 ZKP 验证的成本。

• EIP 6690：

• 改变：EIP-6990是从 EIP-6601 改编而来的提案，旨在不依赖 EOF 向 EVM 引入优化的模块化算术运算。虽然 EIP-6601 需要 EIP-4750 和 EIP-3670 作为依赖项，但 EIP-6990 提供了一个更独立的解决方案。它通过消除对 EOF 的依赖提供了一种更简化的方法。

• 意义：它保留了 EIP-6601 的核心功能，可以对高达 4096 位的奇数模数进行优化的模块化算术运算，这种简化允许更有效的实施和采用，同时仍然提供与 EIP-6601 相关的好处。

EOF changes：

• 简介：EOF 是对 EVM 的升级，引入了新的合约标准和一些新的操作码，传统的 EVM 字节码（bytecode）是非结构化的指令序列（unstructured sequence of instructions）字节码。EOF 引入了容器（container）的概念，它实现了结构化的字节码。容器由一个 header 和几个 section 组成，来实现字节码的结构化。升级后 EVM 将可以进行版本控制，并且同时运行多套合约规则。

• EIP 663：

• 简介：无限制的 SWAP 和 DUP 指令

• 意义：通过引入了两个新指令：SWAPN 和 DUPN，它们与 SWAP 和 DUP 的区别在于堆栈深度从 16 个元素增加到 256 个元素

• EIP 3540：

• 简介：

• 从前链上部署的 EVM 字节码都是没有一种预先定义的同一结构的，代码只有在客户端中被运行前才会被验证，这既是一种间接成本，也会阻碍开发者引入新功能或弃用老功能。

• 此 EIP 为 EVM 引入一种可以拓展和版本控制的 container，并且声明了 EOF 合约的格式，以此为基础就可以实现在部署 EOF 合约的时候对代码进行验证，即 creation time validation，意味着可以防止不符合 EOF 格式的合约被部署，这种改动实现了 EOF 版本控制，会有助于未来停用 EVM 已有的指令或者引入大型功能（如账户抽象）

• 意义：

• 版本控制有利于以后实现引入或弃用新功能（例如引入账号抽象）；

• 合约代码和数据的分离对于L2的验证(op)有益，减少L2验证器的gas成本，同时合约代码和数据的分离也更加方便链上数据分析工具的工作。

• EIP 3670：

• 简介：基于 EIP-3540 ，目的是确保 EOF 合约的代码是符合格式有效的，对于不符合格式的合约会阻止其部署，不会影响 Legacy bytecode。

• 意义：在由 3540 引入的 container 基础上，EIP-3670 确保 EOF 合约中的代码是有效的，或者防止它被部署。这意味着未定义的操作码不能被部署在 EOF 合约中，这有一个额外的好处，即减少所需增加的 EOF 版本数量。

• EIP 4200：

• 简介：

• 引入了第一个 EOF 专用的 opcode：RJUMP、RJUMPI 和 RJUMPV，它们 encode destinations as signed immediate values。编译器可以使用这些新的 JUMP 操作码来优化部署和执行 JUMP 时的 gas 成本，因为它们消除了现有 JUMP 和 JUMPI 操作码在做 jumpdest analysis 时所需的运行时间。这个 EIP 是对 dynamic jump 的补充。

• 和传统的 JUMP 操作比，区别在于 RJUMP 等操作不是指定一个具体的 offset 位置，而是指定一个相对的 offset 位置（从 dynamic jumps -> static jumps），因为很多时候 static jumps 就够了。

• 意义：优化网络和降低成本。

• EIP 4750：

• 将 4200 的功能更进一步：通过引入 CALLF and RETF两个新的 opcode，为无法用 RJUMP、RJUMPI 和 RJUMPV 代替的情况实现了替代方案，以此实现了在 EOF 合约中再也不需要 JUMPDEST 了，也就因此禁止了 dynamic jump。

• 意义：优化代码，方式是通过将代码划分为几个部分来实现的。

• EIP 5450：

• 背景：背景仍然是以太坊的合约现在在部署的时候是不检查的，只有在运行的时候才会进行一系列的检查，栈有没有溢出（上限 1024），gas 够不够之类的。

• 内容：为 EOF 合约添加了另一个有效性检查，这次是围绕堆栈（stack）。这个 EIP 可防止 EOF 合约部署可能导致堆栈下溢或溢出的情况（stack underflows / overflows）。这样，客户端可以减少他们在执行 EOF 合约期间进行的有效性检查的数量。

• 意义：一大改进就是让这些执行的时候才发生的检查尽可能的少，更多的检查都在合约部署的时候就发生。

5月26日开发者会议更新后，与EIP 4844有关的交易类型从SSZ到RLP的变化意味着不再需要坎昆的两个SSZ EIPs，因此EIPs 6475和6493被移出坎昆升级

EIP 6475X

• 简介：EIP 4844 的配套提案。Proto-danksharding 引入一个使用 SSZ 编码的新交易类型，而不是其他交易类型所使用的 RLP 编码方式。

• 更新：在第 161 次以太坊执行层核心开发者会议中，关于EIP 4844 的 SSZ 序列化格式的讨论显示，最初开发者倾向于通过 blob 事务向 EL 引入 SSZ 格式的早期迭代，最终开发者计划将所有交易类型从 RLP 升级至 SSZ，但鉴于其路径不明确且肯定无法在坎昆升级上实施，开发者一直在权衡从 EIP-4844 中删除 SSZ。经过多次讨论，开发者同意将 SSZ 从 EIP-4844 的 EL 实现中移除，但目前并未对EIP6475做出移除的行为。5月26日更新后，SSZ-> RLP 的变化将意味着不再需要坎昆的两个 SSZ EIPs: 因此 EIPs 6475和6493将被移出坎昆升级。

EIP 6493X

• 简介：SSZ交易签名方案。该 EIP 为简单序列化 (SSZ)编码交易定义了签名方案，将解决节点应如何处理在CL上以SSZ格式进行格式化但在EL上编码不同的blob交易类型。这个EIP是更新以太坊序列化格式以实现跨层一致性内容的一部分；

• 背景：SSZ changes

• 简介：Simple SerialiZe，是信标链上使用的序列化方法。

• SSZ changes还包括另外三种配套提案，此次只引入了6465.

• EIP 6465：SSZ 取款根，定义了现有 Merkle-Patricia Trie (MPT) 承诺向简单序列化 (SSZ)提款的迁移过程；

• EIP 6404 / EIP 6466：

• 二者均定义了一个将现有的 Merkle-Patricia Trie (MPT) 承诺迁移到简单序列化 (SSZ)的过程。

• EIP-6404 — SSZ 交易根

• EIP-6466 — SSZ 收据根

Tim Beiko 在5月26日的核心开发者会议中建议未来围绕扩大坎昆范围的对话仅限于以下五个EIP：EIP 5920、5656、7069、4788和2537，后续提案将在此范围中产生。后续EIP 5656和EIP 4788被确认为正式升级的提案，5920、7069和2537被移出，其中EIP 5920 是由于开发者担心转移ETH的方式可能存在的潜在副作用，以及暂未完成的推理、测试和安全工作，所以从升级中移除。

EIP 5920：X

• 简介：支付操作码。引入新的操作码 PAY用于以太坊传输，无需调用其任何函数即可将以太币发送到地址。

• 原因：目前，向一个地址发送以太需要用户调用该地址的一个函数，这有几个问题：

• 首先，它打开了一个重入攻击的载体，因为接收者可以回调到发送者那里；

• 其次，它打开了一个DoS向量，所以父函数必须认识到接收者可能会耗尽 gas 或回调；

• 最后，CALL操作码对于简单的以太传输来说是不必要的昂贵，因为它需要扩展内存和堆栈，加载接收者的全部数据，包括代码和内存，最后需要执行一个调用，可能会做其他无意的操作。

• 更改：

• 引入了一个新的操作码：( PAY) PAY_OPCODE，其中：

• 从堆栈中弹出两个值：addrthen val。

• 将 wei 从执行地址转移val到地址addr。如果addr是零地址，valwei 则从执行地址烧录。

• 潜在隐患：现有合约被使用时将不依赖于他们钱包的实际余额，因为已经可以在不调用它的情况下将以太币发送到一个地址。

• 意义：节省 gas。

• 更新：23年6月9日，由于担心转移 ETH 的方式可能存在的潜在副作用，以及通过提案需要进行的推理、测试和安全工作，PAY 从升级中移除。

EIP 7069X

• 简介：修改后的 CALL 指令

• 更改：引入三个新的调用指令，CALL2、DELEGATECALL2和STATICCALL2，具有简化语义的作用。旨在从新指令中删除gas可观察性，并为不受重定价影响的新类别合约打开大门。

• 背景：

• 63/64th 规则：限制 call 深度且确保调用者在被调用者返回后有剩余的gas来进行状态改变；

• 在引入第63/64条规则之前，需要稍微准确地计算呼叫方的可用gas。Solidity有一个复杂的规则，它试图估计调用者一方执行调用本身的成本，以便设置一个合理的gas值。

• 目前引入63/64th 规则：

• 删除了call 深度检查；

• 确保在执行被调用行为之前，至少保留5000个gas；

• 确保至少有2300个gas可供被调用行为使用。

• 津贴规则：如知名的2300津贴，当一个合约调用另一个合约时，被调用的合约会得到 2300 gas 用于执行非常有限的操作（足够做一点计算和生成一条日志，但不够写满一个存储槽），由于它设置的是固定的 gas 数量，因此只要 gas 价格可以调整，人们就没有办法确定这些 gas 到底能支持什么类型的计算。

• 意义：为未来引入 EOF 铺路，同时更加便捷大型合约的运行。

• 移除 gas 可选性：新指令不允许指定 gas limit，而是依赖“63/64th 规则”（主要指 EIP-150 中用于大量 IO 操作的 Gas 重定价，提高了特定操作的 Gas 消耗量）来限制 gas，这个重要的改进是简化了围绕“津贴”的规则，无论是否发送该 value，调用者都不需要执行有关 gas 的计算；

• 引入新提案后，用户始终可以通过在交易中发送更多 gas（当然，会受区块 gas 限制）来克服 Out of Gas 错误。

• 以前在提高存储成本时 (如EIP-1884 增加某些操作码的 gas) 一些只向他们的调用发送有限数量的 gas 的合约被新的成本核算机制所打破。之前一些合约有一个 gas 上限，永久地限制了他们可以花费的气体数量，哪怕他们将其发送到他们的子调用中也无法解决，无论多少额外的 gas 都不能解决，因为 call 会限制发送的数量。

• 为引入 EOF 铺路：一旦引入 EVM 对象格式 (EOF)，就可以在 EOF 合约中拒绝旧的调用指令，确保它们基本上不受 gas 价格变化的影响。由于这些操作是消除气体可观察性所必需的，因此 EOF 将需要它们来代替现有指令；

• 更加便利的状态返回码：引入了返回更详细状态代码的便利功能：成功 (0)、还原 (1)、失败 (2)，且在未来可扩展。

EIP 2537：X

• 简介：BLS12-381 曲线操作的预编译。

• 改变：将 BLS12-381 曲线上的操作作为预编译添加到有效执行 BLS 签名验证和执行 SNARKs 验证等操作所必需的集合中。

• 意义：以太坊可以创建更安全的密码证明，并允许与信标链更好的互操作性。

PR 3175 曾被提及过，但未曾放入候选名单中，后续无讨论

PR 3175：X

• 简介：该提案将防止被惩罚的验证者在退出队列时提出区块。如果有超过50％的验证者因恶意行为而被惩罚，在被强制从网络中驱逐的同时，这些验证者仍然能够提出区块。开发者表示，更改此逻辑是一个相对较小的CL层更改，可以提供对“高故障模式”的保护。

• 根据 5 月 4 日的第 108 次以太坊核心开发者共识会议，PR 3175 处在格式化为 EIP 的过程中，将改为 EIP-6987，即出于安全考虑，防止罚没（slashed）验证节点被选为区块提议者。

未来

基于以上信息，我们得到了以下结论：

1.坎昆升级的主要目标按照优先级排序为，扩容，安全，省gas和互操作性：

• 扩容毫无疑问，是第一优先级（4844）；

• 安全和省 gas 为第二要义（6780、1153、5656 和 7045），同时兼顾一定的开发者体验；

• 第三为互操作性，如优化 dapp之间的联结、通信和互操作性（4788、7044 和 6988）；

• 预期数据：测试网 4844 可降低opside rollup 的 50%成本；EigenLayer 和 Celestia 的技术方案没有披露太多，无法评估其数据；Ethstorage 预估 DA 成本降至原先的5%；Topia 预期降低100~1000倍成本。

2.坎昆升级 到 Danksharding的未来2~5年，是DA层项目的黄金发展期

• Layer 2 的安全上限取决于其采用的 DA 层，Proto-Danksharding 通过更便宜的状态数据存储，将利好存储协议、模块化协议和 L1 存储扩展网络。

• 首先，Danksharding 回归到以太坊状态机的本质。 V神提到，以太坊共识协议的目的不是保证所有历史数据的永久存储。相反，目的是提供一个高度安全的实时公告板，并为其他去中心化协议留出空间进行更长期的存储 （The purpose of the Ethereum consensus protocol is not to guarantee storage of all historical data forever. Rather, the purpose is to provide a highly secure real-time bulletin board, and leave room for other decentralized protocols to do longer-term storage. ）；

• 其次，Danksharding 降低了DA 成本，但实际落地时间和数据可用性问题也需要解决。

• DA成本降低：在此次更新之前，将数据从 rollup 发布到以太坊主链需要调用 calldata，而调用此代码的 gas 费非常昂贵，是 layer 2 中最大的一笔支出，EIP 4844 通过引入数据 blob，作为 rollups 独有的额外数据空间，将大大减少存储成本，进而使 DA 成本降低。

• 实际落地时间长，且能够提升的 TPS 和降低的 gas 仍有限，所以利好 DA 层项目在后续的持续发展：

• 在 polynya有关 danksharding 的 Variable security data sharding 文章中，表明其落地需要2-5年；

• 即使落地，其能够提高的 TPS 和降低的 gas 量级仍有限：

• EIP 4844 目前支持6个Blob，未来扩容问题依靠 Danksharding 才能解决；

• 当前以太坊区块空间大概是 200 KB。到了 Danksharding 之后，在规范中计划的大小是 32 兆，约为是 100 倍的提升。目前以太坊的 TPS 为15左右，理想化状态下提升100倍后为1500左右，量级上并非有很大提升。

• 因此，落地时间长 + 实际改变有限将利好 DA 层项目，一些如Celestia、Eigenda 的 DA 项目仍可以在后续通过更便宜的成本和更快的 TPS 与 Danksharding 竞争，ETHstorage topia 等新DA项目也能填补落地前的市场空白。

• 技术问题，如数据存储和数据可用性问题也需要解决：

• DA 主要的成本有两个，一个是网络带宽的成本，另一个是存储成本，而 4844 本身并不解决存储问题和区块上链的带宽问题

• blob 会在以太坊共识层上存储约 3 周后被删除，若想达成存储完整历史记录和全部数据可用，目前的解决方案有：dapp 自身存储与自己相关的数据、以太坊门户网络（目前正在开发中）或区块浏览器等第三方协议进行存储、在 BitTorrent 中存储历史数据或个人用户的自发存储。

• 因此，Proto-Danksharding 将利好存储协议、模块化协议和 L1 存储扩展网络：

• 对于历史数据的调用需求使去中心化存储协议或第三方索引协议等将会多一条新的发展渠道；

• 后续模块化协议可以通过高速的 Rollup 执行交易，安全的结算层负责结算，低费用大容量的数据可用性层用负责保障；

• 利好 L1 存储扩展网络，如 Eth storage，其能以更低的存储成本提供可编程存储的二层解决方案。

3.坎昆升级利好L2多样性、L3、RAAS和 数据可用性等赛道

• L2 赛道分析：

• 头部Layer2，如Arbitrum Orbit、OP Stack、Polygon2.0、Fractal Scaling（StarkWare 旗下）和 HyperChain（zkSync 旗下）等5个项目会受益。blob 带来的存储减费会使之前一系列限制 layer 2 发展的成本和可拓展性问题得到大幅改善，大大增强数据吞吐量，解决费用问题后，头部 layer 2 将有机会继续部署针对特定功能、高度自定义化的多链并发的 L3 生态；

• 二线 Layer2 与主流 Layer2 在运营成本上的差距会被缩小，将给予一些小型项目更多的发展机会，如Aztec、Metis、Boba、ZKspace、layer2.finance等；

• 虽然模块化区块链项目的真实需求仍然有待验证，但多样化的编程语言仍然成为可能，比如 Starkware的Cario 、Move系语言、Wasm 支持的 C、c++、C# 和 Go系列语言，这样可以引入更多的 web2 开发者。

• Raas 赛道分析：

• Raas 本身优势在于高度定制化，定制化需求 > 单纯成本和效率，所以费用降低是定制化 Rollup 的一个较大利好。

• 但是 RAAS 赛道的问题是可能被 OverHype 了，甚至有对 RAAS 赛道本身的质疑。面对 5 个头部 layer2 的竞争，各种新的 DA 的出现，新项目能否构成一个赛道我们是要打一个问号的。

• 首先，头部 layer 2 应用链的部署优势在于网络框架的完整度和链间生态的安全性， RAAS 的优势在于其定制性和自由度；

• 但是目前 OP 和 ZK 系的 RAAS 技术壁垒不强，且短期内仍处于测试网阶段，无实际产品交互，考虑到 RAAS 的实际进展、技术形式和未来 layer3 的生态优势，RAAS 的实际需求存疑。

• OP 系：虽然 OP stack 的 bedrock 升级 + 4844 上线从成本和效率上带来了一定的⼩幅提升，但是该提升带来的吸引力不强；

• ZK系：目前龙头项目走ZKEVM 路线的较多，更加在意与以太坊的兼容性，所以电路设计就会牺牲一定的效率，在针对性上不如 OP 系。但是目前市面上的 ZK RAAS 大多依旧是使用龙头项目（如ZkSync）去 Fork 链，壁垒仍不强。

• 所以，短期内 OP RAAS 在 layer3 落地前仍有一定的发展空间，长期看来 ZK RAAS 和 layer3 可能是未来趋势。

• ZK RAAS 在 4844 后的成本劣势更大，其消耗的算力比 OP 要大很多，虽然其上传到 L1 的成本相较于 OP 更少，但这相比于证明过程的花费仅仅是杯水车薪，而 OP 就优势在于能在短期内快速搭建生态，在 layer3 落地前仍有一定的发展空间；

• 对于常规 defi 应用，NFT市场，转型 rollup 并非是一个硬性需求，仅对效率要求高的支付应用或游戏才对 rollup 有更强的需求。未来可能 defi 类项目会在 l2，social 类可能日常行为在 l3 或者链下，最后核心数据和关系放在 l2 上，gaming 类的项目有需求去 l3 或 rollup，但考虑到目前链游大多实质为资金盘，且代币无法对外流通带来了发展瓶颈，加上全链上游戏的萌发，l3 本身的生态吸引力要远远大于 rollup。

4.坎昆升级改善了开发者和用户体验

• 坎昆升级第二个重要提案 SELFDESTRUCT removal 将进一步提高以太坊安全性，同时对于删除后可能存在的程序性账户更新问题，准备引入新操作码 SETCODE 来改善此类情况；

• 坎昆升级的第三个提案 EIP 1153 增加了瞬态存储操作码，首先可以节省 gas，其次能解决帧间通信问题，最后为未来的存储设计铺路，如 Verkle 树将不需要考虑瞬时存储的退款问题；

• 坎昆升级的第四个提案EIP 5656 引入了 MCOPY 内存复制指令，可以更精确地复制代码词句，将提高约 10% 的内存副本性能；

• 坎昆升级的第五个提案为EIP 4788可以使以太坊网络中不同协议和应用程序之间的通信更加高效和安全，也允许质押池、桥接和 restaking 协议有更多无需信任的设计；

• 坎昆升级最新（23年6月15日）提议加入的以CL为中心的EIP升级还有：EIP 6988、EIP 7044、EIP 7045，分别在细节方面提升了以太坊的安全性和使用性，如改善质押者体验和提升网络安全性等。

• 被删除的提案中，SSZ-> RLP 的转变使两个 SSZ EIP（EIP 6475 和 EIP 6493）被移出坎昆升级；EOF 相关提案在被从上海升级中移出后再次从坎昆升级中移除，目前考虑可能直接在后期的日常升级中实现；EVMMAX 由于是一些与 EOF 实现相关的 EIP 子集，所以也和EOF一起被移出坎昆升级；考虑到转移 ETH 的方式可能存在的潜在副作用，以及通过提案需要进行的推理、测试和安全工作，EIP 5920从升级中移除。

5.与zkml和账户抽象的关系

对zkml影响不大

• ZKML 即零知识证明（Zero Knowledge）和机器学习（Machine Learning）的结合；区块链与 ML 模型的结合解决了机器学习的隐私保护及可验证性问题：

• 隐私保护：输入数据的保密，如使用大量个人信息作为数据喂给机器进行训练时，个人信息的保密就是一大需求；或模型参数作为项目的核心竞争力，也需要进行加密来维持竞争壁垒。诸如此类的信任问题存在时，ML 模型要想获得更大规模的数据和应用就会存在阻碍。

• 可验证性：零知识证明技术应用范围广泛，ZKP 可以让用户无需验证即可得知信息正确性。且由于机器学习模型需要大量计算，而 ML 模型可以通过 ZK-SNARK 生成证明，减少证明大小，缓解ML的算力需求问题。

• ZKML 的存储需求和 DA 关系不大：需要类似 Space and Time 这种单独的存储结构，其核心技术是“SQL 证明”新安全协议，简单来说就是一个位于区块链旁边的数据仓库，能让开发者以简单的 SQL 格式连接链上和链下数据并将结果直接加载到智能合约中；

• ZK-SNARKs 是 ZKML 中 ZK 的主要形式，能适配 ML 的链上算力需求，随着密码学的发展，尤其是递归的SNARK 证明会利好 ZKML 在链上的落地：

• ZK-SNARKs 具有高度紧凑性的特点，使用 ZK-SNARKs 能让证明者生成一个短证明，而验证者无需交互，只需进行少量的计算即可验证其有效性，这种仅需一次有证明者向验证者交互的性质，使 ZK-SNARKs 在实际应用中具有高效性和实用性，更加适配 ML 的链上算力需求。

• 目前不可能进行链上训练，链上仅能存储链外计算的结果：

• 当前 ML 的问题更多在于算力需求无法满足和算法限制（无法并行计算）导致的低性能，大模型 ZK 证明需要更高算力，链上无法支持，当下流行的 ZK-SNARKs 也仅支持小规模、较小计算量的 ML 零知识证明，即算力局限是影响 ZKML 区块链应用发展的关键因素，链上仅能做到存储链外计算的结果。

利好账户抽象

• 首先，坎昆升级能一定程度减少 ZK rollup 证明的费用：

• 当前 zkSync 的交易费取决于 3 方面：

• 验证者生成 SNARK 证明和进行验证所消耗的固定资源成本，该部分成本较高；

• 验证者将 SNARK 证明提交到以太坊主网时的 gas 费，这部分费用会因主网拥堵而相应增加；

• 用户支付给验证者的服务费用，包括交易确认、消息广播等。

• 所以，若引入 4844，主网拥堵导致的 gas 费增加问题将得到缓解，能一定程度减少 ZKP 证明的费用，虽然相较于生成证明的费用不多，但是考虑到目前 ZK 仍处于出初期，未来 ZK 系发展趋势仍不容小觑。

• 其次，账户抽象将传统的 tx 交易转变为 useroperation，再将 useroperations 用 ECDSA 打包成块，对链上存储占用相比于之前更多，所以对于存储的要求更高；

• 接着，账户抽象与 ZK rollup 可以相辅相成：

• 目前账户抽象的问题一是 Gas Fee 贵，由于步骤过多，且牵扯到智能合约，所以数据多，进而导致 Gas Fee 贵，而 ZK Rollup 优势就在于能减少数据；

• 账户抽象导致安全性难以保证：由于 AA 涉及多个合约，安全性是问题，但是未来 L2 逐步成型后，共识层将不再改动，智能合约会有更多用武之地，账户抽象的安全性也可得到保障，借助 ZK rollup 的可信验证，安全性将会有更大提升。

• 最后，考虑到 AI 技术的崛起，能帮助增强链上合约的安全性和优化链上交易或活动步骤：

• AI 与安全性：AI 技术可以用于增强链上交易的安全性和隐私保护。例如Web3安全平台 SeQure 就利用AI检测和防止恶意攻击、欺诈行为和数据泄露，并提供实时监控和警报机制，确保链上交易的安全性和稳定性；

• AI 与链上活动优化：区块链上的活动包括交易、合约执行和数据存储等。通过AI的智能分析和预测能力，可以更好地优化链上活动，提高整体效率和性能。AI可以通过数据分析和模型训练，帮助识别交易模式、检测异常活动，并提供实时建议以优化区块链网络的资源分配。

• 因此，坎昆升级将从存储空间的扩大，到与 ZK rollup 的相辅相成，再到与 AI 技术的结合，逐步利好账户抽象未来的发展。

6.回看以太坊路线图，接下来是什么

• 目前来看，Layer2 还没有类似于 Solana 的性能（在延迟和吞吐量方面），也没有像 Near 这样的分片性能，也没有像 Sui 和 Aptos 这样的并行执行性能，坎昆升级提升了以太坊作为领导者的领先地位；

• 坎昆升级之后，预估几个重大的开发时间 Fully-Danksharding（2~5年），MEV 和 PBS落地（1~3年），账户抽象（1~2年），ZK 一切（3~6年），EOF和开发者体验（看延期几次？）。

The Scourge

• 目标：重点是解决 MEV 问题。

• 方案：通过「提议者构建者分离（PBS）」来达成应用层的 MEV 最小化，此时可能会对 blob 做出优化，并引入预确认服务或抢跑保护等。

• PBS即出块者和排序者分离。排序者只负责排序不管上链，出块者不管交易，直接选排序者打好的包上链。这个流程会让整个过程更加流程正义，缓解MEV问题，是 MEV 外部化的思路。

• PBS目前完成度仍然很低，比较成熟的是 外部 MEV 解决方案合作——flashbots 的 mevboost。

• 进阶版的「Enshrined Proposer-Builder Separation（ePBS）」完成度更低周期更长，估计短期内无法见到落地，另外还有渐进版本的 PEPC 和 Optimistic Relaying ，增强了 PBS 框架的灵活性和适应性

The Verge

• 目标：利用 Verkel 树取代 Merkle ，引入信任最小化的解决方案，使轻节点获得与全节点一样的安全保障，让区块验证尽可能简单和轻便。

• 同时，L1 的 ZK 化明确地加入 Verge 路线图之中 ZK 将是未来扩容和提速的大势所趋；

• 方案：引入 zk-SNARKs ，代替旧的证明系统，包括基于 SNARK 的轻客户端；共识状态变化的 SNARKs；Enshrined Rollups。

• Verkle 树是一种专门针对状态的 Merkle 树的更有效的替代方法，它不需要提供每个姐妹节点（共享同一个父节点的节点）到所选节点的路径，而只是提供路径本身作为证明的一部分，Verkle 证明的效率比 Merkle 证明高 3 倍。

• Enshrined Rollup 是指在 L1 上拥有某种共识集成的 Rollup，优点在于继承了 L1 的共识，无需治理代币来执行 rollup 升级，同时通过在链外进行计算并只将结果发布到区块链上，可以提升交易数量，不过实现的技术难度较大。未来这些 rollup 组合在一起，将能满足未来几十年区块链生态系统中的大部分需求。

The purge

• The Purge 指的是通过降低参与验证网络的存储要求来简化协议的目标。这主要是通过对历史和状态的休眠和管理来实现的。历史数据休眠（EIP-4444）允许客户端修剪超过一年的历史数据，并停止在 P2P 层面提供服务。

• 状态休眠。当涉及到处理状态增长时，有两个主要目标：弱无状态，指的是只使用状态来建立区块，但不验证它的目标；状态休眠，指删除在规定时间内（1 年）未被访问的状态。状态休眠应该使节点需要存储的状态总共减少 20-50 GB。

• 在第五个阶段 Purge中，EIP 4444 被明确写入 Roadmap，EIP-4444 要求客户端清除超过 1 年的数据，同时该阶段还有一些 EVM 优化的工作，如简化 GAS 的机制和 EVM 预编译等；

The Splurge

• 最后的第六阶段 Splurge 中，EIP 4337 也被提及，作为钱包生态的长期布局提案，账户抽象未来将会进一步提高钱包易用性，包括使用稳定币支付 gas、社交恢复钱包等；

参考资料：

• 以太坊核心开发者会议更新：https://www.galaxy.com/authors/christine-kim/

• Ethereum All Core Developers Call #148 Writeuphttps://www.galaxy.com/research/insights/ethereum-all-core-developers-call-148/

• Ethereum All Core Developers Call #149 Writeup https://www.galaxy.com/research/insights/ethereum-all-core-developers-call-149/

• Ethereum Consensus Layer Call #99 Writeuphttps://www.galaxy.com/research/insights/ethereum-consensus-layer-call-99-writeup/

• Ethereum All Core Developers Call #150 Writeuphttps://www.galaxy.com/research/insights/ethereum-all-core-developers-call-150-writeup/

• Ethereum All Core Developers Call #151 Writeuphttps://www.galaxy.com/research/insights/ethereum-all-core-developers-call-151/

• Ethereum Consensus Layer Call #100 Writeuphttps://www.galaxy.com/research/insights/ethereum-consensus-layer-call-100/

• Ethereum All Core Developers Execution Call #152 Writeuphttps://www.galaxy.com/research/insights/ethereum-all-core-developers-execution-call-152/

• Ethereum All Core Developers Execution Call #153 Writeuphttps://www.galaxy.com/research/insights/ethereum-all-core-developers-execution-call-153/

• Ethereum Magicians 论坛讨论原文：https://ethereum-magicians.org/t/cancun-network-upgrade-meta-thread/12060

• Ethereum All Core Developers Execution Call #156 Writeuphttps://www.galaxy.com/research/insights/ethereum-all-core-developers-execution-call-156/

• Ethereum All Core Developers Execution Call #157 Writeuphttps://www.galaxy.com/research/insights/ethereum-all-core-developers-execution-call-157/

• Ethereum All Core Developers Execution Call #158 Writeuphttps://www.galaxy.com/research/insights/ethereum-all-core-developers-execution-call-158/

• Ethereum All Core Developers Execution Call #159 Writeuphttps://www.galaxy.com/research/insights/ethereum-all-core-developers-execution-call-159/

• Ethereum All Core Developers Execution Call #160 Writeuphttps://www.galaxy.com/research/insights/ethereum-all-core-developers-execution-call-160/

• Ethereum All Core Developers Consensus Call #108 Writeuphttps://www.galaxy.com/research/insights/ethereum-all-core-developers-consensus-call-108/

• Ethereum All Core Developers Execution Call #161 Writeuphttps://www.galaxy.com/research/insights/ethereum-all-core-developers-execution-call-161/

• Ethereum All Core Developers Consensus Call #109 Writeuphttps://www.galaxy.com/research/insights/ethereum-all-core-developers-consensus-call-109/

• Ethereum All Core Developers Execution Call #162 Writeuphttps://www.galaxy.com/research/insights/ethereum-all-core-developers-execution-call-162/

• Ethereum All Core Developers Consensus Call #110 Writeuphttps://www.galaxy.com/research/insights/ethereum-all-core-developers-consensus-call-110/

• Tim 关于最新的以太坊坎昆升级推文（23年6月9日）：https://twitter.com/TimBeiko/status/1666908046994608128

• 以太坊所有核心开发者共识电话会议 #111 Writeuphttps://www.galaxy.com/research/insights/ethereum-all-core-developers-consensus-call-111/

• Ethereum All Core Developers Consensus Call #112 Writeuphttps://www.galaxy.com/research/insights/ethereum-all-core-developers-consensus-call-112/

• 以太坊升级相关内容：

• 自毁代码的简介：https://www.wtf.academy/solidity-advanced/DeleteContract/

• 探索 EVMMAX 提案和 BLS12-381https://etherworld.co/2023/03/27/exploring-evmmax-proposals-bls12-381/

• 除了EIP-4844 坎昆升级还会包含哪些内容？速览以太坊最新共识电话会议https://www.fx168news.com/article/193393

• 以太坊上海升级，又增加了哪些新内容？https://foresightnews.pro/article/detail/21520

• 推文：https://twitter.com/xiangganzi/status/1588367511577194496

• OKX Ventures:以太坊上海升级后，坎昆升级潜在投资机会 - Foresight News

• 除了备受瞩目的EIP-4844，坎昆升级还会包含哪些提案？https://www.panewslab.com/zh/articledetails/4qlg59ty.html

• V神：值得考虑删除的 EVM 功能https://www.jinse.com/blockchain/1020439.html

• Proto-Danksharding FAQ https://notes.ethereum.org/@vbuterin/proto_danksharding_faq#What-is-Danksharding

• V 神推荐丨深入了解以太坊的分片路线图，看这一份报告就足够https://www.8btc.com/article/6755560

• 一文读懂以太坊新升级方案Dankshardinghttps://mirror.xyz/mtyl.eth/TbLbRI1VcDZYxkHJOBhB319oaYxnV5_DmqXl6xLfcWM

• 解读 Ethereum 最新路线图中的有趣事实和隐含密码https://web3caff.com/zh/archives/40114

• Vitalik：为什么说SELFDESTRUCT对以太坊的生态弊大于利https://www.8btc.com/article/6610829

• 以太坊愿景：https://ethereum.org/zh/roadmap/vision/

• Blockworks Research 研究员 Brrr ： Proto-Danksharding 如何加速以太坊的 L1 Rollup 可扩展性
  https://twitter.com/blockworksres/status/1671604147437834240

• 第111次以太坊ACDC会议：讨论Deneb升级最终范围以及EIP-7044等三项提案https://www.theblockbeats.info/flash/150732

• KOL Stacy Muur 速览以太坊扩展解决方案演变：OP Stack、Arbitrum Orbit、Polygon 2.0https://twitter.com/stacy_muur/status/1674091705300312066

• 三类Rollups横向对比：经典Rollups（Optimistic/ZK Rollups）、Enshrined Rollups、Sovereign Rollupshttps://news.marsbit.co/20230627082034175777.html

• [AMA] We are EF Research (Pt. 8: 07 July, 2022)：https://www.reddit.com/r/ethereum/comments/vrx9xe/ama_we_are_ef_research_pt_8_07_july_2022/

• 2023值得重新思考的3大热门赛道https://finance.sina.cn/blockchain/2023-04-12/detail-imyqawtq3942364.d.html

• 黑山 EDCON 2023 结束后的思考：基础设施和应用趋势前瞻https://www.techflowpost.com/article/detail_12307.html

• AI 与 Web3 结合可能性的无限遐想https://www.techflowpost.com/article/detail_12169.html

• AI+Web3：探索人工智能和区块链的融合之路https://www.techflowpost.com/article/detail_12141.html

• 对比 zk-rollup 和 op-rollup：从验证方式分析为何当前 zkSync Gas 费偏高https://www.techflowpost.com/article/detail_11778.html

• “卷上加卷”：Rollup时代的账户抽象解决方案https://www.panewslab.com/zh/articledetails/pbx0zoiw.html

• 深度解读ZKML：技术原理、应用场景、优势和挑战https://www.odaily.news/post/5188011

• ZKML：将AI和区块链融合，实现隐私保护的模型部署技术https://www.techflowpost.com/article/detail_12011.html

• Variable security data shardinghttps://polynya.mirror.xyz/xJUgtU5mArDwz0MXIyxM_wAYDKy5parhUfqb2Z24ErI

• 对话 EthStorage 创始人 Qi Zhou | 数据可用性和去中心化存储https://mp.weixin.qq.com/s/1K8ue0jkER_QuXXsZUNbRw

• 一文读懂最新版以太坊发展路线图https://foresightnews.pro/article/detail/20815

• 关于Space and Time的简单介绍https://mirror.xyz/200070.eth/1nzH8lYGrmt7T4ellNou0kKRfQXaKpxBb7D4caIqoPA

• 提案原文：

• EIP 4844：https://eips.ethereum.org/EIPS/eip-4844

• EIP 6780：https://eips.ethereum.org/EIPS/eip-6780

• EIP 1153：https://eips.ethereum.org/EIPS/eip-1153

• EIP 5920：https://eips.ethereum.org/EIPS/eip-5920

• EIP 5656：https://eips.ethereum.org/EIPS/eip-5656

• EIP 7069：https://github.com/ethereum/EIPs/pull/7069

• EIP 4788：https://eips.ethereum.org/EIPS/eip-4788

• EIP 2537：https://eips.ethereum.org/EIPS/eip-2537

• EVMMAX EIPs：

• EIP 6601：https://ethereum-magicians.org/t/eip-6601-evm-modular-arithmetic-extensions-evmmax/13168

• EIP 6990：https://github.com/jwasinger/EIPs/blob/evmmax-no-eof/EIPS/eip-6690.md

• EOF changes：

• EIP 663：https://eips.ethereum.org/EIPS/eip-663

• EIP 3540：https://eips.ethereum.org/EIPS/eip-3540

• EIP 3670：https://eips.ethereum.org/EIPS/eip-3670

• EIP 4200：https://eips.ethereum.org/EIPS/eip-4200

• EIP 4750：https://eips.ethereum.org/EIPS/eip-4750

• EIP 5450：https://eips.ethereum.org/EIPS/eip-5450

• EIP 6475：https://eips.ethereum.org/EIPS/eip-6475

• EIP 6493：https://eips.ethereum.org/EIPS/eip-6493

• PR 3175：https://github.com/ethereum/consensus-specs/pull/3175