The First GAS Design of MOVE Language: How to Calculate On-Chain GAS Consumption

Recently, a certain blockchain project announced its GAS plan. As the first GAS design of the MOVE language, this is seen as an innovative attempt. The project team elaborated on the principles, processes, calculation methods, and future adjustment plans for establishing GAS, and expressed their welcome for community suggestions.

GAS measurement is a fundamental concept of many blockchains, used to measure the computational and storage resources required to execute and store on-chain transactions. The GAS schedule determines the cost of all executions on-chain, used to calculate the GAS consumption during transaction execution.

design process

The GAS design process of the project includes the following steps:

1. Define design principles
2. Prepare the evaluation framework and determine the price for each execution.
3. Establish a GAS measurement system and secure GAS algebra for MOVE
4. Import the upstream GAS framework into the project
5. Make the GAS framework storage-aware
6. Further refine the GAS plan

Design Principles

The project team has established the following design principles:

1. The operating costs should be directly related to the available resources of the network and decrease with technological improvements.
2. GAS should be set by on-chain governance and can be configured flexibly.
3. GAS can prevent DoS attacks and can be quickly adjusted.
4. The GAS price reflects the project's vision to promote growth and popularize blockchain.
5. Encourage making favorable choices in design, such as prioritizing security, modularity, etc.

GAS calculation method

When users submit a transaction, they need to specify two amounts:

• Maximum GAS Amount: The maximum number of GAS units that the user is willing to pay.
• GAS price: the price per unit of GAS, calculated in octal (1 octal = 0.00000001 tokens)

The following fees will be charged during the execution of the transaction:

1. Fixed Costs
2. Execution Cost (Executing MOVE Instructions)
3. Read Cost (reading data from storage)
4. Write Cost (Writing Data to Storage)

Final transaction fee = Total amount of GAS consumed × GAS unit price

For example, if a transaction consumes 670 GAS units and the user's specified GAS price is 100 Octa/unit, then the final fee is 670 × 100 = 67000 Octa = 0.00067 tokens.

If the transaction execution runs out of GAS, the sender will be charged the maximum GAS amount, and the changes made by the exchange will be revoked.

GAS Project Schedule Construction

1. Basic configuration: includes components unrelated to a single operation such as transaction size and maximum GAS units.

2. Transaction size: Initially set at 32KB, later adjusted to 64KB based on community feedback.

3. Maximum GAS Units: Defines the maximum amount of operations that can be executed in a single transaction, set to 1,000,000

4. Execution Costs: Assess the relative costs of MOVE instructions and native functions through benchmark frameworks and analytical tools.

5. Storage Costs: Consider the bandwidth of storage devices, IOPS capacity, and the cost of permanent disk usage.

Storage GAS fee = Project fee + ( byte fee × Number of bytes )

read, create, and write operations

• Read: The most common operation with the lowest fees.
• Create: Add a new item to the state storage, with a maximum fee.
• Write: Update existing items, byte fee same as creation

In each transaction, even if the same resource is read/written multiple times, only one fee is charged.

stable GAS unit cost

A fixed GAS unit cost helps maintain the stability of the GAS plan, decoupled from the market value of tokens. The project team represents the GAS units with approximately three-digit precision, such as the transfer transaction cost being about 700 GAS units.

Community Participation

The project encourages community members:

1. Point out the unreasonable aspects of the GAS plan.
2. Participate in community discussions and express opinions on the GAS plan.
3. Vote on GAS-related governance proposals

GAS cost adjustment

The GAS plan serves as on-chain configuration storage and can be modified through governance proposals. Complex updates to the GAS formula require updates to node software and widespread adoption, ultimately approved through governance proposals.

future work direction

1. Reduce execution costs: by improving the compiler and virtual machine.
2. Multi-dimensional GAS Calculation: Allows users to specify separate budgets for execution and storage.
3. Relieve state bloat: Explore the TTL concept for each project, deleting unvisited state items upon TTL expiration.

As the first GAS design for the MOVE language, this project lays the foundation for future work, looking forward to further optimizing the on-chain GAS mechanism through continuous improvement and community participation.