Partnered With:

Aptos Announces Gas Plan: How to Calculate the Cost?

Read this article in 18 Minutes

Aptos Labs showed its principles and procedures for formulating GAS, how to calculate GAS, adjustment of GAS fees in the later period, and actively accepted suggestions from the Aptos community

Original title: "The first GAS design of MOVE language: How to calculate the GAS cost on the Aptos chain?" "

Original author: Aptos Labs

Original compilation: Aptos Global

Aptos Labs announced the GAS plan of Aptos on October 14, because the previous version of the MOVE language was actually intended to run without GAS, So it is not ready for the GAS plan, so the GAS plan established by Aptos labs for Aptos this time is the first GAS design of the MOVE language, which is officially called "an adventure".

In the GAS plan of Aptos, Aptos Labs has indicated its own principles and procedures for formulating GAS, how to calculate GAS, adjustment of GAS fees in the later period, and actively accepting opinions from the Aptos community suggestion.

GAS metering is a fundamental concept of Aptos and many other blockchains, it defines execution and The abstract calculation of the amount of computing and storage resources required by the trading platform on the storage chain. The GAS plan determines the cost consumed by all executions on the chain, which is used to calculate the GAS cost used during the execution of the transaction.

Process

For effective execution, we in Aptos The on-chain process is:

1) Define our principles;

2) Prepare An evaluation framework to determine the price of each execution;

3) Establish a gas metering system and safe gas algebra for Move;

< br>

4) Import the upstream GAS framework into Aptos;

5) Make the GAS framework storage aware;

6) Finally, further refine the GAS plan.

Principles

Our defined principles are:

1. The cost of an operation should be directly related to the resources available on the network (such as CPU, memory, network, storage I/O and space usage, etc.). In addition, when the technology and process are improved, the cost of GAS should be reduced accordingly.

2. Gas should be set by on-chain governance and can be configured seamlessly.

3. Gas can prevent DoS attacks on a fixed set of resources in the network, and may need to be quickly adjusted through governance recommendations according to network conditions.

4. Aptos' GAS price reflects the Aptos Foundation's desire to accelerate growth and keep blockchain accessible to everyone.

5. Encourage good choices in design - such as prioritizing security, modularity, assertions, etc.

Calculate GAS

When a user submits a transaction, they Two amounts must also be specified in the transaction:

Max gas amount: Measured in GAS units. This is the maximum number of gas units a user (i.e., a transaction sender) is willing to spend to execute a transaction.

Gas unit price: Calculated in octal per unit of GAS, where 1 octal=0.00000001 APT(=$10^{-8} $). This is the gas price that users are willing to pay.

During execution, the transaction will be charged:

1) Fixed cost, fixed Base plus additional fees for large transactions.

2) Execution cost, used to execute the Move instruction.

3) Read cost for reading data from persistent storage.

4) Write cost for writing data to persistent storage.

The final transaction fee can be calculated by multiplying the total amount of GAS consumed (calculated in GAS units) by the unit price of GAS. For example, if a transaction consumes 670 GAS units, and the user specifies a gas unit price of 100 Octa per unit in the transaction, then the final transaction fee will be 670 * 100 = 67000 Octa = 0.00067 APT.

If a transaction runs out of gas during execution, the sender will be charged according to the maximum gas amount, and the transaction platform does All changes will be reverted.

Create a GAS schedule

1. Basic configuration

There are several components of the GAS plan that are not related to the details of individual operations, including transaction size and maximum gas units (different from the maximum gas specified by the user in the transaction quantity).

2. Transaction size

For most transactions, the transaction size may be in the kilobytes order of magnitude. However, a Move module release can easily be several kilobytes, while the Aptos framework is around 100 KB. Most user modules are typically between 4KB and 40KB in size. Initially, we set the transaction size value to 32KB, but based on community responses asking for more space to ease application development, we adjusted the transaction size to 64KB.

Very large transactions incur higher bandwidth costs across the network and can negatively impact performance. If abused, mempools are encouraged to ignore larger transactions, so our approach is to strike a balance between the size of the largest transaction and accessibility.

3. Maximum GAS unit

The maximum GAS unit in the GAS plan defines a The maximum number of operations a transaction can perform. Notice! This is different from the maximum gas amount specified by the user in the transaction.

The maximum GAS unit of the GAS plan directly affects how long a transaction can be executed, setting it too high may cause a negative performance impact on the blockchain trade. For example, a user may forget to have an increment in a while loop, resulting in an infinite loop, which is a common mistake. We found that even with our biggest framework upgrades, we're still less than 90% of the gas plan's max gas units (set at 1,000,000).

4. Execution

In order to evaluate the execution cost, we constructed a The baseline framework and is used when executing that framework.

Valgrind to analyze Move VM. Its output is a set of annotated source code that tells us how many machine instructions each line of code produced.

With the help of the above analysis, we roughly estimated the relative cost of all Move instructions and native functions. However, we noticed that this approach has some issues with inline functions: they are not automatically included in the caller's count. We also saw that this only happens when we analyze certain Move instructions, and we can fix this by adding the numbers together.

