Several resources in a blockchain network are limited, for example, storage and computation. Transaction fees prevent individual users from consuming too many resources. Setheum uses a weight-based fee model as opposed to a gas-metering model. As such, fees are charged prior to transaction execution; once the fee is paid, nodes will execute the transaction.
Web3 Foundation Research designed the Polkadot fee system which Setheum also uses as its fee system with the following objectives:
Each block should be processed efficiently to avoid delays in block production.
The growth rate of the Chain should be bounded.
Each block should have space for special, high-priority transactions like misconduct reports.
The system should be able to handle spikes in demand.
Fees should change slowly so that senders can accurately predict the fee for a given transaction.
Fees on the Setheum Blockchain are calculated based on three parameters:
A per-byte fee (also known as the "length fee")
A weight fee
A tip (optional)
The length fee is the product of a constant per-byte fee and the size of the transaction in bytes.
Weights are a fixed number designed to manage the time it takes to validate a block. Each transaction has a base weight that accounts for the overhead of inclusion (e.g. signature verification) as well as a dispatch weight that accounts for the time to execute the transaction. The total weight is multiplied by a per-weight fee to calculate the transaction's weight fee.
Tips are an optional transaction fee that users can add to give a transaction higher priority.
Together, these three fees constitute the inclusion fee. This fee is deducted from the sender's account prior to transaction execution. A portion of the fee will go to the block producer and the remainder will go to the Treasury. At Setheum's genesis, this is set to 20% and 80%, respectively.
Blocks in Setheum have both a maximum length (in bytes) and a maximum weight. Block producers will fill blocks with transactions up to these limits. A portion of each block - currently 25% - is reserved for critical transactions that are related to the chain's operation. Block producers will only fill up to 75% of a block with normal transactions. Some examples of operational transactions:
Member operations in an election (e.g. renouncing candidacy)
Block producers prioritize transactions based on each transaction's total fee. Since a portion of the fee will go to the block producer, producers will include the transactions with the highest fees to maximize their reward.
Transaction volume on blockchains is highly irregular, and therefore transaction fees need a mechanism to adjust. However, users should be able to predict transaction fees.
Setheum uses a slow-adjusting fee mechanism with tips to balance these two considerations. In addition to block limits, Setheum also has a block fullness target. Fees increase or decrease for the next block based on the fullness of the current block relative to the target. The per-weight fee can change up to 30% in a 24 hour period. This rate captures long-term trends in demand, but not short-term spikes. To consider short term spikes, Setheum uses tips on top of the length and weight fees. Users can optionally add a tip to the fee to give the transaction a higher priority.
When a block author constructs a block, it must limit the block's execution time. A block body consists of a series of extrinsics. Since the resources needed to execute an extrinsic can vary, Substrate provides a flexible mechanism called "weights" to characterize the time it takes to execute an extrinsic. To be economically sustainable and to limit spam, some transactions --- primarily those dispatched by users --- require a fee prior to transaction execution.
Although an extrinsic's weight is only one component of the fee charged to its sender, it is recommended to understand the weight system before reading this document.
Transaction weight must be computable prior to execution, and therefore can only represent fixed logic. Some transactions warrant limiting resources with other strategies. For example:
Bonds: Some transactions, like voting, may require a bond that will be returned or slashed after an on-chain event. In the voting example, returned at the end of the election or slashed if the voter tried anything malicious.
Deposits: Some transactions, like setting an identity or claiming an index, use storage space indefinitely. These require a deposit that will be returned if the user decides to free storage (e.g. clear their ide).
Burns: A transaction may burn funds internally based on its logic. For example, a transaction may burn funds from the sender if it creates new storage entries, thus increasing the state size.
Limits: Some limits are part of the protocol. For example, nominators can only nominate 16 validators. This limits the complexity of Phragmén.
This page only covered transactions that come from normal users. If you look at blocks in a block explorer, though, you may see some "extrinsics" that look different from these transactions. In Setheum (and any chain built on Substrate i.e. Polkadot), an extrinsic is a piece of information that comes from outside the chain. Extrinsics fall into three categories:
This page only covered signed transactions, which is the way that most users will interact with Setheum. Signed transactions come from an account that has funds, and therefore Setheum can charge a transaction fee as a way to prevent spam.
Unsigned transactions are for special cases where a user needs to submit an extrinsic from a key pair that does not control funds. For actions in the form of "heartbeat" messages to indicate that they are online. The example, when users claim their DNAR tokens after genesis, their DNAR address doesn't have any funds yet, so that uses an unsigned transaction. Validators also submit unsigned trans heartbeats must be signed by one of the validator's session keys. Session keys never control funds. Unsigned transactions are only used in special cases because, since Setheum cannot charge a fee for them, each one needs its own, custom validation logic.
Finally, inherents are pieces of information that are not signed or included in the transaction queue. As such, only the block author can add inherents to a block. Inherents are assumed to be "true" simply because a sufficiently large number of validators have agreed on them being reasonable. For example, Setheum blocks include a timestamp inherent. There is no way to prove that a timestamp is true the way one proves the desire to send funds with a signature. Rather, validators accept or reject the block based on how reasonable they find the timestamp. In Setheum, it must be within some acceptable range of their own system clocks.