Transaction Weights
链可用的资源是有限的。 These resources include memory usage, storage I/O, computation, transaction/block size and state database size. Substrate makes several mechanisms available to manage access to resources and to prevent individual components of the chain from consuming too much of any resource. 权重就是用于管理 验证区块花费的时间 的机制。 一般来说，这用来限制存储 I/O 和计算。
Note: Weights are not used to restrict access to other resources, such as storage itself or memory footprint. Other mechanisms must be used for this.
The amount of weight a block may contain is limited, and optional weight consumption (i.e. weight that is not required to be deployed as part of the block's initialization or finalization phases nor used in mandatory inherent extrinsics) will generally be limited through economic measures — or in simple terms, through transaction fees. The fee implications of the weight system are covered in the Transaction Fees document.
Substrate defines one unit of weight as one picosecond of execution time, that is 1012 weight = 1 second, or 1,000 weight = 1 nanosecond, on fixed reference hardware (Intel Core i7-7700K CPU with 64GB of RAM and an NVMe SSD).
Benchmarking on reference hardware makes weights comparable across runtimes, which allows composability of software components from different sources. In order to tune a runtime for different validator hardware assumptions, you can set a different maximum block weight. For example, in order to allow validators to participate that are only half as fast as the reference machine, the maximum block weight should be half of the default, keeping the default block time.
The maximum block weight should be equivalent to one-third of the target block time, allocating one third for block construction, one third for network propagation, and one third for import and verification. Doubling the block time would allow a doubling of the maximum block weight. These tuning options give runtime developers a way to make the optimal transaction per second vs. hardware requirement trade-offs for their use case. These trade-offs can be tuned with runtime updates to keep up with hardware and software improvements.
权重基础知识
Weights represent the limited time that your blockchain has to validate a block. This includes computational cycles, and storage I/O. A custom implementation may use complex structures to express this. Substrate weights are simply a numeric value.
A weight calculation should always:
- 在被调用之前可计算。 区块创建者在实际决定是否接受某个交易之前应该能够检查其权重。
- 本身消耗很少的资源。 如果计算交易的权重会消耗与执行交易消耗相似的资源，那这样就没有意义了。 因此，权重计算应该比执行交易更轻量级。
- 无需访问链上状态即可确定使用的资源。 权重擅长表示 固定 的测量或仅基于无昂贵 I/O 的可调用函数参数的测量 。 当交易成本依赖于链上状态时，权重就不是很有用了。
In the case that the weight of a dispatchable is heavily dependent on chain-state case, two options are available:
- 强制使用可调用函数可能消耗的权重上限。 如果可调用函数使用的强制权重上限与其下限差别只是很少，则可直接使用其权重上限而无需访问链上状态。 但是如果两者差别巨大，那么即使进行很少的交易，其经济成本也可能很大，这将破坏激励措施，并降低链上吞吐量。
- 要求有效权重（或可用于有效计算权重的参照值）作为参数传递到可调用函数中。 消耗的权量应基于这些参数，同时也应包含在调用时验证它们所花费的时间。 必须经过这一验证过程以确保权重参数准确对应于链上状态，如果对应不上，则相应操作应友好地报错。
权重因素
Several factors impact execution time, and therefore weight calculation. One large contributor is the number of database accesses that are performed by a dispatchable. Because the cost of a database access is greatly dependent on the database backend and storage hardware, the weight calculations are parameterized over the weight costs of database reads and writes. These costs are determined by benchmarking each available database backend on some reference hardware. This allows switching database backends without changing all weight calculations.
In addition to only using constants for the pre-dispatch weight calculation, the developer has the ability to factor in the input parameters of the given dispatchable. This can be useful when the execution time depends on, for example, the length of one parameter. It is important that these calculations do not entail any meaningful work themselves. The pre-dispatch maximum weight should be trivially computable from the input arguments with some basic arithmetic.
The System pallet 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 pallet 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.
调用后权重校正
There are cases where the actual weight of a dispatchable is not trivially computable from its inputs. For example, the weight could depend on the logic path of the dispatchable. Without any means of correcting the weight after dispatch, we would constantly overestimate and subsequently overcharge for those dispatchables as we must assume the worst case ahead of dispatch for the chain to be safe.
The post-dispatch weight correction allows any dispatchable to return its actual weight after it was executed. This weight must be less than or equal to the pre-dispatch worst case weight. For a user to be allowed to include an extrinsic, they still must be able to pay for the maximum weight, even though the final payment will be based on the actual weight.
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 transactions that would take too long to execute. While processing transactions within a block, the System pallet 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 MaximumBlockLength and MaximumBlockWeight.
One important note about these limits is that a portion of them are reserved for the Operational dispatch class. This rule applies to both of the limits and the ratio can be found in AvailableBlockRatio.
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.
There is also a Mandatory dispatch class that can be used to ensure an extrinsic is always included in a block regardless of its impact on block weight. Please refer to the article on Transaction Fees to learn more about the different dispatch classes and when to use them.