一、动机
交易在内存池、共识和执行中的优先级基于单位 Gas 价格——每个交易承诺为每单位 Gas 支付的价格（以 APT 为单位）。客户端需要一种方法来估计他们应该使用什么单位 Gas 价格，以便在合理的时间内在链上执行交易。本提案包含了一个设计，其中 Aptos 全节点提供一个 API，供客户端用于此目的。
二、基本原理
每个客户端必须使用一个满足他们当前成本-延迟权衡的评估。换句话说，为了给出一个好的预估，有竞争的关注点有：
- 客户端希望在合理的时间内执行交易
- 客户端希望支付最少的 Gas 费用，以便在合理的时间内执行交易。
单位Gas价格估计的前一种实现使用了单位 Gas 费用的滚动平均值作为估计。这无法提供（2），因为价格没有“重置”——一旦 Gas 费用上升，大多数客户端都在使用预估 API ，即使系统的负载小到不需要额外的 Gas 费用，费用也无法降下来。
三、规范
我们提出一个基于 Aptos 区块链的负载，以及历史单位 Gas 费用支付的设计。从高层次来看，我们将提供一个估计，用于获取进入下一个区块所需的 Gas 单位价格。估计是基于近期历史的，但是无法预测未来。因此，API提供了三个值——低、市场和激进——基于估计的置信度，客户端可以根据他们当前的成本-延迟权衡使用。
（我们从以太坊的 EIP-1559 中得到启发，它使用区块负载和 Metamask 提供的基于这些信息的低、市场和激进的 Gas 费用。尽管细节上有很大的偏差，但是是基于 Aptos 区块链的构建方式。）
1. 满区块
我们考虑区块是否“满”；如果区块不满，那么我们不应该提高 Gas 估计，无论包含在非满区块中的交易支付了什么。我们可以分类满区块，如果它们满足以下任一条件：
- **交易计数。**在共识和执行中，区块受到交易计数和大小的限制。在大多数情况下，交易计数可以作为负载的衡量——如果达到最大交易计数，区块就完全加载，如果没有，则区块仍有空间用于交易。 交易在 Quorum Store 批次中添加到区块，所以最大交易计数可能会有一些碎片化，例如，最后考虑的批次不适合在区块中，所以区块比最大的小，但仍然被认为是完全加载的。 区块的最大交易计数由提议者根据当前区块链性能动态调整。为了单位 Gas 价格估计的目的，我们建议使用最小可能的最大交易计数作为完全加载区块的指标。然后我们将这个值除以二，以考虑到 Quorum Store 批处理的碎片化。 使用当前默认配置，最小区块大小是250个交易，所以满区块阈值将是125个交易。
- **Gas 使用。**AIP-33 提出了每个区块的 Gas 限制。这意味着一个区块可以有少量的交易，因为执行的交易达到了 Gas 限制。因此，Gas使用量高的区块也被分类为满。
2. 区块中包含的最小Gas单价
每个区块都有一个最小包含价格 （min_inclusion_price），即保证包含在区块中的最低 Gas 单价。对于非满区块，我们简单地将 min_inclusion_price 设置为100，这是最小的系统 Gas 单价。这是因为无论 Gas 单价如何，交易都会被包含进来。
对于满区块，我们取区块中最小的 Gas 单价，然后提高 Gas 桶，取下一个 Gas 桶的最小端。这是因为在传播过程中，无论是在内存池还是 Quorum Store，交易都是在桶内进行批处理的，所以最小的保证包含是一个更高的桶。
3. 目标和公式
我们定义以下宽松的目标，并在下面给出它们的公式。调用估计 API 将返回以下三个值 - 为了向后兼容，旧 API 将返回市场。
- 低：取过去10个区块中 min_inclusion_price 的最小值。
- 市场：取最后30个区块中 min_inclusion_price 的p50。
- 激进：取最后120个区块中 min_inclusion_price 的 p90。此外，向上取整到下一个 Gas 桶。
更激进的值查看更大的时间窗口，并取更高的百分位数，以增加交易将在接下来的几个区块中被包含的把握。最激进的值还提高了一个额外的 Gas 桶，增加了交易传播不会被延迟的把握。
注意，因为对于非满区块，min_inclusion_price = 100，观察非满区块将重置所有三个值，无论交易中使用的 Gas 费用如何，例如，低将在过去10个区块中的任何一个非满区块重置，市场将在最后30个区块中有15个非满区块时重置，激进将在最后120个区块中有108个非满区块时重置。
4. 示例
我们说明了这在不同场景下是如何工作的，我们提供了一些简单的示例，使用当前的系统配置。
(A) 区块链负载较轻，所以在最后120个区块中没有满区块。估计是：
- 低：100（= 最小系统 Gas 单价）
- 市场：100
- 激进：150（= 下一个桶的最小值）
(B) 区块链负载很重，最后120个区块中只有满区块，但所有交易都使用最低的 Gas 单价。估计是：
- 低：150（= 下一个桶的最小值 > 100）
- 市场：150
- 激进：300（= 下一个桶的最小值 > 150）
(B) 区块链负载适中，类似于上面，但在最后10个区块中至少有一个非满区块。估计是：
- 低：100（= 最小系统 Gas 单价）
- 市场：150（= 下一个桶的最小值 > 100）
- 激进：300（= 下一个桶的最小值 > 150）
四、参考实现
- https://github.com/aptos-labs/aptos-core/pull/8186
- AIP-33 后的兼容性变更: https://github.com/aptos-labs/aptos-core/pull/8208
五、风险和缺点
- 我们对如何分类小的满区块非常保守。这可能导致尽管负载适中，但 Gas 费用仍然上升。
- 依赖于共识配置，特别是链健康和背压配置。公式依赖于最小完全加载区块的共识配置。因此，对这个共识配置的任何更改都需要在 Gas 估计中进行更改。
六、未来潜力
- 目前，估计根据定义的目标提供三个值。如果有客户需求，一般框架可以扩展，并提供更细粒度的统计数据，如直方图。
七、建议的实施时间表
- 里程碑1（进行中）：在 v1.5 发布结束之前完成代码
八、建议的部署时间表
- 里程碑1（计划中）：切入 v1.5 版本
- 里程碑2（待定）：部署到全节点。客户端将使用向后兼容的“市场”值。
- 里程碑3（待定）：客户端使用新的 API 进行部署。这里也是这样的。