The First GAS Design of MOVE Language: Exploring On-Chain GAS Fee Calculation Methods

The previous version of the MOVE language was originally planned to run in a no-GAS environment, so it was not prepared for GAS design. Recently, a blockchain project team launched the first GAS design solution for its on-chain project based on the MOVE language, which is referred to as a "risky" attempt.

In this GAS plan, the team clarified the principles, processes, calculation methods, and later adjustment mechanisms for developing GAS, and expressed a welcome for community suggestions.

GAS measurement is a fundamental concept of this project and many other blockchains, which defines the abstract calculation of the amount of computational and storage resources required to execute and store on-chain transactions. The GAS scheme determines the cost of all executions on-chain, used to calculate the GAS fees incurred during the execution of transactions.

process

In order to execute effectively, the on-chain process of the project is:

1. Definition 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

principle

The defined principles include:

1. The operational costs should be directly related to the available resources of the network and decrease with technological advancements.
2. GAS should be set by on-chain governance and can be configured flexibly.
3. GAS can prevent DoS attacks and can quickly adjust according to network conditions.
4. The GAS price reflects the vision of the project foundation to promote growth and maintain the accessibility of the blockchain.
5. Encourage making excellent choices in design, such as focusing on security, modularity, etc.

Calculate GAS

Users need to specify two quantities when submitting a transaction:

• Maximum GAS Amount: The maximum number of GAS units that a user is willing to pay for executing a transaction.
• GAS price: calculated in octal per unit of GAS, 1 octal = 0.00000001 native token

During execution, the transaction will be charged:

1. Fixed Costs
2. Execution Cost
3. Read Cost
4. Write Cost

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

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

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

Establish GAS schedule

1. Basic Configuration

The GAS plan includes several components that are not related to a single operation, such as transaction size and maximum GAS units.

2. Transaction Scale

Most transaction sizes are at the kilobyte level, but the MOVE module can reach several kilobytes, with the project framework around 100 KB. The initial transaction size was set at 32KB, later adjusted to 64KB based on community needs to simplify application development.

3. Maximum GAS unit

The maximum GAS unit defined in the GAS plan specifies the maximum number of operations that can be executed in a single transaction. Setting it too high may have a negative impact on blockchain performance. It is currently set at 1,000,000, which has not exceeded 90% even with the maximum framework upgrades.

4. Execute

Evaluate execution costs using a benchmark framework and analytical tools, estimating the relative costs of all MOVE instructions and native functions. Considering system robustness and security, derive the final number of machine instructions executed and weigh them against storage and maximum GAS units.

5. Storage

The storage GAS plan takes into account the instantaneous scarcity of data access and the permanent disk occupation costs. Accessing and storing state items incurs costs related to verifying the entire blockchain state. Storage GAS fee = project fee + ( byte fee × number of bytes )

Read, Create and Write

State item access is divided into three types: read, create, and write, each with different cost calculation methods. Read operations are the most common, create operations have the highest cost, and write operations fall in between the two.

Based on these considerations, six GAS parameters were defined:

• per_item_read
• per_byte_read
• per_item_create
• per_byte_create
• per_item_write
• per_byte_write

stable GAS unit cost

Each operation and transaction itself requires a fixed unit cost relative to storage and execution costs, which helps maintain a stable GAS schedule. The project team represents GAS units with an accuracy of about three digits, making the cost of transfer transactions approximately 700 GAS units.

Community Participation

As a community project, members can:

1. Point out the unreasonable aspects of the GAS plan.
2. Express concerns about the GAS plan and participate in discussions.
3. Vote on governance proposals related to GAS.

How to adjust GAS costs?

The GAS plan serves as on-chain configuration storage, which can be modified through governance proposals and allows for the seamless addition of new instructions or native features. The GAS parameters can be adjusted over time to accommodate the development of the project and the community.

Some complex GAS formula changes may require updating node software and distinguishing through new GAS feature flags. This requires node operators to widely adopt the new software and approve the use of the new version through governance proposals.

Future Work

As the first viable GAS framework of the MOVE language, this project paves the way for future work:

1. Reduce execution costs
2. Implement multi-dimensional GAS calculation, allowing users to specify separate budgets for execution and storage.
3. Alleviate the bloated state, explore the TTL concept for each project, and delete unvisited state projects upon TTL expiration.

This GAS is designed to provide an important foundation for the development of the MOVE language ecosystem, and there is still much room for optimization and improvement in the future.