tps://etherscan.io/tx/0xc5195b64cc333b8098d71fbd0f032e05d4545917e3b0be8d123ab06e1ad7998e）总共花费了 47,085 Gas。这分为 (i) 21000 Gas 的“基本成本”，(ii) 作、包含部分交易的调用数据字节的 1556 Gas，(iii) 用于读取和写入存储的 16500 Gas，(iv) 用于生成日志的2149 Gas，其余用于 EVM 执行。用户必须支付的交易费用与交易消耗的gas成正比。一个区块最多可包含 3000万 Gas，并且 Gas 价格通过EIP-1559 目标机制不断调整，确保区块平均包含1500万 Gas。 这种方法有一个主要效率：因为所有东西都合并到一个虚拟资源中，所以它导致了非常简单的市场设计。优化交易以最小化成本很容易，优化区块以收取尽可能高的费用相对容易（不包括MEV），并且没有奇怪的激励措施鼓励某些交易与其他交易捆绑在一起以节省费用。 但这种方法也有一个主要的低效率问题：它将不同的资源视为可以相互转换，而网络可以处理的实际潜在限制却并非如此。理解这个问题的一种方法是看这个图： Gas 限制强制执行以下约束：x1*data+x2*computationTARGET, 0) 这里TARGET = 3。也就是说，如果一个区块的blob 数量多于目标，excess_blobs则增加，如果区块的 blob 数量少于目标，则减少。然后我们设置blob_basefee = exp(excess_blobs / 25.47)，其中exp是指数函数的近似值exp（x）。 也就是说，每当excess_blobs增加约 25 倍时，blob 基本费用就会增加约 2.7 倍。如果 blob 变得太贵，平均使用量就会下降，然后excess_blobs开始下降，从而自动再次降低价格。 Blob 的价格不断调整，以确保平均而言，区块是半满的 - 也就是说，每个区块平均包含 3 个 Blob。 如果使用量出现短期峰值，则会出现限制：每个区块最多只能包含 6 个 blob，在这种情况下，交易可以通过提高优先费来相互竞争。然而，在正常情况下，每个 blob 只需要支付blob_basefee加一点额外的优先权费用，作为被纳入的激励。 这种 Gas 定价在以太坊中已经存在多年：早在 2020 年，EIP-1559就引入了非常相似的机制。通过 EIP-4844，我们现在有两个单独的 Gas 和 Blob 浮动价格。 2024 年 5 月 8 日一小时内的 Gas 基本费用，单位为 gwei。来源：ultrasonic.money 原则上，我们可以为存储读取和其他类型的操作添加更多单独浮动的费用，但有一个警告，我将在下一节中详细说明。 对于用户来说，这种体验与今天非常相似：你不再支付一笔基本费用，而是支付两项基本费用，但你的钱包可以将其从你那里抽象出来，只向你显示你可以预期支付的预期费用和最高费用。 对于区块构建者来说，大多数时候最佳策略与今天相同：包括任何有效的内容。大多数区块都未满——无论是gas还是blob。一个具有挑战性的情况是，当有足够的gas或足够的blob超过区块限制时，构建者需要潜在地解决多维knapsack问题以最大化其利润。然而，即使存在相当好的近似算法，在这种情况下，通过制定专有算法来优化利润所获得的收益也比使用 MEV 进行相同操作所获得的收益要小得多。 对于开发者来说，主要挑战是需要重新设计 EVM 及其周边基础设施的功能，这些基础设施目前是围绕一个价格和一个限制设计的，而设计为适应多个价格和多个限制的设计。应用程序开发人员面临的一个问题是优化变得稍微困难 ：在某些情况下，你不能再明确地说 A 比 B 更高效，因为如果 A 使用更多的 calldata 而 B 使用更多的执行，那么当 calldata 为便宜，当 calldata 昂贵时则更昂贵。然而，开发者仍然能够通过根据长期历史平均价格进行优化来获得相当好的结果。 多维定价、EVM 和子调用（sub-calls） 有一个问题不会出现在 blob 中，也不会出现在 EIP-7623 中，甚至不会出现在 calldata 的“完整”多维定价实现中，但如果我们尝试单独对状态访问或任何其他资源进行定价，则会出现这个问题：子调用中的gas 限制。 EVM 中的 Gas 限制存在于两个地方。首先，每笔交易都会设置一个 Gas 限制，该限制限制了该交易中可以使用的 Gas 总量。其次，当一个合约调用另一个合约时，该调用可以设置自己的gas limit。这允许合约调用他们不信任的其他合约，并且仍然保证他们在调用后仍有剩余的gas来执行其他计算。 帐户抽象交易的踪迹，其中一个帐户调用另一个帐户，并且仅向被调用者提供有限数量的gas，以确保即使被调用者消耗了分配给它的全部gas，外部调用也可以继续运行。 挑战在于：在不同类型的执行之间使 Gas 成为多维的，似乎需要子调用来为每种类型的 Gas 提供多个限制，这将需要对 EVM 进行真正深入的更改，并且与现有应用程序不兼容。 这就是多维gas提案通常停留在两个维度的原因之一：数据和执行。数据（无论是交易 calldata 还是 blob）仅在 EVM 外部分配，因此 EVM 内部无需更改任何内容即可使 calldata 或 blob 单独定价。 我们可以想出一个“EIP-7623式的解决方案”来解决这个问题。这是一种简单的实现：在执行期间，对存储操作收取 4 倍的费用；为了简化分析，我们假设每个存储操作为10000 gas。交易结束，退款min(7500 * storage_operations, execution_gas)。结果是，在扣除退款后，用户需要支付以下费用： execution_gas + 10000 * storage_operations - min(7500 * storage_operations, execution_gas) 这等于： max(execution_gas + 2500 * storage_operations, 10000 * storage_operations) 这反映了 EIP-7623 的结构。另一种方法是实时跟踪storage_operations和execution_gas，并根据调用操作码时上涨的金额max(execution_gas + 2500 * storage_operations, 10000 * storage_operations)多少收取 2500 或 10000 gas。这避免了交易需要过度分配天gas，而这些gas主要通过退款来收回。 我们没有获得子调用的细粒度许可：子调用可能会消耗交易的所有“津贴”以进行廉价的存储操作。但我们确实得到了足够好的东西，其中进行子调用的合约可以设置限制，并确保一旦子调用完成执行，主调用仍然有足够的gas来执行它需要执行的任何后处理。 我能想到的最简单的“完整的多维定价解决方案”是：我们将子调用gas限制视为成比例。也就是说，假设有 ?个不同类型的执行，每笔交易设置多维度限制?1…??。假设在当前执行点，剩余gas 为?1…??。假设CALL调用了一个操作码，带有子调用gas limit S。让s1=S， 进而s2=s1/g1*g2,s3=s1/g1*g3， 等等。 也就是说，我们将第一种类型的gas（实际上是虚拟机执行）视为一种特权“帐户单位”，然后分配其他类型的gas，以便子调用在每种类型建获得相同百分比的可用gas。这有点难看，但它最大限度地提高了向后兼容性。如果我们想让方案在不同类型的gas之间更加“中立”，以牺牲向后兼容性为代价，我们可以简单地让子调用gas limit参数代表剩余gas的一小部分（例如[1...63] / 64）。 然而，无论哪种情况，值得强调的是，一旦开始引入多维执行gas，固有的丑陋程度就会增加，这似乎很难避免。 因此，我们的任务是做出一个复杂的权衡：我们是否接受 EVM 级别的一些更丑陋的东西，以便安全地释放显著的 L1 可扩展性收益，如果是这样，哪种具体建议最适合协议经济学和应用程序开发人员？ 很可能，它不是我上面提到的任何一个，并且仍然有空间想出更优雅、更好的东西。 特别感谢Ansgar Dietrichs、Barnabe Monoton 和 Davide Crapis的反馈和审查。 来源：金色财经lg...
北美站
