Gas and Fees
Last updated
Last updated
Gas is essential to the Electroneum Smart Chain. It is the fuel that allows it to operate, in the same way that a car with an internal-combustion engine needs petrol or diesel to run.
To better understand this page, we recommend you first read up on transactions and the EVM.
Gas refers to the unit that measures the amount of computational effort required to execute specific operations on the Electroneum network.
Since each Electroneum transaction requires computational resources to execute, each transaction requires a fee. Gas refers to the fee required to execute a transaction on Electroneum, regardless of transaction success or failure.
Gas fees are paid in Electroneum's native cryptocurrency, ETN. Gas prices are denoted in gwei, which itself is a denomination of ETN - each gwei is equal to 0.000000001 ETN (10-9 ETN). For example, instead of saying that your gas costs 0.000000001 ETN, you can say your gas costs 1 gwei. The word 'gwei' itself means 'giga-wei', and it is equal to 1,000,000,000 wei. Wei itself (named after Wei Dai↗, creator of b-money↗) is the smallest unit of ETN.
Let's say Jordan has to pay Taylor 1 ETN. In the transaction, the gas limit is 21,000 units and the base fee is 10 gwei. Jordan includes a tip of 2 gwei.
The total fee would now be: units of gas used * (base fee + priority fee) where the base fee is a value set by the protocol and the priority fee is a value set by the user as a tip to the validator.
i.e 21,000 * (10 + 2) = 252,000 gwei or 0.000252 ETN.
When Jordan sends the money, 1.000252 ETN will be deducted from Jordan's account. Taylor will be credited 1.0000 ETN. Validator receives the tip of 0.000042 ETN. Base fee of 0.00021 ETN is burned.
Additionally, Jordan can also set a max fee (maxFeePerGas) for the transaction. The difference between the max fee and the actual fee is refunded to Jordan, i.e. refund = max fee - (base fee + priority fee). Jordan can set a maximum amount to pay for the transaction to execute and not worry about overpaying "beyond" the base fee when the transaction is executed.
Each block has a target size of 15 million gas, but the size of blocks will increase or decrease in accordance with network demand, up until the block limit of 30 million gas (2x the target block size). The protocol achieves an equilibrium block size of 15 million on average through the process of tâtonnement. This means if the block size is greater than the target block size, the protocol will increase the base fee for the following block. Similarly, the protocol will decrease the base fee if the block size is less than the target block size. The amount by which the base fee is adjusted is proportional to how far the current block size is from the target.
Every block has a base fee which acts as a reserve price. To be eligible for inclusion in a block the offered price per gas must at least equal the base fee. The base fee is calculated independently of the current block and is instead determined by the blocks before it - making transaction fees more predictable for users. When the block is validated this base fee is "burned", removing it from circulation.
The base fee is calculated by a formula that compares the size of the previous block (the amount of gas used for all the transactions) with the target size. The base fee will increase by a maximum of 12.5% per block if the target block size is exceeded. This exponential growth makes it economically non-viable for block size to remain high indefinitely.
1
15M
0%
100 gwei
2
30M
0%
100 gwei
3
30M
12.5%
112.5 gwei
4
30M
12.5%
126.6 gwei
5
30M
12.5%
142.4 gwei
6
30M
12.5%
160.2 gwei
7
30M
12.5%
180.2 gwei
8
30M
12.5%
202.7 gwei
This transaction-fee-mechanism causes fee prediction to be more reliable. Following the table above - to create a transaction on block number 9, a wallet will let the user know with certainty that the maximum base fee to be added to the next block is current base fee * 112.5% or 202.7 gwei * 112.5% = 228.1 gwei.
It's also important to note it is unlikely we will see extended spikes of full blocks because of the speed at which the base fee increases proceeding a full block.
30
30M
12.5%
2705.6 gwei
...
...
12.5%
...
50
30M
12.5%
28531.3 gwei
...
...
12.5%
...
100
30M
12.5%
10302608.6 gwei
With the base fee getting burned, priority fee (tip) incentivise validators to include a transaction in the block. Without tips, validators would find it economically viable to mine empty blocks, as they would receive the same block reward. Under normal conditions, a small tip gave miners a minimal incentive to include a transaction. For transactions that needed to get preferentially executed ahead of other transactions in the same block, a higher tip was necessary to attempt to outbid competing transactions.
To execute a transaction on the network, users can specify a maximum limit they are willing to pay for their transaction to be executed. This optional parameter is known as the maxFeePerGas. For a transaction to be executed, the max fee must exceed the sum of the base fee and the tip. The transaction sender is refunded the difference between the max fee and the sum of the base fee and tip.
Instead of explicitly stating how much you are willing to pay to get your transaction through, wallet providers will automatically set a recommended transaction fee (base fee + recommended priority fee) to reduce the amount of complexity burdened onto their users.
The implementation of EIP-1559↗ made the transaction fee mechanism more complex than the previous gas price auction, but it has the advantage of making gas fees more predictable, resulting in a more efficient transaction fee market. Users can submit transactions with a maxFeePerGas corresponding to how much they are willing to pay for the transaction to be executed, knowing that they will not pay more than the market price for gas (baseFeePerGas), and get any extra, minus their tip, refunded.
This video explains EIP-1559 and the benefits it brings:
If you are interested, you can read EIP-1559↗.
Continue down the rabbit hole with these EIP-1559 Resources↗.
The implementation of ETNIP-1 introduces Priority Transactions in the Electroneum Smart Chain. There is a smart contract deployed and owned and managed by Electroneum Ltd which contains a list of public keys that are associated with priority permissions.
Priority transactions are signed by priority entities with the private keys paired with those public keys.
The validators can recognise those priority signatures and prioritise transactions in blocks accordingly, regardless of the transaction fees that the transactions were sent with. Some priority transactors are allowed to completely bypass the fee system to send 0-gas fee transactions.
Only my.electroneum.com will be sending with priority at first. Third parties may/may not be afforded this permission in the future.
In short, gas fees help keep the Electroneum network secure. By requiring a fee for every computation executed on the network, we prevent bad actors from spamming the network. In order to avoid accidental or hostile infinite loops or other computational wastage in code, each transaction is required to set a limit to how many computational steps of code execution it can use. The fundamental unit of computation is "gas".
Although a transaction includes a limit, any gas not used in a transaction is returned to the user (i.e. max fee - (base fee + tip) is returned).
Gas limit refers to the maximum amount of gas you are willing to consume on a transaction. More complicated transactions involving smart contracts require more computational work, so they require a higher gas limit than a simple payment. A standard ETN transfer requires a gas limit of 21,000 units of gas.
For example, if you put a gas limit of 50,000 for a simple ETN transfer, the EVM would consume 21,000, and you would get back the remaining 29,000. However, if you specify too little gas, for example, a gas limit of 20,000 for a simple ETN transfer, the EVM will consume your 20,000 gas units attempting to fulfill the transaction, but it will not complete. The EVM then reverts any changes, but since the validator has already done 20k gas units worth of work, that gas is consumed.
