1. CoinON官网首页
  2. 新闻
  3. 头条

Aptos Gas 时间表制作

Bob鲍师傅 • • 头条 • 阅读 10613

Aptos Gas 时间表制作

Gas 计量是 Aptos 和许多其他区块链的基础概念——它定义了执行和存储交易所需的计算和存储资源量的抽象度量。这类似于用汽油开汽车或用天然气取暖。然后，gas 时间表将这些成本编码到所有操作中，并用于计算执行交易时使用的 gas 数量。

我们为 Aptos 制定 gas 时间表的努力是一次冒险！Move 没有为适当的 gas 时间表做好充分准备。它的最后一个化身实际上是打算在没有 gas 的情况下运行，因此只有一个微不足道的系统。

为了有效收费，我们在 Aptos 的流程是：

  • 确定我们的原则。

  • 准备一个评估框架，以确定每次操作的价格。

  • 为 Move 构建 gas 计量系统和安全 gas 代数。

  • 将上游 gas 框架导入 Aptos。

  • 使 gas 框具备存储意识。

  • 最后，细化、细化、再细化 gas 时间表。

原则

我们的定义原则是：

1. 操作的成本应该与网络上的可用资源（例如 CPU、内存、网络、存储 I/O 和空间使用量等）直接相关。此外，该成本应反映由于新技术和流程改进，导致的资源成本随时间变化的演变。

2. Gas 应该由链上治理设置并且可以无缝配置。

3. Gas 可以防止对网络中的一组固定资源的 DoS 攻击，并且可能需要根据网络情况通过治理建议进行快速调整。

4. Aptos gas 反映了 Aptos 基金会希望加速增长并保持区块链对每个人的开放。

5. 在设计中激发良好的选择——例如优先考虑安全性、模块化、断言和利用事件。

测量 gas

当用户提交交易时，他们还必须在交易中指定两个数量：

  • 最大 gas 数量：以 gas 单位测量。这是用户（即交易发送者）愿意为执行交易而花费的最大 gas 单位数。

  • gas 单价：以每 gas 单位的 octa 衡量，其中 1 octa = 0.00000001 APT (=$10^{-8}$)。这是用户愿意支付的 gas 价格。

在执行过程中，将收取交易费用：

  • 内在成本，有固定的基数加上大额交易的额外成本。

  • 执行成本，用于执行 Move 指令。

  • 读取成本，用于从持久存储中读取数据。

  • 写入成本，用于将数据写入持久存储。

最终交易费用可以通过将消耗的 gas 总量（以 gas 单位衡量）乘以气体单价来计算。例如，如果一笔交易消耗了 670 个 gas 单位，而用户在交易中指定的 gas 单位价格是 100 Octa/unit，那么最终的交易费用为 670 * 100 = 67000 Octa = 0.00067 APT。

如果交易在执行过程中耗尽了gas，那么发送者将根据最大 gas 量收费，并且该交易所做的所有更改都将被还原。

建立 gas 时间表

基本配置

gas 时间表有几个组成部分与与单个操作的细节无关。这些包括交易规模和最大 gas 单位（与用户在交易中指定的最大 gas 量不同）。

交易规模

对于大多数交易来说，交易规模可能在千字节量级。但是，Move 模块发布很容易达到几千字节，而 Aptos Framework 大约为 100 KB。此外，大多数用户模块往往在 4KB 和 40KB 之间。最初，我们将事务大小的值设置为 32KB，但社区反应迅速，并要求更多空间，以方便应用程序开发，因此将其调整为 64KB。

巨大的交易会导致整个网络的带宽成本，并对性能产生负面影响。如果被滥用，内存池会被激励忽略更大的交易，因此我们的方法是在最大交易规模和可访问性之间取得平衡。

最大 gas 单位

gas 时间表中的最大 gas 单位定义了一个交易可以执行多少次操作。注意，这与用户在交易中指定的最大 gas 量不同。

gas 时间表的最大 gas 单位对交易的执行时间有直接影响。将其设置得太高可能会导致交易对区块链产生负面的性能影响。例如，用户可能忘记在 while 循环中增加增量，从而导致无限循环，这是一个不幸的常见错误。我们发现，即使我们进行了最大的框架升级，我们仍然不到 gas 时间表的最大 gas 单位（设定为 1,000,000）的 90%。

