多维 Gas 计量的一种实用提案 - 执行层研究

本提案由我和 @dcrapis 共同撰写

\ fbce230bf72eb1324e03fa2e200e1cfb9044f4c38b748dadc305fd9a2c70c2f01024×1024 136 KB

我们要感谢来自 @soispoke, @Julian, @adietrichs, 和 @vbuterin 的讨论、评论和审查。

动机

在以太坊中，我们使用 gas 作为衡量 EVM 两个重要概念的指标。一方面，gas 用于衡量交易对资源的消耗。交易使用的资源越多，支付的交易费用就越多。另一方面，gas 也用于控制资源限制，并确保区块不会使网络过载。目前，验证者强制执行每个区块 3600 万 gas 单位的限制。如果一个区块需要的 gas 超过这个限制，它将被认为是无效的。

我们可以将 gas 的第一种用途视为“交易定价”，第二种用途视为“区块计量”。因为相同的指标一直代表着这两个概念，所以很自然地认为它们是可以互换的。但是，我们认为我们可以将它们分开考虑，事实上，这样做是有好处的。更具体地说，我们可以引入一个多维计量方案，该方案考虑了不同的 EVM 资源，同时保持定价模型不变。

但是，这样做有什么好处呢？首先，使用多维方案来计量资源可以让我们更有效地打包区块。在这些方案中，即使一个区块已经达到了一个资源的限制，如果它们不使用瓶颈资源，我们仍然可以将更多的交易添加到该区块中。例如，一个已经因调用数据而“满”的区块仍然可以包含不花费 gas 在调用数据上的计算密集型交易。 Vitalik 的这篇博客文章很好地解释了为什么当前的一维方案不是最佳的。

根据我们之前的实证分析，假设历史交易的需求是无限的，一个分离计算、状态增长、状态访问和所有其他资源的四维计量方案将允许交易吞吐量增加约 240%。

其次，即使完全多维定价能够实现更灵活的定价，但这种灵活性是以终端用户和开发者更糟糕的 UX 体验（因为他们现在必须处理多个基本费用和 gas 限制）以及增加激励来捆绑交易以节省交易费用为代价的。此外，EVM 的约束（例如在子调用中）使得多维定价的实施在技术上具有挑战性。换句话说，目前尚不清楚多维定价的优势是否大于潜在问题。单独更改计量方案时，这种权衡会更加明显。

新的计量方案

我们建议将 多维计量 作为一种改变我们计算一个区块中使用的 gas 的方式。这使我们可以充分利用每个单独资源的 gas 限制，同时仍保持在安全限制内，并在不更改 gas 限制的情况下产生显着的吞吐量提升。此外，交易 UX 和向用户收取的费用结构保持不变。

新的计量方案引入了一个名为 block.gas_metered 的新变量。在交易执行期间，我们沿每个资源维度（计算、状态、访问、内存等）计量使用的 gas，例如 (r_1, ... r_k)。然后我们计算

block.gas_metered = max(r_1, ... r_k),

而当前 gas 使用定义的公式是

block.gas_used = sum(r_1, ... r_k).

从用户的角度来看，一切都保持不变。一笔交易仍然只有一个 tx.gas_limit，并根据实际的 tx.gas_used 支付。 tx.gas_used 和 tx.gas_limit 仍然用于检查交易的“out-of-gas”情况（如果在交易执行期间 tx.gas_used 超过 tx.gas_limit，则交易将被回滚）。

在区块级别，block.gas_metered 在 (1) 区块有效性条件 和 (2) EIP-1559 费用更新计算中取代了 block.gas_used。

LIMIT = 36_000_000
TARGET = LIMIT // 2

## sender is charged based on sum of resources
# 收款人根据资源总和收费
def compute_price_for_usage(tx_bundle):
   return basefee * sum(tx_bundle)

## block limit is enforced on the highest individual resource
# 区块限制在最高的单个资源上执行
def is_valid_consumption(block_bundle):
   return max(block_bundle) <= LIMIT

## basefee is updated using the highest individual resource
# 基本费用使用最高的单个资源更新
def compute_new_excess_gas(block_bundle):
   return max(0, excess_gas + max(block_bundle) - TARGET)

