We have successfully implemented an improved fee algorithm on the Aergo Mainnet. The previous algorithm was a simpler method in which additional fees were charged based on the payload size and the state usage size to the base of 0.002 AERGO as transaction fees. However, it is not a fair measurement since variables such as computational time or memory size were not being factored in. The new algorithm takes into account the CPU and memory usage used by the contract. This is a significant update to the Aergo Mainnet.

For this purpose, a gas system was introduced. In order to measure computation time for each transaction, the Bytecode instruction and the amount of gas consumed per built-in function is allocated.

The memory used by the VM and the update size of the state are also measured in gas. The total amount of gas measured is a numerical value corresponding to the calculation, not a fee. To calculate the fee, we use the concept of a gas price. Gas price is the AER value corresponding to 1 Gas.

This is a simple breakdown of the units involved comparing it to ETH (note that price is insignificant in this example, it’s for demonstration of the units and similarities)

1 ETH = 1 AERGO
1 GWEI = 1 GAER
1 WEI = 1 AER

Key Notes

• All transactions in a block have the same gas price and is not determined by the user.
• The gas price is also not a fixed value and it can be changed by DAO.
• By adjusting the gas price, the contract ecosystem can be stabilized against rapid changes in AERGO’s market value. This is the reason for using gas price without converting gas directly to fee.

Gas Limit

The gas limit allows the user to specify the maximum amount of gas to be used for transactions and contracts. To this end, the new version of the tool and client library supports the Gas limit parameter. For compatibility with the previous version that did not specify a gas limit, the gas limit 0 is automatically used as the maximum gas limit you can specify. The contract will not continue to perform enough calculations to exhaust all of your balance, but user needs to be cautious about this.

Even if the user knows the Bytecode instruction and the gas amount of the basic function (the gas table will be provided in the Fee section of the 2.0 document), it is not easy to estimate the exact gas limit. Although the execution path of a contract can be understood in the Bytecode instructions, it is ultimately impossible for the user to predict the amount of memory used by the VM for the call stack and objects used by the VM. The best way to estimate the gas limit used by the contract is by actually using it.

The simplest way to simulate is to use brick. You can use brick to deploy and perform contracts without running the blockchain. In addition, you can check the results, gas usage, etc. It also has functions for debugging the contract.

Delegated Fee

As Fee 2.0 is set in place, it will be more expensive to execute the contract. Since the contract fee can be a burden on the dapp user, a new transaction type has been added in order to activate dapp. The provider pays the fee by subtracting from the contract the fee used to execute the contract.

If all users send this transaction type, the provider will be burdened as well. Thus, a function is specified to check the available users so that the user can set limits by defining the function in the contract according to the intention of the provider.

We hope that this paints a better picture of what Fee 2.0 is, how it works, the gas limits, and delegated fee.