Aptos Labs 于 10 月 14 日公布了 Aptos 的 GAS 计划，因为 MOVE 语言的上一个版本其实是打算在没有 GAS 的前提下运行的，所以并没有为 GAS 计划做好准备，所以 Aptos labs 此次为 Aptos 建立的 GAS 计划是 MOVE 语言首个 GAS 设计，被官方称为「一场冒险」。
在 Aptos 的 GAS 计划中，Aptos Labs 表明了自己制定 GAS 的原则、流程、如何计算 GAS、后期 GAS 费调整以及积极接受 Aptos 社区的建议。
GAS 计量是 Aptos 和其他很多区块链的基本概念，它定义了执行和存储链上交易平台需的计算和存储资源量的抽象计算。GAS 计划将链上所有执行所消耗的成本确定，用于计算执行交易期间使用的 GAS 花费。
流程
为了有效的执行，我们在 Aptos 链上的流程是：
1）定义我们的原则；
2）准备一个评估框架，以确定每个执行的价格；
3）为 Move 建立 GAS 计量系统和安全 GAS 代数；
4）将上游 GAS 框架导入 Aptos；
5）使 GAS 框架具有存储意识；
6）最后，进一步细化 GAS 计划。
原则
我们的定义原则是:
1、操作的成本应该与网络上的可用资源直接相关 (例如 CPU、内存、网络、存储 I/O 和空间使用等)。此外，当技术和流程改进后，GAS 所需的成本应该要随之降低。
2、Gas 应该由链上治理设置，并且可以无缝配置。
3、Gas 可以防止对网络中固定资源集的 DoS 攻击，并且可能需要根据网络情况通过治理建议迅速进行调整。
4、Aptos 的 GAS 价格反映了 Aptos 基金会加速增长和保持区块链人人可及的愿望。
5、鼓励在设计中做出好的选择——例如优先考虑安全性、模块化、断言等事件。
计算 GAS
当用户提交交易时，他们还必须在事务中指定两个数量:
Max gas amount:以 GAS 单位计量。这是用户 (即，交易发送者) 愿意为执行交易花费的最大 GAS 单位数。
Gas unit price:以每单位 GAS 的八进制计算，其中 1 八进制=0.00000001 APT(=$10^{-8}$)。这是用户愿意支付的 GAS 价格。
在执行过程中，交易将被收取:
1）固定成本，固定基数加上大额交易的额外费用。
2）执行成本，用于执行 Move 指令。
3）读取成本，用于从持久存储读取数据。
4）写入成本，用于将数据写入持久存储。
最终的交易费用可以用消耗的 GAS 总量 (以 GAS 单位计算) 乘以 GAS 单价来计算。例如，如果一笔交易消耗 670 个 GAS 单位，而用户在交易中指定的天然气单位价格为每单位 100 Octa，那么最终的交易费用为 670 * 100 = 67000 Octa = 0.00067 APT。
如果一个交易在执行过程中耗尽了 gas，那么发送方将根据最大 gas 量收取费用，并且该交易平台做的所有更改都将被恢复。
建立一个 GAS 计划表
1、基本配置
GAS 计划中有几个组成部分与单个操作的细节无关，包括交易大小和最大 GAS 单位 (不同于用户在交易中指定的最大 GAS 量)。
2、交易规模
对于大多数交易，交易规模可能在千字节的数量级。然而，Move 模块的发布很容易就有几千字节，而 Aptos 框架大约有 100 KB。大多数用户模块的大小一般在 4KB 到 40KB 之间。最初，我们将交易规模的值设置为 32KB，但根据社区的反应，要求提供更多空间以简化应用程序开发，因此我们将交易规模调整为 64KB。
非常大规模的交易会导致整个网络的带宽成本提高，并可能对性能产生负面影响。如果被滥用，内存池会被鼓励忽略规模更大的交易，因此我们的方法是在最大规模交易的大小和可访问性之间取得平衡。
3、最大 GAS 单位
GAS 计划中的的最大 GAS 单位定义了一个交易最多可以执行多少操作。注意！这不同于用户在交易中指定的最大 GAS 量。
GAS 计划的最大 GAS 单位直接影响到一个交易可以执行多长时间，将其设置过高可能会导致对区块链产生负面性能影响交易。例如，用户可能忘记在 while 循环中有一个增量，从而导致无限循环，这是一个常见错误。我们发现，即使我们进行了最大的框架升级，我们仍然不到 gas 计划的最大 gas 单位（设定为 1,000,000）的 90%。
4、执行
为了评估执行成本，我们构建了一个基准框架，并在执行该框架时使用。
Valgrind 来分析 Move VM。它的输出是一组带注释的源代码，它告诉我们每行代码产生了多少机器指令。
在上述分析的帮助下，我们粗略估计了所有 Move 指令和本机函数的相对成本。然而，我们注意到这个方法与内联函数存在一些问题：它们不会自动包含在调用者的计数中。我们还看到，这只发生在我们分析某些 Move 指令时，我们可以通过将数字相加来解决这个问题。
随后，通过考虑增强系统稳健性和安全性的编码范例，团队得出了最终执行的机器指令数量。这个数字依次与存储和最大 GAS 单位进行权衡，以确定它们在 GAS 计划中的当前值。
5、存储
每当访问存储在持久存储中的账本状态项或数据时，Aptos 节点都会向存储设备发出读取或写入。每秒的数据访问总数取决于存储设备的带宽和 IOPS 容量。与 gas 调度计算部分的 CPU 周期类似，数据访问是区块链用户在系统负载时通过费用市场竞争的瞬时稀缺性，此外，写入数据的磁盘占用成本在链上是永久的。Aptos 团队通过考虑这些成本来设计存储 GAS 计划。
访问和存储任何状态项都会产生与验证整个区块链状态的数据结构
水母默克尔树相关的成本：
此成本与不同状态项的基数有关（$2^{256}$）。还有一个成本与每个项目的大小成正比。要对一个状态项进行操作，费用为（下一节中描述的例外情况除外）：
存储 GAS 费 = item_fee + (byte_fee * bytes)
读、创建和写
对状态项的任何访问都属于以下三种类型之一:读、创建或写。访问按项目费和字节费收费，如上面的等式所示。
读操作是最常见的操作，它只受瞬时资源稀缺的限制。因此，读取费用是根据磁盘 IOPS(项目费用) 和参考硬件规范的带宽容量进行校准的。
create 是在状态存储中添加一个新项。因此，create 增加了身份验证数据结构，使一切都变得更昂贵，因此成本最高。创建费用是根据网络拥有的参考磁盘空间进行校准的。因此，用项目 (item_fee) 和字节 (byte_fee) 填满磁盘需要大量的 GAS。
写操作更新状态存储中的现有项。因此，写操作不会在身份验证数据结构中产生额外的开销。然而，通过修改现有的条目到更大的字节，仍然可以破坏磁盘。因此，我们对更新项中的字节收取与创建时相同的费用。
应该注意的是，与存储相关的成本是基于每一笔交易进行评估的:即使您多次读取/写入相同的资源，也只需要支付一次费用。
基于上述考虑，我们定义了 6 个 GAS 参数，它们构成了 GAS 总费用的组成部分。见以下:
per_item_read:根据 IOPs 进行校正
per_byte_read:根据实际带宽校准
per_item_create:根据目标总项目进行校准
per_byte_create:根据目标总大小进行校准-每个项目包含的第一个 1KB
per_item_write:与 per_item_read 相同
per_byte_write:与 per_byte_create 相同
更多信息，请访问此处。
稳定的 GAS 单位成本
无论以 APT 或法定货币的市场价值计算执行操作的成本如何，每个操作和交易本身都需要相对于存储和执行成本的固定单位成本。固定的 gas 单位成本有助于保持 gas 计划不变，并与 APT 的自由市场价值脱钩。此外，正确选择 GAS 单位的精确位数有助于保持 GAS 计划不变。考虑到这一点，Aptos 团队以大约 3 位数的精度来表示 GAS 单位。因此，转账交易的成本大约是 700 个 gas 单位。
社区参与
即使我们对 GAS 计划投入了大量的精力，但是它还远远不够完善。作为一个社区项目，Aptos 社区成员可以选择:
1）根据你的经验，找出 GAS 计划不合理的地方；
2）说出你对 GAS 计划的担忧，并参与社区讨论。
3）就 Aptos 上与 GAS 相关的治理提案进行投票。
如何调整 GAS 成本？
GAS 计划作为链上配置被存储，但是可以通过 Aptos 治理提案进行更改，并且可以无缝添加新指令或原生功能。
GAS 计划被设计为可扩展的，允许通过治理提案对其进行升级。随着 Aptos 和 Aptos 社区不断改进 Move VM 并纳入用户反馈，GAS 参数可以随着时间的推移进行调整。
有时，GAS 公式可能需要超出链上配置的复杂更改。这些 GAS 公式通常用 Rust 编码，并通过链上 GAS 特征标志来区分。要升级这些公式，必须使用新公式更新节点软件，并以不同的 GAS 特征标志进行区分。然后必须发布节点软件并为节点运营商大量采用，最后，必须发布并批准治理提案才能使用新的 gas 版本。
未来的工作
这是 Move 的第一个可行的 GAS 框架。它需要对 Move VM 和 Aptos-Core 进行大量修改。我们希望这项工作为今后的工作铺平道路：
1）降低执行成本，拥有一个真实的 GAS 模型表明编译器和虚拟机在哪里有效率，团队可以改进其中的大部分以降低执行成本。
2）多维 GAS 计算，允许用户为执行和存储指定单独的预算。这样，用户就不必为因为代码编写不佳的应用程序花费过长的执行时间，支付高昂的 gas 价格。它还将允许对区块链端交易的最大 Gas 价格进行更细粒度的定义；
3）缓解臃肿状态，目前没有简单的方法来缩小状态集，除了合约（或用户）显式删除事物。用户付钱删除数据可能会带来套利机会，用户在便宜的时候创建存储，在昂贵的时候删除它。Aptos 推迟了解决这一挑战，这可能会削弱开发人员删除链上数据的动力。该团队正在探索每个项目 TTL 的概念，该概念将在 TTL 到期时删除未访问的状态项目。