此提案具有以下属性：

• 增加资源利用率
• 保持每个资源的安全限制
• 不改变 UX

与其他多维定价方法相比，此更改相对简单，并且以适度增加的复杂性带来了显着改进。特别是，最佳区块构建变得更加困难，但仍然可以使用简单的启发式方法来生成区块。协议更改涉及 (i) 引入计算以外的资源 gas 成本计划，以及 (ii) 计量每个资源使用的 gas。请注意，由于计算以外的资源由相对较少数量的操作码使用，因此这将仅涉及将 gas 成本参数的数量从今天的约 100 个增加到约 150 个，以考虑所有其他资源。

除了直接产生显着收益之外，这项改进还是释放多维定价未来收益的重要垫脚石。

例子

block.gas_target 和 block.gas_limit 保持不变，分别为 18m 和 36m。假设我们得到一个区块，其中每个资源的需求 profile（以百万 gas 单位衡量）为 (18, 9, 9, 6, 3)，其中向量中的每个维度都是分配给单个资源的 gas。根据当前的规范，此区块将无效，因为 sum(18, 9, 9, 6, 3) = 45 超过了 gas 限制 900 万 gas 单位。使用新的提案，计量的 gas 为 max(18, 9, 9, 6, 3) = 18，这使得该区块有效，也正好达到目标，因此 gas 费用不会改变。假设我们随后得到一个区块，其中第二个资源的负载很高 (18, 30, 9, 6, 3)，block.gas_metered = 30 百万 gas 单位。虽然它仍然是一个有效的区块，因为它低于限制，但基本费用会增加，因为它高于目标。

接下来步骤

需要回答两个关键问题才能完全指定此提案。首先，我们需要定义我们要跟踪的资源。最初的 gas 模型旨在考虑以下资源：

• 计算：执行/CPU 成本，表示合约执行期间执行的计算工作。
• 内存：一个临时的、可扩展的区域，在执行期间用于临时数据存储，在交易完成后清除。
• 状态：所有帐户余额、合约存储和代码的当前快照，维护在 Merkle Patricia Trie 中。
• 历史：存储在链上的交易和状态转换的完整记录，使节点能够重建过去的状态。历史可以被修剪，这是与状态的关键区别。
• 读/写访问：验证来自 Merkle trie 的状态读/写所需的数据量（证明组件），影响验证成本和效率。
• 带宽：共享区块内容的成本，即区块大小（以 Kb 为单位）。
• Bloom Topic：来自事件主题的 32 字节哈希值，合并到 2048 位 Bloom 过滤器中，用于高效的日志过滤和查询加速。

问题是新的计量系统是否应该跟踪这些相同的资源。是否应该添加任何其他资源（例如，证明成本）？是否应合并某些资源以简化计量？根据我们之前的分析，至少分离计算、状态和访问有明显的收益，因为这些是我们数据中的瓶颈资源。但是，我们可能希望隔离更多资源，以使此提案具有前瞻性。

第二个问题是如何正确地将每个 EVM 操作的总 gas 成本分解为各种资源。一旦我们定义了资源，我们就可以在各种 EL 客户端上执行基准测试，以测量每个 EVM 操作（操作码、预编译等）使用的资源。当然，这需要定义如何衡量资源的使用情况。例如，对于计算，我们可以使用执行时间，而对于带宽，我们可以跟踪区块大小（以 Kb 为单位）。一旦我们获得了每个操作的资源使用情况，我们就可以为每个资源设置安全限制，然后将它们转换为 gas 单位。

这些基准测试与当前增加 gas 限制的工作紧密相关。在这里，客户端团队已经在设置基准测试和测试来分析网络性能。一个很好的例子是 Gas Cost Estimator Project，它在不同的客户端上实施了一个全面的基准测试，重点是计算成本。此外，这项工作与最近的重定价工作密切相关，例如 EIP-7904 和 EIP-7883。

• 走向多维 - 对 EVM 中 gas 计量的实证分析

• 原文链接： ethresear.ch/t/a-practic...
• 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～