执行情况

为了评估执行成本，我们构建了一个基准框架，并在执行该框架时使用 Valgrind 来分析 Move VM。它的输出是一组带注释的源代码，它告诉我们每行代码产生了多少机器指令。

在上述分析的帮助下，我们粗略估计了所有 Move 指令和本机函数的相对成本。

然而，我们注意到这个方法与内联函数存在一些问题：它们不会自动包含在调用者的计数中。我们还看到，这种情况只发生在我们对某些 Move 指令进行剖析的时候，我们可以通过将数字相加来解决这个问题。

随后，通过考虑增强系统稳健性和安全性的编码范例，团队得出了最终执行的机器指令数量。这个数字依次与存储和最大 gas 单位进行权衡，以确定它们在 gas 时间表中的当前值。

存储

每当访问存储在持久存储中的账本状态项或数据时，Aptos 节点都会向存储设备发出读取或写入的指令。每秒的数据访问总数取决于存储设备的带宽和 IOPS 容量。与 gas 时间表的计算部分的 CPU 周期类似，数据访问是区块链用户在系统负载时通过付费市场竞争的短暂稀缺性。此外，写入数据的磁盘占用成本在链上是永久的。Aptos 团队通过考虑这些成本来设计存储 gas 时间表。

访问和存储任何状态项都会产生与验证整个区块链状态的数据结构（水母默克尔树）相关的成本。此成本与不同状态项的基数有关（在$2^{256}$范围之外）。还有一个与每个项目的大小成正比的成本。要对一个状态项进行操作，费用为（下一节中描述的例外情况除外）：

存储 gas 费= item_fee + (byte_fee * bytes)

读取、创建和写入对一个状态项目的任何访问都属于这三类中的一类：读取、创建或写入。一个访问是由项目费和字节费来收费的，如上面的公式所示。

读取是最常见的操作，只受限于瞬时的资源稀缺性。因此，读取费用是根据参考硬件规格的磁盘 IOPS（项目费用）和带宽容量进行校准的。

创建会在状态存储中增加一个新的项目。因此，创建会扩展认证数据结构，使一切都变得更加昂贵，因此成本最高。创建费用是根据网络拥有的参考磁盘空间来校准的。因此，用项目（item_fee）和字节（byte_fee）来填充磁盘需要花费大量的 gas。

写入会更新状态存储中的现有项目。因此，写入不会在认证数据结构中产生额外的开销。但是，通过将现有项目修改为更大的字节大小，仍然可能会破坏磁盘。因此，我们对更新项目中的字节收费与创建时的字节相同。

应该注意的是，与存储相关的成本是按每笔交易评估的：即使你们多次读取/写入相同的资源，也只会被收取一次费用。

考虑到上述因素，我们定义了六个存储 gas 参数，它们构成了总存储 gas 费的组成部分。见下文：

  • per_item_read：由 IOP 校准

  • per_byte_read：由实际带宽校准

  • per_item_create：按目标总项目校准

  • per_byte_create：按目标总大小校准——每个项目中包含的前 1KB

  • per_item_write：与 per_item_read 相同

  • per_byte_write：与 per_byte_create 相同

更多细节，请参考：https://aptos.dev/concepts/base-gas/#storage-gas。

稳定的 gas 单位成本

无论以 APT 或法定货币的市场价值计算执行操作的成本，每个操作和交易本身都需要相对于存储和执行成本的固定单位成本。固定的 gas 单位成本有助于保持 gas 时间表不变，并与 APT 的自由市场价值脱钩。此外，正确选择 gas 单位的精确位数有助于保持 gas 时间表不变。考虑到这一点，该团队已经以大约 3 位数的精度来表示气体单位。因此，转移交易的成本大约是 700 个 gas 单位。

社区参与

尽管我们为开发该项目付出了大量的工作，但 gas 时间表也远非完美。作为一个社区项目，Aptos 社区成员们做到以下几点是至关重要的：

  • 根据你们的经验，找出 gas 时间表中的异常之处。

  • 参与社区讨论。

  • 参与 Aptos 上与 gas 相关的治理提案的投票。

如何调整 gas 费用

gas 时间表存储为链上配置。通过 Aptos 治理提案，可以更改 Gas 费用，并且可以无缝添加新指令或原生功能。

