EIP-7904: 通用重定价
重新评估 Gas 成本以反映计算复杂性和交易吞吐量的增加
Authors | Jacek Glen (@JacekGlen), Lukasz Glen (@lukasz-glen) |
---|---|
Created | 2025-02-05 |
Discussion Link | https://ethereum-magicians.org/t/gas-cost-repricing-to-reflect-computational-complexity/23067 |
Requires | EIP-7883 |
Table of Contents
摘要
本提案修改了操作码、预编译、内存扩展和数据访问的 gas 成本计划,优先考虑计算复杂度,同时排除网络相关成本,如状态持久性。这些调整旨在提高 gas 成本的准确性并重新平衡成本结构。
动机
Gas 成本包含两个组成部分:网络(社会)成本和计算成本。网络成本反映了区块链维护状态的努力,包括添加交易、存储、日志、calldata和收据,而计算成本代表了智能合约的非持久性处理工作。
适当 gas 成本的重要性源于在以太坊区块链上完成的计算的性质,并且已在许多研究论文中讨论过。此外,从安全和网络稳定的角度来看,这一点至关重要。Gas 成本是防止滥用网络容量的天然威慑。另一方面,网络需要经济实惠且高效。适当的 gas 成本在两个要求之间取得了平衡。
虽然一些 EIP(例如,EIP-160, EIP-1884)已经改进了与网络相关的 gas 成本,但自以太坊成立以来,计算成本在很大程度上保持不变。随着多个 EVM 实现现在稳定和优化,以及高级工具的出现,我们可以评估当前的 gas 计划与硬件工作负载配置的匹配程度。
测量和估计取决于多种因素,包括硬件、操作系统、虚拟化、编译器、内存管理、EVM 等。单个操作码的执行会影响或依赖于缓存、区块准备、区块最终确定、垃圾收集器、代码分析、解析等。因此,单个计算成本是分布在软件堆栈上的多个因素的总和。尽管存在这种复杂性,但检查表明,计算成本概要在 EVM 实现、技术堆栈和上下文中是一致的。
例如,实验数据可能表明,在大多数 EVM 实现中,执行一个操作码所需的计算工作量始终是另一个操作码的两倍。在这种情况下,这些操作码之间的 gas 成本比率应设置为 2:1,以反映其相对计算复杂度。这种方法依赖于经验测量而不是理论假设。因此,gas 成本计划应准确反映计算复杂性。
可观察的异常值
当前的 gas 成本计划在许多地方与实验确定的计算复杂度不同。已经发现许多重要的异常值,表明需要重新平衡。许多其他的都是重新平衡的合理候选者。不平衡的 gas 成本计划可能会:暴露网络风险、打开攻击向量、导致错误的优化,并打破 gas 是交易执行工作量的抽象单位的原则。
Gas 成本的相对性质
Gas 成本计划本质上是相对的,只要比例保持不变就可以调整。大幅降低本提案中包含的 gas 成本有两个显着的影响:它提高了区块链在每个区块的交易数量方面的吞吐量,并增加了网络存储成本的比例权重。
规范
本文档中的关键词“必须 (MUST)”,“禁止 (MUST NOT)”,“需要 (REQUIRED)”,“应当 (SHALL)”,“不应当 (SHALL NOT)”,“应该 (SHOULD)”,“不应该 (SHOULD NOT)”,“推荐 (RECOMMENDED)”,“不推荐 (NOT RECOMMENDED)”,“可以 (MAY)”,和“可选 (OPTIONAL)”按照 RFC 2119 和 RFC 8174 中的描述进行解释。
参数
常量 | 值 |
---|---|
WARM_STORAGE_READ_COST |
5 |
BASE_OPCODE_COST |
1 |
FAST_OPCODE_COST |
2 |
MID_OPCODE_COST |
3 |
EXP_BASE_COST |
2 |
EXP_PER_BYTE_COST |
4 |
COPY_PER_WORD_COST |
1 |
成本公式
名称 | 公式 | 描述 |
---|---|---|
data_size | len(data) | 以字节数为单位表示的数据大小 |
data_word_size | (len(data) + 31) / 32 | 以字数为单位表示的数据大小 |
exponent_byte_size | len(exponent) | EXP 操作码中指数的大小(以字节为单位)。 |
sets_count | len(data) / 192 | ECPAIRING 预编译中的对集数量。 |
memory_expansion_cost | memory_cost(current_word_size) - memory_cost(previous_word_size) | 将内存从 previous_word_size 字扩展到 current_word_size 字的成本。在单个上下文中,内存无法收缩,因此该公式始终为非负数 |
memory_cost | (memory_word_size ** 2) / 512 | data_word_size 字的内存成本。 |
memory_word_size | (memory_size + 31) / 32 | 已分配的内存大小(以字数为单位表示) |
address_access_cost | 5 (warm) | 2600 (cold) | 访问热和冷地址数据的成本。 |
storage_access_cost | 5 (warm) | 2100 (cold) | 访问热和冷存储数据的成本。 |
操作码成本
操作码 | 名称 | 变更前 Gas | Gas 成本 |
---|---|---|---|
0x01 | ADD | 3 | BASE_OPCODE_COST |
0x02 | MUL | 5 | BASE_OPCODE_COST |
0x03 | SUB | 3 | BASE_OPCODE_COST |
0x04 | DIV | 5 | BASE_OPCODE_COST |
0x05 | SDIV | 5 | BASE_OPCODE_COST |
0x06 | MOD | 5 | BASE_OPCODE_COST |
0x07 | SMOD | 5 | BASE_OPCODE_COST |
0x08 | ADDMOD | 8 | FAST_OPCODE_COST |
0x09 | MULMOD | 8 | MID_OPCODE_COST |
0x0A | EXP | 10 + 50 * exponent_byte_size | EXP_BASE_COST + EXP_PER_BYTE_COST * exponent_byte_size |
0x0B | SIGNEXTEND | 5 | BASE_OPCODE_COST |
0x10 | LT | 3 | BASE_OPCODE_COST |
0x11 | GT | 3 | BASE_OPCODE_COST |
0x12 | SLT | 3 | BASE_OPCODE_COST |
0x13 | SGT | 3 | BASE_OPCODE_COST |
0x14 | EQ | 3 | BASE_OPCODE_COST |
0x15 | ISZERO | 3 | BASE_OPCODE_COST |
0x16 | AND | 3 | BASE_OPCODE_COST |
0x17 | OR | 3 | BASE_OPCODE_COST |
0x18 | XOR | 3 | BASE_OPCODE_COST |
0x19 | NOT | 3 | BASE_OPCODE_COST |
0x1A | BYTE | 3 | BASE_OPCODE_COST |
0x1B | SHL | 3 | BASE_OPCODE_COST |
0x1C | SHR | 3 | BASE_OPCODE_COST |
0x1D | SAR | 3 | BASE_OPCODE_COST |
0x30 | ADDRESS | 2 | BASE_OPCODE_COST |
0x31 | BALANCE | address_access_cost | address_access_cost |
0x32 | ORIGIN | 2 | BASE_OPCODE_COST |
0x33 | CALLER | 2 | BASE_OPCODE_COST |
0x34 | CALLVALUE | 2 | BASE_OPCODE_COST |
0x35 | CALLDATALOAD | 3 | BASE_OPCODE_COST |
0x36 | CALLDATASIZE | 2 | BASE_OPCODE_COST |
0x37 | CALLDATACOPY | 3 + 3 * data_word_size + memory_expansion_cost | BASE_OPCODE_COST + COPY_PER_WORD_COST * data_word_size + memory_expansion_cost |
0x38 | CODESIZE | 2 | BASE_OPCODE_COST |
0x39 | CODECOPY | 3 + 3 * data_word_size + memory_expansion_cost | BASE_OPCODE_COST + COPY_PER_WORD_COST * data_word_size + memory_expansion_cost |
0x3A | GASPRICE | 2 | BASE_OPCODE_COST |
0x3B | EXTCODESIZE | address_access_cost | address_access_cost |
0x3C | EXTCODECOPY | 0 + 3 * data_word_size + memory_expansion_cost + address_access_cost | COPY_PER_WORD_COST * data_word_size + memory_expansion_cost + address_access_cost |
0x3D | RETURNDATASIZE | 2 | BASE_OPCODE_COST |
0x3E | RETURNDATACOPY | 3 + 3 * data_word_size + memory_expansion_cost | BASE_OPCODE_COST + COPY_PER_WORD_COST * data_word_size + memory_expansion_cost |
0x3F | EXTCODEHASH | address_access_cost | address_access_cost |
0x41 | COINBASE | 2 | BASE_OPCODE_COST |
0x42 | TIMESTAMP | 2 | BASE_OPCODE_COST |
0x43 | NUMBER | 2 | BASE_OPCODE_COST |
0x45 | GASLIMIT | 2 | BASE_OPCODE_COST |
0x46 | CHAINID | 2 | BASE_OPCODE_COST |
0x47 | SELFBALANCE | 5 | BASE_OPCODE_COST |
0x50 | POP | 2 | BASE_OPCODE_COST |
0x51 | MLOAD | 3 | BASE_OPCODE_COST |
0x52 | MSTORE | 3 + memory_expansion_cost | BASE_OPCODE_COST + memory_expansion_cost |
0x53 | MSTORE8 | 3 + memory_expansion_cost | BASE_OPCODE_COST + memory_expansion_cost |
0x56 | JUMP | 8 | BASE_OPCODE_COST |
0x57 | JUMPI | 10 | BASE_OPCODE_COST |
0x58 | PC | 2 | BASE_OPCODE_COST |
0x59 | MSIZE | 2 | BASE_OPCODE_COST |
0x5A | GAS | 2 | BASE_OPCODE_COST |
0x5C | TLOAD | 100 | WARM_STORAGE_READ_COST |
0x5D | TSTORE | 100 | WARM_STORAGE_READ_COST |
0x5B | JUMPDEST | 1 | BASE_OPCODE_COST |
0x5E | MCOPY | 3 + 3 * data_word_size + memory_expansion_cost | BASE_OPCODE_COST + COPY_PER_WORD_COST * data_word_size + memory_expansion_cost |
0x5F | PUSH0 | 2 | BASE_OPCODE_COST |
0x60 - 0x7F | PUSHx | 3 | BASE_OPCODE_COST |
0x80 - 0x8F | DUPx | 3 | BASE_OPCODE_COST |
0x90 - 0x9F | SWAPx | 3 | BASE_OPCODE_COST |
预编译成本
预编译 | 名称 | 当前 Gas | 建议 Gas |
---|---|---|---|
0x07 | ECMUL | 6000 | 2700 |
0x08 | ECPAIRING | 45000 + 34000 * sets_count | 8000 + 7000 * sets_count |
0x0A | POINTEVAL | 50000 | 21000 |
计算和重新调整的 0x06 (ECADD) 的成本高于当前成本。但此成本保持不变,以保持与现有合约的兼容性。
其余的预编译保持不变。
此外,所有预编译都受益于 *CALL 操作码的降低成本(见下文)。
间接更改
这些操作码的公式保持不变,但计算的总成本会受到某些组件更改的影响。
操作码 | 名称 | 受影响的公式组件 |
---|---|---|
0x54 | SLOAD | storage_access_cost |
0x55 | SSTORE | storage_access_cost |
0xF0 | CREATE | memory_expansion_cost |
0xF5 | CREATE2 | memory_expansion_cost |
0xF1 | CALL | memory_expansion_cost, address_access_cost |
0xFA | STATICCALL | memory_expansion_cost, address_access_cost |
0xF4 | DELEGATECALL | memory_expansion_cost, address_access_cost |
0xF3 | RETURN | memory_expansion_cost |
0xFD | REVERT | memory_expansion_cost |
原理
Gas 成本估算器项目
Gas 成本估算器项目是此 EIP 的经验基础。该项目在七个广泛使用的 EVM 实现中进行了广泛的测试,以测量各种操作码和操作所需的实际计算工作量。在受控环境中进行,以消除外部变量,这些测试产生了准确且可重现的结果。发现突出了当前 gas 成本计划与 EVM 操作的实际计算复杂度之间的不一致。通过根据这些测量结果重新校准 gas 成本,此 EIP 旨在使定价与计算现实保持一致,从而提高以太坊的性能和弹性。
此 EIP 基于 Gas 成本估算器项目的激进的提案。这意味着所有估算值都已额外重新调整,以便基本算术运算仅花费 1 个 gas 单位。使用的 rescale factor
是 Gas 成本估算器项目中定义的 0.217391304。将此提案与其他 EIP 或项目进行比较时,应使用此因子。
其他项目
一些计划已经探索了 EVM 操作的实际 gas 成本,为该 EIP 提供了有价值的背景信息。值得注意的例子包括:
- EIP-7883 - ModExp Gas 成本增加:此 EIP 专门分析了 ModExp 并提出了修改后的定价方案。当使用我们的
rescale factor
进行调整时,其成本与此提案一致,无需进一步更改。这种一致性验证了我们的测量方法。 - Nethermind 的 Gas 基准测试:此项目采用不同的方法来测量 gas 成本。它使用独立的客户端而不是隔离的 EVM 实现。尽管方法不同,但其结果与 Gas 成本估算器的结果相似,从而加强了我们的结论。
- @raxhvl 的 EVM 内存分析:此项目侧重于与内存相关的成本,提供了对内存访问和扩展成本的宝贵见解。我们的提案将这些发现纳入
memory_expansion_cost
公式中。
这些项目共同确认了重新评估 gas 成本的必要性,并证明了与我们方法之间的广泛一致性。
小数 Gas 价格
在此 EIP 开发过程中考虑的另一种替代方案是小数 gas 定价,这将能够根据计算工作量进行更精细的成本分配。
- 优点:这可以更精确地反映资源使用情况,从而提高公平性和效率 - 尤其是在 gas 成本降至 1 以下时(例如,对于激进重新缩放下的简单操作接近 0)。
- 缺点:它带来了重大的实际挑战,需要对 gas 计量基础设施进行大量修改。潜在的好处并不超过这些实施障碍。
考虑到这些权衡,我们选择不使用小数定价,而选择更简单、更可行的重新校准。
仅限计算复杂度
此 EIP 有意只考虑计算复杂度(以裸 CPU 上的执行时间来衡量),同时排除网络相关成本,例如状态持久性。这确保了提议的 gas 成本调整与实现无关,适用于各种 EVM 客户端,而与其技术堆栈无关。通过利用来自多个 EVM 实现的经验数据,我们为计算工作量建立了一个通用的、可验证的基准。与网络成本不同,网络成本会随着长期状态持久性或区块链大小等因素而波动,计算复杂度可以直接量化。这种关注简化了估算,并提高了提案在以太坊各种生态系统中的清晰度和适用性。
Gas 成本变更的影响
请注意,由于与 gas 限制和硬编码 gas 限制相关的向后兼容性问题,降低 gas 成本更安全(请参见下文)。决定是否增加或减少特定操作的 gas 成本需要平衡效率和安全性。
- 降低 Gas 成本:降低定价过高的操作的成本可以通过允许每个区块更多的交易来提高网络吞吐量,从而提高以太坊的可扩展性。但是,如果成本降低得过于激进,则可能会低估计算密集型任务的价格,从而可能使网络面临 DoS 攻击的风险。
- 增加 Gas 成本:提高定价过低的操作的成本可以通过阻止滥用行为来加强安全性,但可能会增加交易费用并降低吞吐量。
此 EIP 采用保守策略,优先降低经验数据表明定价过高的操作的成本,同时确保任何降低都不会损害安全性。这种方法旨在优化效率,而不会引入新的漏洞。
内存扩展成本
此提案引入了简化的 memory_expansion_cost
公式。当前的公式结合了每个字的固定成本和额外的二次成本。后者被添加以防止利用过度内存使用的攻击。我们的发现得到了相关项目的支持,表明每个字的固定成本可以忽略不计,并且已在扩展内存的操作码中得到考虑。因此,修改后的公式仅保留二次成本,在降低总体 gas 成本的同时保持安全性。因此,前 22 个字的内存不会产生额外的成本,因为二次惩罚从超过此阈值开始。
估计的最大内存分配
下表比较了当前和提议的 gas 计划下的最大内存分配,这些分配针对不同的区块 gas 限制显示。
单次操作码内存分配: 此表显示了使用单个操作码可以实现的估计最大内存分配:
区块 Gas 限制 | 当前 Gas 计划 | 提议 Gas 计划 |
---|---|---|
30M | 123,169 字 | 123,935 字 |
36M | 134,998 字 | 135,764 字 |
60M | 174,504 字 | 175,271 字 |
多次调用内存分配: 此表估计了使用在循环中重复进行子调用的交易可以实现的最大内存分配,直到达到区块 gas 限制为止。每个子调用都以最有效的方式分配内存,从而平衡调用成本和内存扩展成本。对于当前的 gas 计划,每次调用 278 个字,对于提议的 gas 计划,每次调用 93 个字。
区块 Gas 限制 | 当前 Gas 计划 | 提议 Gas 计划 |
---|---|---|
30M | 7,459,574 字 | 82,058,736 字 |
36M | 8,951,600 字 | 98,470,539 字 |
60M | 14,919,426 字 | 164,117,565 字 |
堆栈深度和递归调用的实验表明,与当前 Gas 计划相比,单一时刻分配的最大总内存的增加幅度小于 10%。
考虑 ZK-SNARK 证明生成 (EIP-7667)
EIP-7667 提出了一个用于测量资源消耗的替代框架,强调了生成 ZK-SNARK 证明的需求 - 这是以太坊越来越重要的领域。这包括哈希操作码和预编译,它们在 ZK-SNARK 环境中计算密集。有两个动机驱动 EIP-7667:首先,ZK-SNARKed 以太坊 Layer 1 (L1) 的长期愿景,其中此类操作将至关重要;其次,基于 ZK 的 Layer 2 (L2) 解决方案面临的直接挑战,这些解决方案通常限制哈希操作以管理成本。相比之下,此 EIP 使用裸 CPU 作为其参考点,专注于一般计算复杂度,而不是 ZK 特定的需求。预计所提出的更改不会显着改变基于 ZK 的 L2 的平均情况,但可能会影响最坏情况。虽然承认 ZK-SNARK 的相关性,但此 EIP 认为它们的系统性挑战需要超出此提案范围的不同的解决方案。该领域正在努力并取得进展,但 ZK-SNARKed L1 的愿景似乎足够遥远,足以证明专注于优化当前设置以获得更广泛的网络效益是合理的。
考虑增加区块 Gas 限制 (EIP-7790)
降低计算 gas 成本旨在提高交易吞吐量,允许每个区块更多的交易。EIP-7783 和 EIP-7790 通过提高区块 gas 限制来追求类似的结果 - 一种影响可控的更简单方法。但是,它们不会解决定价错误的操作码和预编译。我们的提案通过纠正定价不准确来补充这些努力,并且应该一起实施这两种策略,以在确保成本准确性的同时最大化吞吐量。
考虑存储成本
通过实施该提案,总体计算成本将降低,而存储成本保持不变。这反映了 EVM 软件效率的提高和不断增长的状态的成本。通过增加计算成本和存储成本之间的相对差距,该提案间接激励开发人员优化其合约并减少状态大小。这是该提案的积极副作用。
地址和存储访问成本
该提案修改了 address_access_cost
和 storage_access_cost
的两个公式,但仅适用于热数据。这是因为可以使用此处使用的相同方法进行估计。冷访问成本是多层的,并且取决于区块链状态、其大小和数据结构。准确的测量需要设计更合适的方法。
两个存储操作码 SLOAD 和 STORE 已间接更新。它们的成本公式很复杂,并且仅修改了热/冷数据访问成本比率。CREATE 和 CREATE2 也是如此。仅修改了内存扩展成本因子,该因子是计算性的,并且与其他可能扩展内存的操作码一致。
预编译
对于 MODEXP 预编译,此提案假定采用 EIP-7883,并且其 gas 成本保持不变。对于 ECPAIRING,gas 成本降低了大约 5 倍,与此提案中的类似调整一致。ECRECOVER、IDENTITY、ECADD、ECMUL、BLAKE2F 和 POINTEVAL 等预编译要么保留其当前的 gas 成本,要么略有降低。
像 Nethermind 的 Gas 基准测试之类的项目强调了一个安全问题:降低 ECRECOVER 的 gas 成本可能会导致最坏的情况,即区块计算时间超过安全阈值。类似的问题适用于 MODEXP。因此,即使有进一步降低的空间,rescale factor
也不能低于提议的 0.217391304
。请注意,区块中的最大操作数取决于 gas 成本计划和区块 gas 限制。
Gas 成本估算器项目建议略微增加 ECRECOVER 的 gas 成本,但此提案避免了该更改,以保持向后兼容性,并且因为影响很小。
哈希
哈希操作、预编译 SHA2-256、RIPEMD-160、BLAKE2F 和 KECCAK256 操作码在此处有意不更新。基于当前主网 EVM 实现的检查发现了可以并且应该修改的设置。假设此 EIP 中提出的更改作为参考,主要发现包括:
- BLAKE2F 的 gas 成本应保持不变。
- KECCAK256 的每个字的 gas 成本应保持不变,基本成本降低 3 倍。
- 对于 SHA2-256 和 RIPEMD-160,每个字的 gas 成本应降低 3 倍。
另一方面,基于 ZK 的 EVM 最近在 Layer 2 和未来的主网上出现。这些解决方案在生态系统中发挥着重要作用。此外,由于正在努力优化有关哈希操作的 ZK 证明,因此情况是动态的。这些操作的 gas 成本变更应在另一个 EIP 中提出。
此外,检查揭示的潜在更改可能看起来很大,但不会恶化 EIP-7667 中概述的极端情况 - 它们是在完全填充哈希操作的区块中生成 ZK 证明的场景。
向后兼容性
由于提议的 gas 成本计划更改对其影响以太坊网络的操作机制,因此需要进行硬分叉。下面,我们概述了这些更改的主要后果,并重点介绍了需要进一步研究的领域,以确保平稳过渡。
这些变更具有以下后果:
- Gas 成本调整:
- 将修改各种操作码、预编译和其他操作(例如内存扩展和访问成本)的 gas 成本。
- 这些调整旨在更好地使 gas 定价与操作的计算复杂度保持一致,但是它们将直接影响执行交易和智能合约的成本。
- 交易 Gas 成本变更:
- 调用合约的任何交易的 gas 成本都很可能会发生变化。
- 这是由于在智能合约代码中广泛使用了受影响的操作码和操作。
- 开发人员和用户应为硬分叉后交易费用的潜在变化做好准备,这可能需要更新 gas 限制估算和费用预算。
- 对具有硬编码 Gas 限制的合约的影响:
- 如果新的 gas 成本超过这些限制,则为子调用指定硬编码 gas 限制(例如,使用 call(gas, …))的合约可能会面临问题。
- 此类合约可能无法按预期执行,从而可能导致交易失败或意外行为。
可能需要进行进一步的研究,以确保不破坏使用硬编码限制的合约。
测试用例
测试 1
代码:
PUSH1 0x60
Gas 成本:1
测试 2
代码:
PUSH2 0x0202
PUSH2 0x1000
EXP
Gas 成本:1 + 1 + (2 + 4 * 2) = 12
TODO: 此 EIP 是一个相对简单的更改,但需要在许多测试(规范、执行 API 等)中进行更新。由于更新测试需要付出努力,因此只有在 EIP 被接受后才能提供
参考实现
Go-Ethereum 中的参考实现提供了新的指令集和新的 memoryGasCost
函数。此外,它还包含一组特定 gas 元素的替代项。实际的实现需要对替代项进行正确的版本控制。
const (
RepricedGasBaseStep uint64 = 1
RepricedGasFastStep uint64 = 2
RepricedGasMidStep uint64 = 3
//overrides
WarmStorageReadCost uint64 = 100 // WARM_STORAGE_READ_COST
ExpGas uint64 = 2 // Once per EXP instruction
ExpByteGas uint64 = 4 // One per byte of the EXP exponent
CopyGas uint64 = 1 // One per word of the copied code
// (CALLDATACOPY, CODECOPY, EXTCODECOPY,
// RETURNDATACOPY, MCOPY)
)
func newRepricedInstructionSet() JumpTable {
instructionSet := newPragueInstructionSet()
// 重新定价的指令集
instructionSet := newPragueInstructionSet()
for _, op := range instructionSet {
if op.isPush || op.isDup || op.isSwap ||
op.constantGas == GasFastestStep || op.constantGas == GasFastStep {
op.constantGas = RepricedGasBaseStep
}
}
instructionSet[ADDMOD].constantGas = RepricedGasFastStep
instructionSet[MULMOD].constantGas = RepricedGasMidStep
instructionSet[TLOAD].constantGas = WarmStorageReadCost
instructionSet[TSTORE].constantGas = WarmStorageReadCost
validateAndFillMaxStack(&instructionSet)
return instructionSet
}
func memoryGasCost(mem *Memory, newMemSize uint64) (uint64, error) {
if newMemSize == 0 {
return 0, nil
}
if newMemSize > 0x1FFFFFFFE0 {
return 0, ErrGasUintOverflow
}
newMemSizeWords := ToWordSize(newMemSize)
newMemSize = newMemSizeWords * 32
if newMemSize > uint64(mem.Len()) {
square := newMemSizeWords * newMemSizeWords
newTotalFee := square / params.QuadCoeffDiv
fee := newTotalFee - mem.lastGasCost
mem.lastGasCost = newTotalFee
return fee, nil
}
return 0, nil
}
安全考虑事项
与此提案相关的主要风险是潜在的 DoS 攻击。通过降低 gas 成本,该提案可能会无意中使某些操作更经济实惠,从而使攻击者可以出于恶意目的利用它们。为了缓解此风险,该提案侧重于降低定价过高的操作的 gas 成本,确保调整不会损害网络安全性。通过维持操作的相对成本,该提案确保即使在最坏的情况下,降低的价格也不会产生新的漏洞。
降低的内存扩展成本仍然保持了成本的二次性质,从而防止了利用过度内存使用的攻击。EIP‑7825解决了任何现有的考虑事项。
该提案未解决 EIP-7667 中提出的问题,但它并未恶化该 EIP 中概述的极端情况。
版权
版权和相关权利已通过 CC0 放弃。
Citation
Please cite this document as:
Jacek Glen (@JacekGlen), Lukasz Glen (@lukasz-glen), "EIP-7904: 通用重定价 [DRAFT]," Ethereum Improvement Proposals, no. 7904, February 2025. [Online serial]. Available: https://eips.ethereum.org/EIPS/eip-7904.