前世
为什么需要坎昆升级？
以太坊的愿景为：在去中心化的前提下变得更具有可扩展性且更安全。当前以太坊的升级也致力于解决这个三难问题，但是一直面临着很大的挑战。
以太坊的问题：
目前出现了TPS和性能较低，gas费高且拥堵严重的情况，同时，运行一个以太坊客户端所需的磁盘空间也在快速增长，在底层，确保以太坊安全和去中心化的工作量共识算法对整个环境的影响也愈发显著。
所以，在去中心化的前提下，如何传输更多的数据并降低gas，来增强可拓展性，如何优化共识算法，来保障安全性，都是以太坊目前正在做的努力。
以太坊路线图怎么规划的？
最近几次重要的升级及其目标
完成了经济模型和POS相关的升级，接下来几次升级解决了以太坊的性能、TPS和开发者体验的问题；
主要有2个方案，链上和链下：
链下方案：指Layer2，包括rollup等，
链上方案：指直接在L1中进行更改，也就是热门的分片方案，分片简单理解就是将所有节点划分成不同片区，完成每个片区的任务，这将有效提升速度；
分片方案解析：
分片（Sharding）方案的困境：曾经的Sharding包括状态分片，交易分片等，但是出现不同分片之间的同步是个难题，目前想要完成大范围的网络节点数据同步，技术难度大，不仅无法解决MEV的情况，且可能需要大量补丁来弥补可能出现的各类问题，短期无法实现。
内容：proto-danksharding的主要特性是引入新的blob交易类型，Blob具有容量大且便宜的特点，给以太坊外接此类数据包，能让rollup的数据全部存入blob，大大缓解主链的存储压力，同时也能降低rollup的费用。
Fully-Rollup
介绍：rollup全面扩容，重点在于数据可用性的利用。
DAS的P2P设计：涉及数据分片网络连接问题的一些工作以及研究；
数据可用性采样客户端：开发轻量级客户端，可以通过对几千字节的随机采样快速判断数据是否可用；
有效的DA自我恢复：能够在最恶劣的网络条件下有效地重建所有数据（比如，恶意验证者攻击、或者大块节点的长时间停机）。
以太坊核心开发者会议
以太坊的每一次升级都依赖于核心开发者会议，通过核心贡献者的共同讨论，根据开发者们的一系列提案，决定未来的发展方向
定义：核心开发者会议是以太坊开发社区每周举行的一次电话会议，来自不同组织的核心贡献者共同讨论技术问题并协调以太坊的未来工作。它们决定了以太坊协议的未来技术走向，同时也是真正进行以太坊升级决策的权力机构，负责决议，EIP是否被纳入升级，是否需要进行路线图变更等重要事项。
核心流程：以EIP为中心的升级流程大致如下，首先在核心开发者会议（简称ACD）上初步接纳一个EIP，然后客户端团队无论该EIP被纳入升级与否，都对其进行测试，并在最终测试完后进行再一次回顾，再根据探讨决定最终是否纳入实际升级中。
会议分2类，分别是共识层会议和执行层会议，两者隔周交替举行：
以太坊核心维护者有3类，主要是一些讨论提案的官方组织或者志愿者论坛：
AllCoreDevs：代码维护者，负责ETH1网络客户端，升级，维护以太坊代码和核心架构；
“项目管理”部分：支持以太坊开发人员、协调硬分叉、监控EIP等，以及直接帮助AllCoreDevs负责通信和运营；
坎昆升级相关会议的时间线
按照讨论内容划分，本次坎昆升级可粗略分为5个阶段。
第一个阶段——引入升级主题
引出新任务proto-danksharding、EOF和“selfdestruct”操作码，粗浅讨论上海升级内容
以太坊在22年9月15日完成合并后，开发者会议暂停4周，为开发者留取一个月的时间查看后续升级所讨论的EIP；
第二个阶段——确定时间范围和KZG仪式的准备
22年11月，在以太坊所有核心开发者电话会议#149中，已经提及EOF或proto-danksharding，此时开发者们仍考虑将其放置在上海升级中；
23年1月5日的核心开发者会议中，开发者们就从上海升级中移除与EOF实现有关的代码修改达成共识，Beiko此时建议在两周之后再决定是否应将EOF包括在坎昆升级中；
第三个阶段——初步讨论提案的范围
23年1月20日的核心开发者会议中，EOF被移入坎昆升级；
第四个阶段——确定明确的提案升级方向，删除无关提案
23年4月12日，以太坊上海升级已完成；
第五个阶段——最后的提案确定和细节完善
23年5月18日的开发者共识会议中简要讨论了4844的进展，如允许EL上的智能合约应用程序验证CL状态的证明；
今生
重点EIP的分析
简介：
Blob简介：
可能会对网络稳定性产生一定影响，但是以太坊开发团队仍决定先行测试，避免后续需要硬分叉来拓展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天有效期）的问题。解决方式：
将Blob中的数据切割成数据碎片，并且让节点由下载Blob数据转变为随机抽查Blob数据碎片，让Blob的数据碎片分散在以太坊的每个节点中，但是完整的Blob数据却保存在整个以太坊账本中，前提是节点需要足够多且去中心化；
提议者-打包者分离（PBS）——解决了节点的工作分工问题，让性能配置高的节点负责下载全部数据进行编码分发，让性能配置低的节点来负责抽查验证。
性能配置高的节点可以成为打包者（Builder），打包者只需要负责下载Blob数据进行编码并创建区块（Block），然后广播给其他的节点来进行抽查，对于打包者（Builder）来说，因为同步数据量和带宽要求较高，所以会相对中心化；
抗审查清单（crList）——解决了对于打包者而言因其审查权力过大，就可以故意忽略掉某些交易并且随意排序并插入自己想插入的交易去获取MEV的问题。
在打包者（Builder）打包区块交易之前，提议者（Proposer）会先公布一个抗审查清单（crList），这个crList中包含着mempool中的所有交易；
节点同步数据时会从提议者（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解决方案来说有一定影响。
proto-danksharding是用来实现完整Danksharding规范的“支架”(即交易格式和验证规则)提案：不过目前还没实现任何分片，所有验证者和用户仍需要直接对完整数据的可用性进行直接验证；
虽然实现完整分片(有数据可用性采样等)是一项很复杂的任务，而且实现proto-danksharding后还有很复杂的工作，但这些复杂性都会控制在共识层上。一旦proto-danksharding部署了，执行层客户端团队、rollup开发者和用户在过渡到完整分片时都不需要做任何额外的工作了。
要实现完整分片，需要完成PBS、委托证明和数据可用性采样的实际实现，不过此类修改都将集中于CL层，无需开发者进行再调整：目前4844实现了一种新的交易类型，与完整分片里需要的交易格式、共识交叉验证逻辑和执行层逻辑等完全相同，也衍生出了用于blob的、自我调整的独立gas定价，未来要实现完整分片，需要完成PBS、委托证明和数据可用性采样的实际实现，不过这些修改仅在CL层，不需要EL层或rollup开发者进行修改，便利开发者。
背景：
在21年3月，Vitalik就提出SELFDESTRUCT对以太坊生态弊大于利，主要原因在于它是唯一一个能在单个区块中变更无限个状态对象、导致合约代码变动、能未经账户同意就能修改账户余额的操作码，对于以太坊安全中有很大隐患；
在链上唯一移除一个合约的办法就是SELFDESTRUCT。如果在合约里面调用：selfdestruct函数即可自毁合约。存在合约中的以太坊将会发送到设计好的地址里。剩下的代码和存储变量将会在状态机中被移除。其实合约销毁这个动作理论上听上去是个好主义，但实际上是很危险的。selfdestruct函数虽然能在紧急情况下帮助开发人员删除智能合约并将合约内的余额转移到指定的地址，但这一特性也被不法分子利用，使它成为了攻击手段。
简介：selfdestruct是智能合约的紧急按钮，销毁合约并将剩余ETH转移到指定账户。
原因：原先操作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兼容，使其只引起有限数量的状态变化
更改：不是在交易结束时销毁合约，而是在调用它的交易结束时发生以下情况：
合约代码设置为0x1，随机数设置为2^64-1。
如果调用被一个或多个别名合约转发后合约自毁，则将别名合约的第0th个存储槽设置为步骤2中计算的地址；
合约的余额将全部转移到堆栈顶部的地址；
堆栈的顶部被弹出。
旨在让SELFDESTRUCT可以后续形成Verkle树，同时进行最少的更改；
应用了EIP-2929的gas成本增加。
简介：瞬态存储操作码，添加用于操作与存储行为相同但在每次交易后丢弃的状态的操作码。
在以太坊中运行交易可以生成多个嵌套的执行框架，每个框架由CALL（或类似的）指令创建。可以在同一笔交易中重新输入合约，在这种情况下，不止一个框架属于一个合约。
目前，这些框架可以通过两种方式进行通信：通过CALL指令传递的输入/输出，以及通过存储更新。如果存在属于另一个不受信任的合约的中间框架，则通过输入/输出进行的通信是不安全的。
改变：EVM中添加了两个新的操作码，TLOAD(0xb3)和TSTORE(0xb4)。
瞬时存储对于拥有它的合约来说是私有的，就像持久存储一样，只有拥有合同框架才能访问其临时存储。当访问存储时，所有帧都会访问同一个临时存储，其方式与持久存储相同，但与内存不同。
潜在用例：
链上可计算CREATE2地址：构造函数参数从工厂合约中读取，而不是作为初始化代码哈希的一部分传递；
转账费用合约：向代币合约支付费用以在交易期间解锁转账；
“Till”模式：允许用户执行所有操作作为回调的一部分，并在最后检查“till”是否平衡；
代理调用元数据：在不使用调用数据的情况下将额外的元数据传递给实现合约，例如不可变代理构造函数参数的值。
节省gas，拥有更简单的gas计费规则；
解决帧间通信问题；
不改变现有操作的语义；
使用后无需清除存储槽；
未来的存储设计（例如Verkle树）不需要考虑瞬时存储的退款问题。
接着是4788，能减少对质押池的信任假设
简介：EVM中的信标块根。
更新：在23年6月15日的开发者会议中，开发者提出进行代码更改以改善质押者体验，该EIP将公开信标链区块的根，其中包含EVM内部链状态信息，供DApp开发者的信任最小化访问。
改变：在相应的执行负载头中提交每个信标链块的哈希根，同时将这些根存储在一个处于执行状态的合约中，并添加一个读取该合约的新操作码。
意义：这是一项代码修改提案，提议修改以太坊虚拟机（EVM）以使其能够公开合约层（CL）状态根在执行层（EL）的数据，可以使以太坊网络中不同协议和应用程序之间的通信更加高效和安全。允许质押池、桥接和restaking协议有更多无需信任的设计。
最后是5656，提供了一种高效的新的内存复制操作码，但是考虑到其测试带宽，目前处于暂时被包括进升级的状态
更新：23年6月9日，开发团队表示最初对MCOPY存在分歧，因为虽然其解决了安全问题，但仍担心将它添加到升级所需的实施+测试带宽，但是最后仍同意包含该EIP，但是如果开发者在测试或客户端遇到容量问题，就会考虑将其删除。因此，MCOPY处于暂时被包括进坎昆升级中的状态。
更改：提供了一种高效的EVM指令来复制内存区域。
意义：内存复制是一个基本操作，但在EVM上实现它需要成本。
随着MCOPY指令的可用性实现，可以更精确地复制代码词句，将提高约10.5%的内存副本性能，对于各种计算量大的操作非常有用；
对编译器生成更有效和更小的字节码也将会很有用；
可以节省一定的身份预编译的gas费用，但是并不能起到实际推进此部分实现的作用。
候选名单EIP
简介：防止被罚没的验证者被选为区块提议者。
意义：加大了违规节点的惩罚，将利好DVT。
简介：确保签名的验证器退出永久有效。
意义：可以一定程度上改善质押者体验。
意义：加强网络安全性。
删除EIP的分析
在23年4月29日的第160次以太坊ACDE会议中，EVMMAX和EOF被确认移出本次升级，与EOF相关的改动可能会在后续的日常升级中引入
简介：EVMMAX旨在为以太坊上的算术运算和签名方案带来更大的灵活性。目前，有两种EVMMAX提案，一种带有EOF，另一种不带EOF。
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-6990是从EIP-6601改编而来的提案，旨在不依赖EOF向EVM引入优化的模块化算术运算。虽然EIP-6601需要EIP-4750和EIP-3670作为依赖项，但EIP-6990提供了一个更独立的解决方案。它通过消除对EOF的依赖提供了一种更简化的方法。
意义：它保留了EIP-6601的核心功能，可以对高达4096位的奇数模数进行优化的模块化算术运算，这种简化允许更有效的实施和采用，同时仍然提供与EIP-6601相关的好处。
简介：无限制的SWAP和DUP指令
意义：通过引入了两个新指令：SWAPN和DUPN，它们与SWAP和DUP的区别在于堆栈深度从16个元素增加到256个元素
从前链上部署的EVM字节码都是没有一种预先定义的同一结构的，代码只有在客户端中被运行前才会被验证，这既是一种间接成本，也会阻碍开发者引入新功能或弃用老功能。
版本控制有利于以后实现引入或弃用新功能（例如引入账号抽象）；
合约代码和数据的分离对于L2的验证(op)有益，减少L2验证器的gas成本，同时合约代码和数据的分离也更加方便链上数据分析工具的工作。
意义：在由3540引入的container123rong基础上，EIP-3670确保EOF合约中的代码是有效的，或者防止它被部署。这意味着未定义的操作码不能被部署在EOF合约中，这有一个额外的好处，即减少所需增加的EOF版本数量。
意义：优化网络和降低成本。
意义：优化代码，方式是通过将代码划分为几个部分来实现的。
背景：背景仍然是以太坊的合约现在在部署的时候是不检查的，只有在运行的时候才会进行一系列的检查，栈有没有溢出（上限1024），gas够不够之类的。
意义：一大改进就是让这些执行的时候才发生的检查尽可能的少，更多的检查都在合约部署的时候就发生。
简介：SSZ交易签名方案。该EIP为简单序列化(SSZ)编码交易定义了签名方案，将解决节点应如何处理在CL上以SSZ格式进行格式化但在EL上编码不同的blob交易类型。这个EIP是更新以太坊序列化格式以实现跨层一致性内容的一部分；
简介：支付操作码。引入新的操作码PAY用于以太坊传输，无需调用其任何函数即可将以太币发送到地址。
原因：目前，向一个地址发送以太需要用户调用该地址的一个函数，这有几个问题：
首先，它打开了一个重入攻击的载体，因为接收者可以回调到发送者那里；
其次，它打开了一个DoS向量，所以父函数必须认识到接收者可能会耗尽gas或回调；
最后，CALL操作码对于简单的以太传输来说是不必要的昂贵，因为它需要扩展内存和堆栈，加载接收者的全部数据，包括代码和内存，最后需要执行一个调用，可能会做其他无意的操作。
引入了一个新的操作码：(PAY)PAY_OPCODE，其中：
从堆栈中弹出两个值：addrthenval。
将wei从执行地址转移val到地址addr。如果addr是零地址，valwei则从执行地址烧录。
潜在隐患：现有合约被使用时将不依赖于他们钱包的实际余额，因为已经可以在不调用它的情况下将以太币发送到一个地址。
意义：节省gas。
更新：23年6月9日，由于担心转移ETH的方式可能存在的潜在副作用，以及通过提案需要进行的推理、测试和安全工作，PAY从升级中移除。
简介：修改后的CALL指令
更改：引入三个新的调用指令，CALL2、DELEGATECALL2和STATICCALL2，具有简化语义的作用。旨在从新指令中删除gas可观察性，并为不受重定价影响的新类别合约打开大门。
63/64th规则：限制call深度且确保调用者在被调用者返回后有剩余的gas来进行状态改变；
在引入第63/64条规则之前，需要稍微准确地计算呼叫方的可用gas。Solidity有一个复杂的规则，它试图估计调用者一方执行调用本身的成本，以便设置一个合理的gas值。
目前引入63/64th规则：
删除了call深度检查；
确保在执行被调用行为之前，至少保留5000个gas；
确保至少有2300个gas可供被调用行为使用。
意义：为未来引入EOF铺路，同时更加便捷大型合约的运行。
以前在提高存储成本时(如EIP-1884增加某些操作码的gas)一些只向他们的调用发送有限数量的gas的合约被新的成本核算机制所打破。之前一些合约有一个gas上限，永久地限制了他们可以花费的气体数量，哪怕他们将其发送到他们的子调用中也无法解决，无论多少额外的gas都不能解决，因为call会限制发送的数量。
为引入EOF铺路：一旦引入EVM对象格式(EOF)，就可以在EOF合约中拒绝旧的调用指令，确保它们基本上不受gas价格变化的影响。由于这些操作是消除气体可观察性所必需的，因此EOF将需要它们来代替现有指令；
更加便利的状态返回码：引入了返回更详细状态代码的便利功能：成功(0)、还原(1)、失败(2)，且在未来可扩展。
简介：BLS12-381曲线操作的预编译。
改变：将BLS12-381曲线上的操作作为预编译添加到有效执行BLS签名验证和执行SNARKs验证等操作所必需的集合中。
意义：以太坊可以创建更安全的密码证明，并允许与信标链更好的互操作性。
简介：该提案将防止被惩罚的验证者在退出队列时提出区块。如果有超过50％的验证者因恶意行为而被惩罚，在被强制从网络中驱逐的同时，这些验证者仍然能够提出区块。开发者表示，更改此逻辑是一个相对较小的CL层更改，可以提供对“高故障模式”的保护。
未来
基于以上信息，我们得到了以下结论：
1.坎昆升级的主要目标按照优先级排序为，扩容，安全，省gas和互操作性：
扩容毫无疑问，是第一优先级（4844）；
安全和省gas为第二要义（6780、1153、5656和7045），同时兼顾一定的开发者体验；
第三为互操作性，如优化dapp之间的联结、通信和互操作性（4788、7044和6988）；
其次，Danksharding降低了DA成本，但实际落地时间和数据可用性问题也需要解决。
实际落地时间长，且能够提升的TPS和降低的gas仍有限，所以利好DA层项目在后续的持续发展：
即使落地，其能够提高的TPS和降低的gas量级仍有限：
技术问题，如数据存储和数据可用性问题也需要解决：
DA主要的成本有两个，一个是网络带宽的成本，另一个是存储成本，而4844本身并不解决存储问题和区块上链的带宽问题
blob会在以太坊共识层上存储约3周后被删除，若想达成存储完整历史记录和全部数据可用，目前的解决方案有：dapp自身存储与自己相关的数据、以太坊门户网络（目前正在开发中）或区块浏览器等第三方协议进行存储、在BitTorrent中存储历史数据或个人用户的自发存储。
因此，Proto-Danksharding将利好存储协议、模块化协议和L1存储扩展网络：
对于历史数据的调用需求使去中心化存储协议或第三方索引协议等将会多一条新的发展渠道；
后续模块化协议可以通过高速的Rollup执行交易，安全的结算层负责结算，低费用大容量的数据可用性层用负责保障；
L2赛道分析：
二线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的出现，新项目能否构成一个赛道我们是要打一个问号的。
但是目前OP和ZK系的RAAS技术壁垒不强，且短期内仍处于测试网阶段，无实际产品交互，考虑到RAAS的实际进展、技术形式和未来layer3的生态优势，RAAS的实际需求存疑。
对于常规defi应用，NFT市场，转型rollup并非是一个硬性需求，仅对效率要求高的支付应用或游戏才对rollup有更强的需求。未来可能defi类项目会在l2，social类可能日常行为在l3或者链下，最后核心数据和关系放在l2上，gaming类的项目有需求去l3或rollup，但考虑到目前链游大多实质为资金盘，且代币无法对外流通带来了发展瓶颈，加上全链上游戏的萌发，l3本身的生态吸引力要远远大于rollup。
4.坎昆升级改善了开发者和用户体验
5.与zkml和账户抽象的关系
对zkml影响不大
隐私保护：输入数据的保密，如使用大量个人信息作为数据喂给机器进行训练时，个人信息的保密就是一大需求；或模型参数作为项目的核心竞争力，也需要进行加密来维持竞争壁垒。诸如此类的信任问题存在时，ML模型要想获得更大规模的数据和应用就会存在阻碍。
可验证性：零知识证明技术应用范围广泛，ZKP可以让用户无需验证即可得知信息正确性。且由于机器学习模型需要大量计算，而ML模型可以通过ZK-SNARK生成证明，减少证明大小，缓解ML的算力需求问题。
ZK-SNARKs是ZKML中ZK的主要形式，能适配ML的链上算力需求，随着密码学的发展，尤其是递归的SNARK证明会利好ZKML在链上的落地：
ZK-SNARKs具有高度紧凑性的特点，使用ZK-SNARKs能让证明者生成一个短证明，而验证者无需交互，只需进行少量的计算即可验证其有效性，这种仅需一次有证明者向验证者交互的性质，使ZK-SNARKs在实际应用中具有高效性和实用性，更加适配ML的链上算力需求。
目前不可能进行链上训练，链上仅能存储链外计算的结果：
当前ML的问题更多在于算力需求无法满足和算法限制（无法并行计算）导致的低性能，大模型ZK证明需要更高算力，链上无法支持，当下流行的ZK-SNARKs也仅支持小规模、较小计算量的ML零知识证明，即算力局限是影响ZKML区块链应用发展的关键因素，链上仅能做到存储链外计算的结果。
利好账户抽象
当前zkSync的交易费取决于3方面：
验证者生成SNARK证明和进行验证所消耗的固定资源成本，该部分成本较高；
验证者将SNARK证明提交到以太坊主网时的gas费，这部分费用会因主网拥堵而相应增加；
用户支付给验证者的服务费用，包括交易确认、消息广播等。
所以，若引入4844，主网拥堵导致的gas费增加问题将得到缓解，能一定程度减少ZKP证明的费用，虽然相较于生成证明的费用不多，但是考虑到目前ZK仍处于出初期，未来ZK系发展趋势仍不容小觑。
其次，账户抽象将传统的tx交易转变为useroperation，再将useroperations用ECDSA打包成块，对链上存储占用相比于之前更多，所以对于存储的要求更高；
最后，考虑到AI技术的崛起，能帮助增强链上合约的安全性和优化链上交易或活动步骤：
AI与安全性：AI技术可以用于增强链上交易的安全性和隐私保护。例如Web3安全平台SeQure就利用AI检测和防止恶意攻击、欺诈行为和数据泄露，并提供实时监控和警报机制，确保链上交易的安全性和稳定性；
AI与链上活动优化：区块链上的活动包括交易、合约执行和数据存储等。通过AI的智能分析和预测能力，可以更好地优化链上活动，提高整体效率和性能。AI可以通过数据分析和模型训练，帮助识别交易模式、检测异常活动，并提供实时建议以优化区块链网络的资源分配。
6.回看以太坊路线图，接下来是什么
目前来看，Layer2还没有类似于Solana的性能（在延迟和吞吐量方面），也没有像Near这样的分片性能，也没有像Sui和Aptos这样的并行执行性能，坎昆升级提升了以太坊作为领导者的领先地位；
坎昆升级之后，预估几个重大的开发时间Fully-Danksharding（2~5年），MEV和PBS落地（1~3年），账户抽象（1~2年），ZK一切（3~6年），EOF和开发者体验（看延期几次？）。
目标：重点是解决MEV问题。
方案：通过「提议者构建者分离（PBS）」来达成应用层的MEV最小化，此时可能会对blob做出优化，并引入预确认服务或抢跑保护等。
PBS即出块者和排序者分离。排序者只负责排序不管上链，出块者不管交易，直接选排序者打好的包上链。这个流程会让整个过程更加流程正义，缓解MEV问题，是MEV外部化的思路。
目标：利用 Verkel树取代 Merkle，引入信任最小化的解决方案，使轻节点获得与全节点一样的安全保障，让区块验证尽可能简单和轻便。
同时，L1的ZK化明确地加入Verge路线图之中ZK将是未来扩容和提速的大势所趋；
Verkle树是一种专门针对状态的Merkle树的更有效的替代方法，它不需要提供每个姐妹节点（共享同一个父节点的节点）到所选节点的路径，而只是提供路径本身作为证明的一部分，Verkle证明的效率比Merkle证明高3倍。
参考资料：
以太坊核心开发者会议更新：https://www.galaxy.com/authors/christine-kim/
Tim关于最新的以太坊坎昆升级推文（23年6月9日）：https://twitter.com/TimBeiko/status/1666908046994608128
以太坊升级相关内容：
自毁代码的简介：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
除了备受瞩目的EIP-4844，坎昆升级还会包含哪些提案？https://www.panewslab.com/zh/articledetails/4qlg59ty.html
V神：值得考虑删除的EVM功能https://www.jinse.com/blockchain/1020439.html
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/
第111次以太坊ACDC会议：讨论Deneb升级最终范围以及EIP-7044等三项提案https://www.theblockbeats.info/flash/150732
2023值得重新思考的3大热门赛道https://finance.sina.cn/blockchain/2023-04-12/detail-imyqawtq3942364.d.html
AI与Web3结合可能性的无限遐想https://www.techflowpost.com/article/detail_12169.html
AI+Web3：探索人工智能和区块链的融合之路https://www.techflowpost.com/article/detail_12141.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
一文读懂最新版以太坊发展路线图https://foresightnews.pro/article/detail/20815
提案原文：
金色财经 善欧巴
元宇宙Lab
比推 Bitpush News
郑重声明： 本文版权归原作者所有， 转载文章仅为传播更多信息之目的， 如作者信息标记有误， 请第一时间联系我们修改或删除， 多谢。