链上 gas 时间表被设计为可扩展的，允许通过治理提案对其进行升级。随着 Aptos 和 Aptos 社区不断改进 Move VM 并采纳用户反馈，gas 参数可以随着时间的推移进行调整。

有时，gas 公式可能需要超出链上配置的复杂更改。这些 gas 公式通常用 Rust 编码，并通过链上 gas 特征标志来区分。要升级这些公式，必须使用新公式更新节点软件，并以不同的 gas 特征标志进行区分。然后必须发布节点软件并为节点运营商大量采用。最后，必须发布并批准治理提案才能使用新的 gas 版本。

未来的工作

这是 Move 的第一个可行的 gas 框架。它需要对 Move VM 和 Aptos-Core 进行大量修改。我们希望这项工作为以下未来工作铺平道路：

  • 降低执行成本。拥有一个真实的 gas 模型表明编译器和虚拟机哪些方面具有效率。团队可以改进其中的大部分内容，以降低执行成本。例如，函数调用显示了改进的机会。

  • 多维 gas 计量。允许用户为执行和存储指定单独的预算。这样，用户就不必为执行时间过长的编程不佳的应用程序支付高昂的 gas 价格。它还将允许对区块链端交易的最大 gas 价格进行更细化的定义。

  • 缓解臃肿状态。目前，除了合同（或用户）明确地删除东西，没有简单的方法来缩小状态集。付钱给用户删除数据可能会带来套利机会，用户在便宜的时候创建存储，在昂贵的时候删除它。Aptos 已推迟解决这一挑战，这可能会削弱开发人员删除链上数据的积极性。该团队正在探索每个项目 TTL 的概念，将在 TTL 到期时删除未访问的状态项目。

致谢

特别感谢 Econia 实验室的 Alnoki 和 OtterSec 的 Robert Chen 提供的审查和反馈。

转载声明：本文 由CoinON抓取收录，观点仅代表作者本人，不代表CoinON资讯立场，CoinON不对所包含内容的准确性、可靠性或完整性提供任何明示或暗示的保证。若以此作为投资依据，请自行承担全部责任。

声明：图文来源于网络，如有侵权请联系删除

风险提示：投资有风险，入市需谨慎。本资讯不作为投资理财建议。

赞 (0)
打赏 微信扫一扫 微信扫一扫
Bob鲍师傅Bob鲍师傅
0
上一篇 2022年10月20日 下午10:31
下一篇 2022年10月20日 下午10:31

相关推荐

Aptos Gas 时间表制作

星期四 2022-10-20 22:31:52

Aptos Gas 时间表制作

Gas 计量是 Aptos 和许多其他区块链的基础概念——它定义了执行和存储交易所需的计算和存储资源量的抽象度量。这类似于用汽油开汽车或用天然气取暖。然后，gas 时间表将这些成本编码到所有操作中，并用于计算执行交易时使用的 gas 数量。

我们为 Aptos 制定 gas 时间表的努力是一次冒险！Move 没有为适当的 gas 时间表做好充分准备。它的最后一个化身实际上是打算在没有 gas 的情况下运行，因此只有一个微不足道的系统。

为了有效收费，我们在 Aptos 的流程是：

  • 确定我们的原则。

  • 准备一个评估框架，以确定每次操作的价格。

  • 为 Move 构建 gas 计量系统和安全 gas 代数。

  • 将上游 gas 框架导入 Aptos。

  • 使 gas 框具备存储意识。

  • 最后，细化、细化、再细化 gas 时间表。

原则

我们的定义原则是：

1. 操作的成本应该与网络上的可用资源（例如 CPU、内存、网络、存储 I/O 和空间使用量等）直接相关。此外，该成本应反映由于新技术和流程改进，导致的资源成本随时间变化的演变。

2. Gas 应该由链上治理设置并且可以无缝配置。

3. Gas 可以防止对网络中的一组固定资源的 DoS 攻击，并且可能需要根据网络情况通过治理建议进行快速调整。

4. Aptos gas 反映了 Aptos 基金会希望加速增长并保持区块链对每个人的开放。

5. 在设计中激发良好的选择——例如优先考虑安全性、模块化、断言和利用事件。

测量 gas

