Let’s talk about transaction fee, also commonly known as gas fee.
Gas fee is a crucial component in most layer 1 blockchain protocols. In most blockchain protocols, there are two major types of participants: operators and users. Operators keeps track of what happens in the protocol: they keep track of users’ balances, execute transactions and make sure the records are consistent across different operators. Users make use of the protocol by submitting transactions, deploying smart contracts and sometimes store data in the blockchain protocol.
Gas fee lays the foundation of long term incentive for blockchain operators to devote their hardware and electricity in running the blockchain protocol. For blockchain users, gas fee is what they pay in exchange for the book keeping service provided by operators.
A well designed gas fee model is vital for the long term growth and sustainability for blockchain protocols. It should be designed to properly reflect the resource and effort that operators put into the blockchain, but also reasonable for blockchain users so it’s economically viable for them to run their use cases on the blockchain.
Breaking down the design of a blockchain’s gas fee model, there are 2 key aspects that calls for the protocol builder’s attention:
- How the gas fee is calculated
- How the gas fee is collected from the user(s)
Gas Fee Calculation
From a macro perspective, gas fee is collected to cover the cost for blockchain operators to process the transaction.
For single purposed blockchains like Bitcoin, who’s sole purpose is to process value transfers, the gas fee calculation is simple. In each of the Bitcoin transactions, there is a difference in the sum of inputs and the sum of outputs. The difference is credited to the operator, or miner, who processes this transaction. As long as the fee is able to cover the cost for the operator to process this transaction, the operator will happily include this transaction into the block it proposes.
However, for general purposed blockchains that support smart contract execution, operators do much more than simply verifying and recording transactions. They also have to execute smart contract functions, read data from the current blockchain state and write data to it after executing transactions. There are two major sources of cost for operators to execute users’ transactions: execution cost and storage cost.
The execution cost is easier. Each operation like addition, subtraction, logic evaluation, disk read… etc can be tagged a price. The more operation a transaction uses, the more gas fee it needs to pay. For example, the gas consumption of each OPCode in Ethereum can be found here.
The storage cost is more tricky. Once a piece of data is recorded to the blockchain, it will continuously cost all blockchain operators to keep this data, until it’s removed from the blockchain altogether. Many blockchains, including Ethereum, charge users a fee when they store data on chain, but lack the mechanism to continuously billing the user for keeping the data there. The continuous billing mechanism is called storage rent.
One of the reason that makes it difficult for Ethereum to adopt storage rent is that data storage and data ownership is decoupled. For example, all the data related to CryptoKitties is stored on the CryptoKitties smart contract, but the ownership of each kitten lies with each kitten holder. It’s nearly impossible to properly charge each kitten holder the storage rent for their on-chain kitten data.
However, with the resource model that Aptos and Flow uses and the account/object model that Solana and Sui adopts, storage rent is made possible and straightforward. Users will be asked to continuously pay fees if they wish to store the data on-chain. They can also lockup a chunk of coins and in effect pay the rent with the interest generated from the locked up coins. With storage rent in place, users will be incentified to clean up their accounts regularly and discard of the data that’s no longer needed.
Gas Fee Collection
Another key aspect of gas fee design is how it’s actually collected from the user(s).
The most straightforward way is to collect it from the user who initiates the transaction. However, this has disastrous impact on the user experience. This means that:
- New users cannot do anything with their accounts until they have some native coin in their account. This is against the average users freemium habits to “try first, pay later”
- Even if a user has NFTs or other coins like USDC in their accounts, they cannot transfer or use their assets unless they have some native coin in their accounts to pay the gas fees
To solve this issue on Ethereum, meta transaction was introduced in 2018. In a meta transaction, the transaction initiator or account owner does not necessarily have to hold native coin, ETH, in their accounts. They simply signs and approves of the transaction but a 3rd party relayer will be paying for the gas fee. Wallets like Blocto and Argent use the meta transaction mechanism to provide better user experience.
In Aptos and other newer blockchains like Flow and Solana, the transactions are more flexible and can have multiple senders/signers. Aptos comes with multi-agent transactions so multiple accounts can collaborate and send a single transaction that potentially makes use of the access of these multiple accounts. Only the first signer is in charge of paying the gas fee.
In a recent AIP, or Aptos Improvement Proposal, a new transaction scheme is proposed so there can be a separate “fee payer account” that pays for the fee of this transaction. With this in place, user experience can be further improved upon the current multi-agent transaction scheme.