The team then derived the final number of executed machine instructions by considering coding paradigms that enhance system robustness and safety. This number is in turn weighed against storage and max gas units to determine their current value in the gas plan.

5. Storage

Whenever access is stored in persistent storage Aptos nodes will send reads or writes to the storage device whenever the ledger status items or data are generated. The total number of data accesses per second depends on the bandwidth and IOPS capacity of the storage device. Similar to CPU cycles for gas scheduling the computational part, data access is an instantaneous scarcity that blockchain users compete for through the fee market while the system is under load, and additionally, the disk footprint cost of writing data is permanent on-chain. The Aptos team designs storage GAS plans by considering these costs.

Accessing and storing any state item will generate and verify the data structure of the entire blockchain state

< p>jellyfish Merkle tree related costs:

This cost is related to the cardinality of the different state items ($2^{ 256}$). There is also a cost proportional to the size of each item. To operate on a state item, the fee is (with exceptions described in the next section):

Storage gas fee = item_fee + (byte_fee * bytes)

read, create and write

< /p>

Any access to a state item is of one of three types: read, create, or write. Access is charged by item fee and byte fee, as shown in the above equation.

Read operations are the most common operations, limited only by instantaneous resource scarcity. Therefore, read charges are calibrated against disk IOPS (item charge) and bandwidth capacity of the reference hardware specification.

create adds a new item to the state store. So create adds to the authentication data structure, making everything more expensive, and thus the most expensive. Creation fees are calibrated against the reference disk space owned by the network. So filling up the disk with items (item_fee) and bytes (byte_fee) takes a lot of gas.

A write operation updates an existing entry in the state store. Therefore, write operations do not incur additional overhead in the authentication data structure. However, it is still possible to corrupt the disk by modifying existing entries to a larger size. Therefore, we charge the bytes in the update item the same as they were in the creation.

It should be noted that storage-related costs are assessed on a per-transaction basis: even if you read/write to the same resource multiple times, You only need to pay once, too.

Based on the above considerations, we have defined 6 GAS parameters, which form part of the total GAS fee. See below:

per_item_read: Correct according to IOPs

per_byte_read: Calibrate according to the actual bandwidth

per_item_create: Calibrate according to the target total item

per_byte_create: Calibration based on target total size - first 1KB per item contains

per_item_write: same as per_item_read

per_byte_write: Same as per_byte_create

For more information, please visit here.

Stable GAS unit cost

Whether APT or The market value of fiat currencies calculates how expensive it is to perform an operation, and each operation and transaction itself requires a fixed unit cost relative to storage and execution costs. A fixed unit cost of gas helps keep the gas schedule constant and decoupled from APT's free market value. In addition, the correct choice of the precise number of GAS units helps to keep the GAS plan intact. With this in mind, the Aptos team represents GAS units with approximately 3 digits of precision. Therefore, the cost of a transfer transaction is approximately 700 gas units.

Community Engagement

Even though we invested in the GAS program A lot of work, but it's far from perfect. As a community project, Aptos community members can choose to:

1) Based on your experience, find out where the GAS plan is unreasonable;

2) Voice your concerns about the GAS program and participate in community discussions.

3) Vote on GAS-related governance proposals on Aptos.

How do I adjust the GAS cost?

The GAS plan is stored as an on-chain configuration, but can be changed through Aptos governance proposals and new instructions or Native functions.

The GAS program is designed to be scalable, allowing it to be upgraded through governance proposals. GAS parameters can be adjusted over time as Aptos and the Aptos community continue to improve the Move VM and incorporate user feedback.

Occasionally, the GAS formula may require complex changes beyond the on-chain configuration. These GAS formulas are usually encoded in Rust and are distinguished by on-chain GAS signatures. To upgrade these formulas, the node software must be updated with the new formula, differentiated by a different GAS signature. Node software must then be released and gain mass adoption for node operators, and finally, governance proposals must be published and approved to use the new gas version.

Future work

This is Move's first a viable GAS framework. It requires extensive modifications to Move VM and Aptos-Core. We hope this work paves the way for future work to:

1) reduce implementation costs, having a realistic GAS model show Where compilers and virtual machines are efficient, the team can improve most of them to reduce execution costs.

2) Multidimensional GAS calculation, allows users to specify separate budgets for execution and storage. This way, users don't have to pay high gas prices for poorly written applications that take too long to execute. It will also allow for a more fine-grained definition of the maximum gas price for blockchain-side transactions;

< p>

3) Alleviate state bloat, There is currently no easy way to shrink the state set, other than contracts (or users) explicitly removing things. Arbitrage opportunities can arise from users paying to delete data, with users creating storage when it is cheap and deleting it when it is expensive. Aptos has delayed solving this challenge, which may reduce the incentive for developers to delete data on-chain. The team is exploring the concept of a per-item TTL, which would remove unvisited state items when the TTL expires.