当用户提交交易时，他们还必须在交易中指定两个数量：

  • 最大 gas 数量：以 gas 单位测量。这是用户（即交易发送者）愿意为执行交易而花费的最大 gas 单位数。

  • gas 单价：以每 gas 单位的 octa 衡量，其中 1 octa = 0.00000001 APT (=$10^{-8}$)。这是用户愿意支付的 gas 价格。

在执行过程中，将收取交易费用：

  • 内在成本，有固定的基数加上大额交易的额外成本。

  • 执行成本，用于执行 Move 指令。

  • 读取成本，用于从持久存储中读取数据。

  • 写入成本，用于将数据写入持久存储。

最终交易费用可以通过将消耗的 gas 总量（以 gas 单位衡量）乘以气体单价来计算。例如，如果一笔交易消耗了 670 个 gas 单位，而用户在交易中指定的 gas 单位价格是 100 Octa/unit，那么最终的交易费用为 670 * 100 = 67000 Octa = 0.00067 APT。

如果交易在执行过程中耗尽了gas，那么发送者将根据最大 gas 量收费，并且该交易所做的所有更改都将被还原。

建立 gas 时间表

基本配置

gas 时间表有几个组成部分与与单个操作的细节无关。这些包括交易规模和最大 gas 单位（与用户在交易中指定的最大 gas 量不同）。

交易规模

对于大多数交易来说，交易规模可能在千字节量级。但是，Move 模块发布很容易达到几千字节，而 Aptos Framework 大约为 100 KB。此外，大多数用户模块往往在 4KB 和 40KB 之间。最初，我们将事务大小的值设置为 32KB，但社区反应迅速，并要求更多空间，以方便应用程序开发，因此将其调整为 64KB。

巨大的交易会导致整个网络的带宽成本，并对性能产生负面影响。如果被滥用，内存池会被激励忽略更大的交易，因此我们的方法是在最大交易规模和可访问性之间取得平衡。

最大 gas 单位

gas 时间表中的最大 gas 单位定义了一个交易可以执行多少次操作。注意，这与用户在交易中指定的最大 gas 量不同。

gas 时间表的最大 gas 单位对交易的执行时间有直接影响。将其设置得太高可能会导致交易对区块链产生负面的性能影响。例如，用户可能忘记在 while 循环中增加增量，从而导致无限循环，这是一个不幸的常见错误。我们发现，即使我们进行了最大的框架升级，我们仍然不到 gas 时间表的最大 gas 单位（设定为 1,000,000）的 90%。

执行情况

为了评估执行成本，我们构建了一个基准框架，并在执行该框架时使用 Valgrind 来分析 Move VM。它的输出是一组带注释的源代码，它告诉我们每行代码产生了多少机器指令。

在上述分析的帮助下，我们粗略估计了所有 Move 指令和本机函数的相对成本。

然而，我们注意到这个方法与内联函数存在一些问题：它们不会自动包含在调用者的计数中。我们还看到，这种情况只发生在我们对某些 Move 指令进行剖析的时候，我们可以通过将数字相加来解决这个问题。

随后，通过考虑增强系统稳健性和安全性的编码范例，团队得出了最终执行的机器指令数量。这个数字依次与存储和最大 gas 单位进行权衡，以确定它们在 gas 时间表中的当前值。

存储

每当访问存储在持久存储中的账本状态项或数据时，Aptos 节点都会向存储设备发出读取或写入的指令。每秒的数据访问总数取决于存储设备的带宽和 IOPS 容量。与 gas 时间表的计算部分的 CPU 周期类似，数据访问是区块链用户在系统负载时通过付费市场竞争的短暂稀缺性。此外，写入数据的磁盘占用成本在链上是永久的。Aptos 团队通过考虑这些成本来设计存储 gas 时间表。

访问和存储任何状态项都会产生与验证整个区块链状态的数据结构（水母默克尔树）相关的成本。此成本与不同状态项的基数有关（在$2^{256}$范围之外）。还有一个与每个项目的大小成正比的成本。要对一个状态项进行操作，费用为（下一节中描述的例外情况除外）：

存储 gas 费= item_fee + (byte_fee * bytes)

读取、创建和写入对一个状态项目的任何访问都属于这三类中的一类：读取、创建或写入。一个访问是由项目费和字节费来收费的，如上面的公式所示。

