EIP-7623 深度解析以太坊 calldata 成本上调如何将最大区块大小从 1.79 MB 压至 0.72 MB【免费下载链接】EIPsThe Ethereum Improvement Proposal repository项目地址: https://gitcode.com/GitHub_Trending/ei/EIPs导读本文以以太坊改进提案 EIP-7623Increase calldata cost 为核心系统拆解其通过数据密集型交易最低成本下限floor cost机制抑制最大区块膨胀的完整设计——从背景动机、规范公式、区块大小量化分析到钱包/节点兼容性要求与安全考量并结合仓库中的 EIP-1559、EIP-2028、EIP-4844 等关联提案及 Pectra 硬分叉元 EIP 佐证其演进脉络。读完本文你将能准确理解该提案的 gas 计算公式、floor 机制的作用原理以及它对区块构建、钱包 gas 估算和 DA数据可用性定价的深远影响。一、提案定位一个已进入 Pectra 升级的 Core 提案EIP-7623 是一份Standards Track / Core类提案状态为Final由 Toni Wahrstätternerolation与 Vitalik Buterinvbuterin共同撰写创建于 2024-02-13。它被正式列入 Prague/ElectraPectra网络升级的 Core EIP 清单——这一事实可从仓库中的硬分叉元 EIP EIP-7600Hardfork Meta - Pectra 直接确认其 Included EIPs 一节明确列出EIP-7623: Increase calldata cost。与多数引入新功能、新操作码的 EIP 不同EIP-7623 的目标非常朴素却极为关键通过重新定价 calldata缩小以太坊区块平均大小与理论上限大小之间的巨大落差为未来容纳更多 blob 或提高区块 gas limit 腾出空间。该提案属于向后不兼容的 gas 重新定价backwards incompatible gas repricing必须随一次排定的网络升级network upgrade生效这也是它被归入 Pectra 的原因。二、背景与动机为什么 calldata 定价需要重新审视2.1 平均大小与最大大小的失衡EIP-7623 的摘要开篇给出了一个刺眼的数据对比按当时的 calldata 定价EL payload执行层负载理论上限约为 7.15 MB而实际平均区块大小仅有约 100 KB。两者相差两个数量级。这意味着协议必须为极端情况预留大量带宽与处理能力而日常根本用不到。这种最大 vs 平均的差距正是限制以太坊进一步扩容提高 gas limit、增加 blob 数量的隐形天花板。2.2 三个关键历史背景提案的 Motivation 部分点出了三个相互关联的历史事实区块 gas limit 自 EIP-1559 以来未曾提高。EIP-1559 引入了 base fee 机制与动态区块伸缩target/limit 弹性但每个区块的 gas 上限本身保持不变区块大小因此被 gas limit 严格约束。calldata 成本自 EIP-2028 以来保持不变。EIP-2028 将 calldata 中非零字节的 gas 成本从 68 gas/字节大幅降至 16 gas/字节零字节仍为 4 gas初衷是降低 Layer 2STARK/SNARK 证明、欺诈证明、DA 数据上链与无状态客户端的成本。但正是这份便宜让 calldata 成为 rollup 廉价发布数据的热门通道——区块平均大小因此随 rollup 数据发布量的增长而持续抬升。EIP-4844Shard Blob Transactions 引入了 blob 作为数据可用性DA的首选方式。blob 交易携带无法被 EVM 执行访问、但承诺可被访问的大块数据且带 blob 的区块不会无上限膨胀。这一数据搬到 blob 上的范式转移要求重新评估 calldata 的定价——既然 DA 有了更合适的载体继续让 calldata 保持廉价海量数据通道的定位就不再合理。2.3 提案的核心思路EIP-7623 的解法不是简单地把所有 calldata 涨价那会误伤正常用户而是引入一个基于EVM 执行 gas 与 calldata gas 之比的最低成本下限floor cost对于主要用来发布数据的交易calldata 成本从 4/16 gas 每字节提高到 10/40 gas 每字节 对于包含大量 EVM 计算的交易calldata 成本维持 4/16 gas 每字节不变。这样既能把纯数据型大负载交易挤出区块空间又不影响绝大多数常规用户。三、规范详解参数、公式与交易有效性3.1 核心参数EIP-7623 的 Specification 只定义了两个参数极简但关键ParameterValueSTANDARD_TOKEN_COST4TOTAL_COST_FLOOR_PER_TOKEN103.2 tokens_in_calldata把 calldata 折算成token规范定义了token代币化计费单元这一中间量统一了零字节与非零字节的计价tokens_in_calldata zero_bytes_in_calldata nonzero_bytes_in_calldata * 4即1 个零字节 1 token1 个非零字节 4 token。这与现行定价零字节 4 gas、非零字节 16 gas的 1:4 比例完全一致——STANDARD_TOKEN_COST 4正是每 token 的标准 gas 价格。3.3 交易 gas 计算从单一公式到 max() 双轨公式在 EIP-7623 之前单笔交易的总 gas 消耗tx.gasUsed由四部分构成tx.gasUsed ( 21000 STANDARD_TOKEN_COST * tokens_in_calldata execution_gas_used isContractCreation * (32000 INITCODE_WORD_COST * words(calldata)) )其中21000每笔交易的内置基础 gasintrinsic gasSTANDARD_TOKEN_COST * tokens_in_calldatacalldata 数据费用execution_gas_used扣除 gas 退款refund后的 EVM 执行 gasisContractCreation * (32000 INITCODE_WORD_COST * words(calldata))合约创建交易额外负担——32000是 EIP-3860 之前的创建成本部分而INITCODE_WORD_COST 2正是 EIP-3860 定义的 initcode 每 32 字节计费常量该提案同时将 initcode 大小上限设为2 * MAX_CODE_SIZE 49152。EIP-7623 的改动在于对上述计算结果与按 token 数计算的最低成本下限取最大值tx.gasUsed ( 21000 max( STANDARD_TOKEN_COST * tokens_in_calldata execution_gas_used isContractCreation * (32000 INITCODE_WORD_COST * words(calldata)), TOTAL_COST_FLOOR_PER_TOKEN * tokens_in_calldata ) )关键在TOTAL_COST_FLOOR_PER_TOKEN * tokens_in_calldata这一项它等于10 × tokens折算到字节层面即零字节 10 gas/字节、非零字节 40 gas/字节。floor 何时生效当交易数据量很大、而 EVM 执行消耗的 gas 相对很少时典型的纯 DA 发布交易execution_gas_used贡献微乎其微第一项 ≈STANDARD_TOKEN_COST * tokens会低于第二项的 10×tokens于是max()取到 floor交易被按 10/40 计价。反之若交易包含大量 EVM 计算DeFi 交互、Token 转账、NFT 操作等第一项中execution_gas_used足够大仍由第一项主导calldata 维持 4/16 的廉价定价。3.4 交易有效性下限floor 必须在 gas limit 中预留规范还明确了一条交易合法性约束任何 gas limit 低于21000 TOTAL_COST_FLOOR_PER_TOKEN * tokens_in_calldata或低于其内在 gas 成本取两者较大值的交易均视为无效invalid。这条规则的逻辑是交易必须仅凭其数据就足以覆盖 floor 价格而不能依赖执行环节产生的 gas 消耗来补足。因为存在合法的场景——比如执行中途REVERT或实际执行 gas 很少——此时gasUsed会低于 floor但 floor 必须在交易的 gas limit 中预先保留交易才能合法进入区块。这一约束直接改变了区块构建者的工作方式正如 EIP-7873 中所述EIP-7623 为交易的 gas limit 建立了新的下限区块构建者需要确保不会把不满足该下限的无效交易打包进区块。四、原理与效果区块大小究竟被压到了多少Rationale 部分是理解该提案价值的核心其中给出了完整的量化推演链4.1 现状最大 EL payload 有多大标准构造下最大 EL payload 约为1.79 MB即30_000_000 / 1630M gas limit ÷ 非零字节 16 gas。使用全零字节填充可以构造出膨胀到7.15 MB的 payload30_000_000 / 4。然而由于 P2P 层区块通常经过Snappy 压缩零字节密集的 payload 一般会被压缩到 1.79 MB 以下。EIP-4844 上线后引入了 blob 相关的区块载荷最大可能压缩区块大小升至约 2.54 MB。4.2 提案生效后数据密集交易被大幅限流在 floor 规则下对于EVM 计算 gas 未超过阈值的数据密集交易calldata 成本变为 10/40 gas 每字节纯零字节交易30_000_000 / 10 3 MB纯非零字节交易最坏情况30_000_000 / 40 0.72 MB。因此EIP-7623 将数据密集交易能塞进单个区块的 payload 上限降到约 0.72 MB。不过规范也诚实地指出对抗性adversarial区块构造仍可达到约1.26 MiB的不可压缩 EL payload——但这相比此前的 7.15 MB 理论值已是数量级的收窄。4.3 谁不受影响提案特别强调两点常规用户不受影响发送 ETH/Token/NFT、参与 DeFi、社交、再质押restaking、桥接bridging等日常操作其 calldata 占比较小、EVM 计算占比较大floor 不会触发成本维持原样。高计算量交易不受影响涉及大量 EVM 计算、calldata 只是附带的交易仍按 4/16 gas 每字节计价。换言之EIP-7623 的定价杠杆精准地只落在主要靠 calldata 发数据的少数交易类型上实现了压低上限、不动平均的效果——这正是它被选入 Pectra 的关键原因在不打扰绝大多数用户的前提下为后续扩容更多 blob、更高 gas limit释放安全余量。五、向后兼容性与升级要求钱包与节点必须同步更新EIP-7623 明确这是一次向后不兼容的 gas 重新定价需要排定的网络升级配合。更重要的是它给出了针对生态各方的强制要求MUST5.1 钱包必须正确估算 floor使用eth_estimateGas的钱包MUST更新其 gas 估算逻辑以正确计入TOTAL_COST_FLOOR_PER_TOKEN。若钱包沿用旧公式估算对数据密集交易可能低估 gas低估会导致交易因 gas limit 低于 floor 而被判无效最终表现为交易失败。5.2 节点软件 / RPC必须采用新公式eth_estimateGas等 RPC 方法MUST采用更新后的 gas 计算公式节点开发者MUST确保与新的 calldata 定价逻辑兼容。5.3 最终用户无需任何操作用户无需修改任何工作流——钱包与 RPC 的升级会透明地处理这些变化。值得一提的是EIP-7623 的 floor 机制并非孤立存在它已成为后续协议设计的基础设施例如 EIP-3298关于退款机制的重新设计就明确指出退款后的tx_gas_used仍受 EIP-7623 calldata floor 约束收据中的cumulative_gas_used使用 floor 后的值EIP-7778 则在区块级 gas 记账中采用block.gas_used max(tx_gas_used, calldata_floor_gas_cost)以纳入该 floorEIP-7886 也规定 inclusion gas 必须取常规 intrinsic gas 与 EIP-7623 calldata floor 成本两者的最大值。这些都印证了 floor 已成为协议 gas 账本的通用构件。六、安全考虑交易捆绑Transaction Bundling不成问题由于最大可能区块大小被显著压低EIP-7623 本身未引发新的安全顾虑no security concerns have been raised。规范额外讨论了一个直觉上可能的规避手段把两笔交易合并成一笔例如把重度依赖 calldata、几乎不耗 EVM 资源的交易与正好相反的交易捆绑从而摊薄 floor 成本。提案给出三点反驳这种捆绑今天就已经可行——合并多笔交易本就可省掉后续每笔的 21,000 gas 基础费且是 ERC-4337 明确支持的账户抽象特性并非 EIP-7623 引入的新漏洞此类捆绑不会削弱本提案的区块大小压缩目标——区块总数据量并不会因此变大实践中捆绑往往不可行——它要求多方之间的信任与协调门槛极高。综合来看交易捆绑不会对提案目标构成实质威胁。七、在以太坊演进中的位置从 calldata 廉价时代到多维定价时代从仓库中可梳理出一条清晰的定价演进主线EIP-20282019Final非零 calldata 字节从 68 gas 降到 16 gas开启calldata 作为 DA 廉价通道时代EIP-48442024Final引入 blobDA 获得专属空间calldata 的 DA 定位开始让位EIP-76232024FinalPectra用 floor 机制约束 calldata 的极端用量压低最大区块大小后续探索并未止步EIP-7706Separate gas type for calldataStagnant提议为 calldata 建立独立的 basefee 与 gas limit 费用市场多维 gas 定价其动机一节与 EIP-7623 如出一辙——理论最大区块过大限制扩容EIP-7976要求 EIP-7623则在 10/40 基础上进一步探讨 64/64 的更高 floor 定价将数据密集 payload 上限进一步压缩在 45M gas limit 假设下从约 1.07 MB 降至约 0.67 MB并指出 10 MiB 的不可压缩执行 payload 在 64/64 定价下需要约 6.71 亿 gas对比 10/40 定价下约 1.05 亿 gas。这条脉络说明EIP-7623 是以太坊从统一 gas 市场走向多维资源定价过程中的关键一环——先用最小侵入的 floor 机制解决最迫切的区块膨胀问题再逐步演进到更精细的分维计价。八、总结EIP-7623 用一组极简参数STANDARD_TOKEN_COST 4、TOTAL_COST_FLOOR_PER_TOKEN 10和一个max()公式完成了对以太坊区块大小分布的一次削峰数据密集交易被按 10/40 gas 每字节重新计价最大 EL payload 从理论上限 7.15 MB 压至约 0.72 MB对抗性构造约 1.26 MiB常规用户与高计算量交易完全不受影响仍享受 4/16 的 calldata 定价钱包与节点必须同步升级 gas 估算逻辑eth_estimateGas否则数据密集交易可能因 gas 低估而失败作为 Pectra 的 Core 提案它为后续 blob 扩容与 gas limit 提升扫清了区块过大这一障碍也为 EIP-7706 的多维定价、EIP-7976 的更高 floor 等后续设计奠定了范式基础。对于协议开发者、钱包工程师、区块构建者以及 rollup 团队而言理解 EIP-7623 的 floor 机制及其在 gas 账本中的贯通应用参见 EIP-3298、EIP-7778、EIP-7886 的引用是在 Pectra 时代正确估算 gas、构建区块与设计数据发布策略的必备前提。【免费下载链接】EIPsThe Ethereum Improvement Proposal repository项目地址: https://gitcode.com/GitHub_Trending/ei/EIPs创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 EIP-7623 深度解析：以太坊 calldata 成本上调如何将最大区块大小从 1.79 MB 压至 0.72 MB
EIP-7623 深度解析以太坊 calldata 成本上调如何将最大区块大小从 1.79 MB 压至 0.72 MB【免费下载链接】EIPsThe Ethereum Improvement Proposal repository项目地址: https://gitcode.com/GitHub_Trending/ei/EIPs导读本文以以太坊改进提案 EIP-7623Increase calldata cost 为核心系统拆解其通过数据密集型交易最低成本下限floor cost机制抑制最大区块膨胀的完整设计——从背景动机、规范公式、区块大小量化分析到钱包/节点兼容性要求与安全考量并结合仓库中的 EIP-1559、EIP-2028、EIP-4844 等关联提案及 Pectra 硬分叉元 EIP 佐证其演进脉络。读完本文你将能准确理解该提案的 gas 计算公式、floor 机制的作用原理以及它对区块构建、钱包 gas 估算和 DA数据可用性定价的深远影响。一、提案定位一个已进入 Pectra 升级的 Core 提案EIP-7623 是一份Standards Track / Core类提案状态为Final由 Toni Wahrstätternerolation与 Vitalik Buterinvbuterin共同撰写创建于 2024-02-13。它被正式列入 Prague/ElectraPectra网络升级的 Core EIP 清单——这一事实可从仓库中的硬分叉元 EIP EIP-7600Hardfork Meta - Pectra 直接确认其 Included EIPs 一节明确列出EIP-7623: Increase calldata cost。与多数引入新功能、新操作码的 EIP 不同EIP-7623 的目标非常朴素却极为关键通过重新定价 calldata缩小以太坊区块平均大小与理论上限大小之间的巨大落差为未来容纳更多 blob 或提高区块 gas limit 腾出空间。该提案属于向后不兼容的 gas 重新定价backwards incompatible gas repricing必须随一次排定的网络升级network upgrade生效这也是它被归入 Pectra 的原因。二、背景与动机为什么 calldata 定价需要重新审视2.1 平均大小与最大大小的失衡EIP-7623 的摘要开篇给出了一个刺眼的数据对比按当时的 calldata 定价EL payload执行层负载理论上限约为 7.15 MB而实际平均区块大小仅有约 100 KB。两者相差两个数量级。这意味着协议必须为极端情况预留大量带宽与处理能力而日常根本用不到。这种最大 vs 平均的差距正是限制以太坊进一步扩容提高 gas limit、增加 blob 数量的隐形天花板。2.2 三个关键历史背景提案的 Motivation 部分点出了三个相互关联的历史事实区块 gas limit 自 EIP-1559 以来未曾提高。EIP-1559 引入了 base fee 机制与动态区块伸缩target/limit 弹性但每个区块的 gas 上限本身保持不变区块大小因此被 gas limit 严格约束。calldata 成本自 EIP-2028 以来保持不变。EIP-2028 将 calldata 中非零字节的 gas 成本从 68 gas/字节大幅降至 16 gas/字节零字节仍为 4 gas初衷是降低 Layer 2STARK/SNARK 证明、欺诈证明、DA 数据上链与无状态客户端的成本。但正是这份便宜让 calldata 成为 rollup 廉价发布数据的热门通道——区块平均大小因此随 rollup 数据发布量的增长而持续抬升。EIP-4844Shard Blob Transactions 引入了 blob 作为数据可用性DA的首选方式。blob 交易携带无法被 EVM 执行访问、但承诺可被访问的大块数据且带 blob 的区块不会无上限膨胀。这一数据搬到 blob 上的范式转移要求重新评估 calldata 的定价——既然 DA 有了更合适的载体继续让 calldata 保持廉价海量数据通道的定位就不再合理。2.3 提案的核心思路EIP-7623 的解法不是简单地把所有 calldata 涨价那会误伤正常用户而是引入一个基于EVM 执行 gas 与 calldata gas 之比的最低成本下限floor cost对于主要用来发布数据的交易calldata 成本从 4/16 gas 每字节提高到 10/40 gas 每字节 对于包含大量 EVM 计算的交易calldata 成本维持 4/16 gas 每字节不变。这样既能把纯数据型大负载交易挤出区块空间又不影响绝大多数常规用户。三、规范详解参数、公式与交易有效性3.1 核心参数EIP-7623 的 Specification 只定义了两个参数极简但关键ParameterValueSTANDARD_TOKEN_COST4TOTAL_COST_FLOOR_PER_TOKEN103.2 tokens_in_calldata把 calldata 折算成token规范定义了token代币化计费单元这一中间量统一了零字节与非零字节的计价tokens_in_calldata zero_bytes_in_calldata nonzero_bytes_in_calldata * 4即1 个零字节 1 token1 个非零字节 4 token。这与现行定价零字节 4 gas、非零字节 16 gas的 1:4 比例完全一致——STANDARD_TOKEN_COST 4正是每 token 的标准 gas 价格。3.3 交易 gas 计算从单一公式到 max() 双轨公式在 EIP-7623 之前单笔交易的总 gas 消耗tx.gasUsed由四部分构成tx.gasUsed ( 21000 STANDARD_TOKEN_COST * tokens_in_calldata execution_gas_used isContractCreation * (32000 INITCODE_WORD_COST * words(calldata)) )其中21000每笔交易的内置基础 gasintrinsic gasSTANDARD_TOKEN_COST * tokens_in_calldatacalldata 数据费用execution_gas_used扣除 gas 退款refund后的 EVM 执行 gasisContractCreation * (32000 INITCODE_WORD_COST * words(calldata))合约创建交易额外负担——32000是 EIP-3860 之前的创建成本部分而INITCODE_WORD_COST 2正是 EIP-3860 定义的 initcode 每 32 字节计费常量该提案同时将 initcode 大小上限设为2 * MAX_CODE_SIZE 49152。EIP-7623 的改动在于对上述计算结果与按 token 数计算的最低成本下限取最大值tx.gasUsed ( 21000 max( STANDARD_TOKEN_COST * tokens_in_calldata execution_gas_used isContractCreation * (32000 INITCODE_WORD_COST * words(calldata)), TOTAL_COST_FLOOR_PER_TOKEN * tokens_in_calldata ) )关键在TOTAL_COST_FLOOR_PER_TOKEN * tokens_in_calldata这一项它等于10 × tokens折算到字节层面即零字节 10 gas/字节、非零字节 40 gas/字节。floor 何时生效当交易数据量很大、而 EVM 执行消耗的 gas 相对很少时典型的纯 DA 发布交易execution_gas_used贡献微乎其微第一项 ≈STANDARD_TOKEN_COST * tokens会低于第二项的 10×tokens于是max()取到 floor交易被按 10/40 计价。反之若交易包含大量 EVM 计算DeFi 交互、Token 转账、NFT 操作等第一项中execution_gas_used足够大仍由第一项主导calldata 维持 4/16 的廉价定价。3.4 交易有效性下限floor 必须在 gas limit 中预留规范还明确了一条交易合法性约束任何 gas limit 低于21000 TOTAL_COST_FLOOR_PER_TOKEN * tokens_in_calldata或低于其内在 gas 成本取两者较大值的交易均视为无效invalid。这条规则的逻辑是交易必须仅凭其数据就足以覆盖 floor 价格而不能依赖执行环节产生的 gas 消耗来补足。因为存在合法的场景——比如执行中途REVERT或实际执行 gas 很少——此时gasUsed会低于 floor但 floor 必须在交易的 gas limit 中预先保留交易才能合法进入区块。这一约束直接改变了区块构建者的工作方式正如 EIP-7873 中所述EIP-7623 为交易的 gas limit 建立了新的下限区块构建者需要确保不会把不满足该下限的无效交易打包进区块。四、原理与效果区块大小究竟被压到了多少Rationale 部分是理解该提案价值的核心其中给出了完整的量化推演链4.1 现状最大 EL payload 有多大标准构造下最大 EL payload 约为1.79 MB即30_000_000 / 1630M gas limit ÷ 非零字节 16 gas。使用全零字节填充可以构造出膨胀到7.15 MB的 payload30_000_000 / 4。然而由于 P2P 层区块通常经过Snappy 压缩零字节密集的 payload 一般会被压缩到 1.79 MB 以下。EIP-4844 上线后引入了 blob 相关的区块载荷最大可能压缩区块大小升至约 2.54 MB。4.2 提案生效后数据密集交易被大幅限流在 floor 规则下对于EVM 计算 gas 未超过阈值的数据密集交易calldata 成本变为 10/40 gas 每字节纯零字节交易30_000_000 / 10 3 MB纯非零字节交易最坏情况30_000_000 / 40 0.72 MB。因此EIP-7623 将数据密集交易能塞进单个区块的 payload 上限降到约 0.72 MB。不过规范也诚实地指出对抗性adversarial区块构造仍可达到约1.26 MiB的不可压缩 EL payload——但这相比此前的 7.15 MB 理论值已是数量级的收窄。4.3 谁不受影响提案特别强调两点常规用户不受影响发送 ETH/Token/NFT、参与 DeFi、社交、再质押restaking、桥接bridging等日常操作其 calldata 占比较小、EVM 计算占比较大floor 不会触发成本维持原样。高计算量交易不受影响涉及大量 EVM 计算、calldata 只是附带的交易仍按 4/16 gas 每字节计价。换言之EIP-7623 的定价杠杆精准地只落在主要靠 calldata 发数据的少数交易类型上实现了压低上限、不动平均的效果——这正是它被选入 Pectra 的关键原因在不打扰绝大多数用户的前提下为后续扩容更多 blob、更高 gas limit释放安全余量。五、向后兼容性与升级要求钱包与节点必须同步更新EIP-7623 明确这是一次向后不兼容的 gas 重新定价需要排定的网络升级配合。更重要的是它给出了针对生态各方的强制要求MUST5.1 钱包必须正确估算 floor使用eth_estimateGas的钱包MUST更新其 gas 估算逻辑以正确计入TOTAL_COST_FLOOR_PER_TOKEN。若钱包沿用旧公式估算对数据密集交易可能低估 gas低估会导致交易因 gas limit 低于 floor 而被判无效最终表现为交易失败。5.2 节点软件 / RPC必须采用新公式eth_estimateGas等 RPC 方法MUST采用更新后的 gas 计算公式节点开发者MUST确保与新的 calldata 定价逻辑兼容。5.3 最终用户无需任何操作用户无需修改任何工作流——钱包与 RPC 的升级会透明地处理这些变化。值得一提的是EIP-7623 的 floor 机制并非孤立存在它已成为后续协议设计的基础设施例如 EIP-3298关于退款机制的重新设计就明确指出退款后的tx_gas_used仍受 EIP-7623 calldata floor 约束收据中的cumulative_gas_used使用 floor 后的值EIP-7778 则在区块级 gas 记账中采用block.gas_used max(tx_gas_used, calldata_floor_gas_cost)以纳入该 floorEIP-7886 也规定 inclusion gas 必须取常规 intrinsic gas 与 EIP-7623 calldata floor 成本两者的最大值。这些都印证了 floor 已成为协议 gas 账本的通用构件。六、安全考虑交易捆绑Transaction Bundling不成问题由于最大可能区块大小被显著压低EIP-7623 本身未引发新的安全顾虑no security concerns have been raised。规范额外讨论了一个直觉上可能的规避手段把两笔交易合并成一笔例如把重度依赖 calldata、几乎不耗 EVM 资源的交易与正好相反的交易捆绑从而摊薄 floor 成本。提案给出三点反驳这种捆绑今天就已经可行——合并多笔交易本就可省掉后续每笔的 21,000 gas 基础费且是 ERC-4337 明确支持的账户抽象特性并非 EIP-7623 引入的新漏洞此类捆绑不会削弱本提案的区块大小压缩目标——区块总数据量并不会因此变大实践中捆绑往往不可行——它要求多方之间的信任与协调门槛极高。综合来看交易捆绑不会对提案目标构成实质威胁。七、在以太坊演进中的位置从 calldata 廉价时代到多维定价时代从仓库中可梳理出一条清晰的定价演进主线EIP-20282019Final非零 calldata 字节从 68 gas 降到 16 gas开启calldata 作为 DA 廉价通道时代EIP-48442024Final引入 blobDA 获得专属空间calldata 的 DA 定位开始让位EIP-76232024FinalPectra用 floor 机制约束 calldata 的极端用量压低最大区块大小后续探索并未止步EIP-7706Separate gas type for calldataStagnant提议为 calldata 建立独立的 basefee 与 gas limit 费用市场多维 gas 定价其动机一节与 EIP-7623 如出一辙——理论最大区块过大限制扩容EIP-7976要求 EIP-7623则在 10/40 基础上进一步探讨 64/64 的更高 floor 定价将数据密集 payload 上限进一步压缩在 45M gas limit 假设下从约 1.07 MB 降至约 0.67 MB并指出 10 MiB 的不可压缩执行 payload 在 64/64 定价下需要约 6.71 亿 gas对比 10/40 定价下约 1.05 亿 gas。这条脉络说明EIP-7623 是以太坊从统一 gas 市场走向多维资源定价过程中的关键一环——先用最小侵入的 floor 机制解决最迫切的区块膨胀问题再逐步演进到更精细的分维计价。八、总结EIP-7623 用一组极简参数STANDARD_TOKEN_COST 4、TOTAL_COST_FLOOR_PER_TOKEN 10和一个max()公式完成了对以太坊区块大小分布的一次削峰数据密集交易被按 10/40 gas 每字节重新计价最大 EL payload 从理论上限 7.15 MB 压至约 0.72 MB对抗性构造约 1.26 MiB常规用户与高计算量交易完全不受影响仍享受 4/16 的 calldata 定价钱包与节点必须同步升级 gas 估算逻辑eth_estimateGas否则数据密集交易可能因 gas 低估而失败作为 Pectra 的 Core 提案它为后续 blob 扩容与 gas limit 提升扫清了区块过大这一障碍也为 EIP-7706 的多维定价、EIP-7976 的更高 floor 等后续设计奠定了范式基础。对于协议开发者、钱包工程师、区块构建者以及 rollup 团队而言理解 EIP-7623 的 floor 机制及其在 gas 账本中的贯通应用参见 EIP-3298、EIP-7778、EIP-7886 的引用是在 Pectra 时代正确估算 gas、构建区块与设计数据发布策略的必备前提。【免费下载链接】EIPsThe Ethereum Improvement Proposal repository项目地址: https://gitcode.com/GitHub_Trending/ei/EIPs创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考