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-7623（Increase 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ätter（@nerolation）与 Vitalik Buterin（@vbuterin）共同撰写，创建于 2024-02-13。它被正式列入 Prague/Electra（Pectra）网络升级的 Core EIP 清单——这一事实可从仓库中的硬分叉元 EIP EIP-7600（Hardfork 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 2（STARK/SNARK 证明、欺诈证明、DA 数据上链）与无状态客户端的成本。但正是这份"便宜"，让 calldata 成为 rollup 廉价发布数据的热门通道——区块平均大小因此随 rollup 数据发布量的增长而持续抬升。
EIP-4844（Shard 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 只定义了两个参数，极简但关键：

Parameter	Value
`STANDARD_TOKEN_COST`	`4`
`TOTAL_COST_FLOOR_PER_TOKEN`	`10`

3.2 tokens_in_calldata：把 calldata 折算成"token"

规范定义了"token"（代币化计费单元）这一中间量，统一了零字节与非零字节的计价：

tokens_in_calldata = zero_bytes_in_calldata + nonzero_bytes_in_calldata * 4

即：1 个零字节 = 1 token，1 个非零字节 = 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：每笔交易的内置基础 gas（intrinsic gas）；
STANDARD_TOKEN_COST * tokens_in_calldata：calldata 数据费用；
execution_gas_used：扣除 gas 退款（refund）后的 EVM 执行 gas；
isContractCreation * (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 / 16（30M gas limit ÷ 非零字节 16 gas）。
使用全零字节填充可以构造出膨胀到7.15 MB的 payload（30_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 重新定价，需要排定的网络升级配合。更重要的是，它给出了针对生态各方的强制要求（MUST）：

5.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)以纳入该 floor；EIP-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-2028（2019，Final）：非零 calldata 字节从 68 gas 降到 16 gas，开启"calldata 作为 DA 廉价通道"时代；
EIP-4844（2024，Final）：引入 blob，DA 获得专属空间，calldata 的 DA 定位开始让位；
EIP-7623（2024，Final，Pectra）：用 floor 机制约束 calldata 的极端用量，压低最大区块大小；
后续探索并未止步：EIP-7706（Separate gas type for calldata，Stagnant）提议为 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），仅供参考