读取是最常见的操作，只受限于瞬时的资源稀缺性。因此，读取费用是根据参考硬件规格的磁盘 IOPS（项目费用）和带宽容量进行校准的。

创建会在状态存储中增加一个新的项目。因此，创建会扩展认证数据结构，使一切都变得更加昂贵，因此成本最高。创建费用是根据网络拥有的参考磁盘空间来校准的。因此，用项目（item_fee）和字节（byte_fee）来填充磁盘需要花费大量的 gas。

写入会更新状态存储中的现有项目。因此，写入不会在认证数据结构中产生额外的开销。但是，通过将现有项目修改为更大的字节大小，仍然可能会破坏磁盘。因此，我们对更新项目中的字节收费与创建时的字节相同。

应该注意的是，与存储相关的成本是按每笔交易评估的：即使你们多次读取/写入相同的资源，也只会被收取一次费用。

考虑到上述因素，我们定义了六个存储 gas 参数，它们构成了总存储 gas 费的组成部分。见下文：

  • per_item_read：由 IOP 校准

  • per_byte_read：由实际带宽校准

  • per_item_create：按目标总项目校准

  • per_byte_create：按目标总大小校准——每个项目中包含的前 1KB

  • per_item_write：与 per_item_read 相同

  • per_byte_write：与 per_byte_create 相同

更多细节，请参考：https://aptos.dev/concepts/base-gas/#storage-gas。

稳定的 gas 单位成本

无论以 APT 或法定货币的市场价值计算执行操作的成本，每个操作和交易本身都需要相对于存储和执行成本的固定单位成本。固定的 gas 单位成本有助于保持 gas 时间表不变，并与 APT 的自由市场价值脱钩。此外，正确选择 gas 单位的精确位数有助于保持 gas 时间表不变。考虑到这一点，该团队已经以大约 3 位数的精度来表示气体单位。因此，转移交易的成本大约是 700 个 gas 单位。

社区参与

尽管我们为开发该项目付出了大量的工作，但 gas 时间表也远非完美。作为一个社区项目，Aptos 社区成员们做到以下几点是至关重要的：

  • 根据你们的经验，找出 gas 时间表中的异常之处。

  • 参与社区讨论。

  • 参与 Aptos 上与 gas 相关的治理提案的投票。

如何调整 gas 费用

gas 时间表存储为链上配置。通过 Aptos 治理提案，可以更改 Gas 费用，并且可以无缝添加新指令或原生功能。

链上 gas 时间表被设计为可扩展的，允许通过治理提案对其进行升级。随着 Aptos 和 Aptos 社区不断改进 Move VM 并采纳用户反馈，gas 参数可以随着时间的推移进行调整。

有时，gas 公式可能需要超出链上配置的复杂更改。这些 gas 公式通常用 Rust 编码，并通过链上 gas 特征标志来区分。要升级这些公式，必须使用新公式更新节点软件，并以不同的 gas 特征标志进行区分。然后必须发布节点软件并为节点运营商大量采用。最后，必须发布并批准治理提案才能使用新的 gas 版本。

未来的工作

这是 Move 的第一个可行的 gas 框架。它需要对 Move VM 和 Aptos-Core 进行大量修改。我们希望这项工作为以下未来工作铺平道路：

  • 降低执行成本。拥有一个真实的 gas 模型表明编译器和虚拟机哪些方面具有效率。团队可以改进其中的大部分内容，以降低执行成本。例如，函数调用显示了改进的机会。

  • 多维 gas 计量。允许用户为执行和存储指定单独的预算。这样，用户就不必为执行时间过长的编程不佳的应用程序支付高昂的 gas 价格。它还将允许对区块链端交易的最大 gas 价格进行更细化的定义。

  • 缓解臃肿状态。目前，除了合同（或用户）明确地删除东西，没有简单的方法来缩小状态集。付钱给用户删除数据可能会带来套利机会，用户在便宜的时候创建存储，在昂贵的时候删除它。Aptos 已推迟解决这一挑战，这可能会削弱开发人员删除链上数据的积极性。该团队正在探索每个项目 TTL 的概念，将在 TTL 到期时删除未访问的状态项目。

致谢

特别感谢 Econia 实验室的 Alnoki 和 OtterSec 的 Robert Chen 提供的审查和反馈。

主页
快讯
精选
电报