A number of resources in any chain can be limited, such as storage or computation. Weights exist to prevent individual components of the chain from consuming too much of any resource.
Consuming some weights should generally incur a fee. The fee implications of the weight system are covered in the Fee Developer document.
Weights represent the limited resources of your blockchain, for example computational cycles, memory, storage, etc. A custom implementation may use complex structures to express this. Substrate weights are simply a numeric value.
A weight calculation should always:
- Be computable ahead of dispatch. A block producer should be able to examine the weight of a dispatchable before actually deciding to accept it or not.
- Consume few resources itself. It does not make sense to consume similar resources computing a transaction's weight as would be spent to execute it. Thus, weight computation should be much lighter than dispatch.
- Delegate variable resource consumption costs and limitations to the dispatched logic. Weights are good at representing fixed measurements, whereas logic may not be consistently heavy. The implementation of the dispatch should take the state of the change into account and manually take extra fees or bonds or take any other measures to make sure that the transaction is safe.
The System module is responsible for accumulating the weight of each block as it gets executed and making sure that it does not exceed the limit. The Transaction Payment module is responsible for interpreting these weights and deducting fees based upon them. The weighing function is part of the runtime so it can be upgraded if needed.
Block Weight and Length Limit
Aside from affecting fees, the main purpose of the weight system is to prevent a block from being
filled with too many transactions. While processing transactions within a block, the System module
accumulates both the total length of the block (sum of encoded transactions in bytes) and the total
weight of the block. If either of these numbers surpass the limits, no further transactions are
accepted in that block. These limits are defined in
One important note about these limits is that a portion of them are reserved for the
dispatch class. This rule applies to both of the limits and the ratio can be found in
For example, if the block length limit is 1 megabyte and the ratio is set to 80%, all transactions can fill the first 800 kilobytes of the block while the last 200 can only be filled by the operational class.
- Substrate Recipes contains examples of both custom weights and custom WeightToFee.
- The srml-example module.
- See an example of adding a transaction weight to a custom runtime function.