以太坊坎昆升级临近，回顾坎昆升级的前生、今生和未来

作者：胖鸟财经

前世

为什么需要坎昆升级？

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

以太坊的问题：

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

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

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

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

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

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

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

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

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

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

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

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

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

下一步重点是以太坊路线图中的TheSurge 。

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

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

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

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

分片方案解析：

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

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

分片方案分为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类，分别是共识层会议和执行层会议，两者隔周交替举行：

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

23年4月13日的核心开发者会议中，开发人员讨论了EIP4844（用于在EL中公开有关CL状态根的数据），除此之外，还有至少九个其他EIP被考虑纳入升级，分别是EIP4844、SELFDESTRUCT移除（EIP-6780、EIP4758、EIP6046、EIP6190）、EIP5920、EIP1153、EIP2537、EIP4788、EVMMAXEIPs（EIP6601和EIP6690）、SSZchanges（EIP6475、EIP6493、EIP6465、EIP6404 和EIP6466 ）、EIP5656 和EIP6193；

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

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

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

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

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

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

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

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

2023年6月13日的核心开发者会议中，开发者们正式确认了升级范围，包括EIP4844、EIP1153、EIP5656、EIP6780、EIP4788；

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

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

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

今生

核心内容是EIP4844，即Proto-Danksharding

此次坎昆升级最终确定的EIP范围为：EIP4844、EIP1153、EIP5656、EIP6780、EIP4788。同时在6月19日的第111次以太坊ACDC会议中，开发者们继续讨论了EIP6988、EIP7044、EIP7045，以便在Deneb中纳入。开发者们表示，计划在未来几周内将上述三个EIP合并到Deneb规范中。

重点EIP的分析

EIP4844

简介：

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

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

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

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

Blob简介：

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

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

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

节点同步链上的BlobTransaction 后，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天有效期）的问题。解决方式：

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

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

DAS采用了两个技术：纠删码（ErasureCoding）和KZG多项式承诺（KZGCommitment）；

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

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

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

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

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

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

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

节点同步数据时会从提议者（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解决方案来说有一定影响。

意义：

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

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

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

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

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

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

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

SELFDESTRUCTremoval EIP-6780：X

背景：

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

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

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

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

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

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

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

EIP1153X

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

原因：

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

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

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

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

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

潜在用例：

reentrancylock；

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

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

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

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

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

意义：

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

解决帧间通信问题；

不改变现有操作的语义；

使用后无需清除存储槽；

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

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

EIP4788：X

简介：EVM中的信标块根。

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

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

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

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

EIP5656X

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

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

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

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

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

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

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

候选名单EIP

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

EIP6988：X

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

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

EIP7044：X

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

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

EIP7045：X

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

意义：加强网络安全性。

删除EIP的分析

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

EVMMAXEIPs：

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

EIP6601：EVM模块化算术扩展(EVMMAX)

改变：是EIP5843的迭代，与EIP5843的区别在：

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验证的成本。

EIP6690：

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

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

EOFchanges：

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

EIP663：

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

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

EIP3540：

简介：

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

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

意义：

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

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

EIP3670：

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

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

EIP4200：

简介：

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

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

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

EIP4750：

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

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

EIP5450：

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

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

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

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

EIP6475X

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

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

EIP6493X

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

背景：SSZchanges

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

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

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

EIP6404/ EIP6466：

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

EIP-6404— SSZ 交易根

EIP-6466— SSZ 收据根

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

EIP5920：X

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

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

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

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

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

更改：

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

从堆栈中弹出两个值：addrthenval。

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

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

意义：节省gas。

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

EIP7069X

简介：修改后的CALL指令

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

背景：

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

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

目前引入63/64th规则：

删除了call深度检查；

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

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

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

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

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

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

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

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

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

EIP2537：X

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

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

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

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

PR3175：X

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

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

未来

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

L2赛道分析：

头部Layer2，如ArbitrumOrbit、OPStack、Polygon2.0、FractalScaling（StarkWare旗下）和HyperChain（zkSync旗下）等5个项目会受益。blob带来的存储减费会使之前一系列限制layer2 发展的成本和可拓展性问题得到大幅改善，大大增强数据吞吐量，解决费用问题后，头部layer2 将有机会继续部署针对特定功能、高度自定义化的多链并发的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的出现，新项目能否构成一个赛道我们是要打一个问号的。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

对zkml影响不大

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

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

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

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

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

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

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

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

利好账户抽象

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

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

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

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

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

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

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

接着，账户抽象与ZKrollup 可以相辅相成：

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

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

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

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

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

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

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

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

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

TheScourge

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

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

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

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

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

TheVerge

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

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

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

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

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

Thepurge

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

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

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

TheSplurge

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