链的可用资源是有限的。资源包括内存使用、存储 I/O、计算、交易/块大小和状态数据库大小。有几种机制可以管理对资源的访问，并防止链中的各个组件消耗过多的资源。重量（Weights）是用于管理验证区块所需时间的机制。一般来说，这来自于限制存储 I/O 和计算。
注意：重量不是用于限制对其他资源的访问，例如存储本身或内存占用。有其他机制用于这个。
块可以包含的重量是有限的，可选的重量消耗（即不需要作为块的初始化或终结阶段的一部分部署的重量，也不需要用于强制的固有外部重量）通常通过经济措施来限制，或者简单地说，通过交易费用来限制。重量系统的费用含义包含在交易费用文档中（https://substrate.dev/docs/en/knowledgebase/runtime/fees）。
Substrate 将一个重量单位定义为在固定参考硬件（Intel Core i7-7700K CPU，64GB RAM 和 NVMe 固态硬盘）上执行时间的皮秒（微微秒）。参考硬件上的基准测试使重量在 runtime 之间具有可比性，从而允许来自不同来源的软件组件的可组合性。为了针对不同的验证人硬件假设去调节 runtime，可以设置不同的最大块重量。例如，为了允许验证人参与，速度只有参考机器的一半，最大块重量应该是默认值的一半，保持默认的块时间。
最大块重量应等于目标块时间的三分之一，分配三分之一用于块构造，三分之一用于网络传播，三分之一用于导入和验证。双倍块时间会双倍最大块重量。这些优化选项为 runtime 开发人员提供了一种方法，使其能够在每秒交易数与硬件需求之间为其场景进行最佳权衡。这些权衡可以通过 runtime 更新进行调整，以跟上硬件和软件的改进。
Handshake团队已修复可使HNS代币出现通胀的漏洞:金色财经报道，去中心化域名服务器（DNS）项目Handshake背后的团队最近修补了一个漏洞，该漏洞可能会使其代币HNS的供应出现通货膨胀。[2021/4/3 19:42:25]
重量表示区块链必须验证区块的有限时间。这包括计算周期和存储 I/O。自定义实现可以使用复杂结构来表示这一点。Substrate 重量只是一个数值（https://crates.parity.io/frame_support/weights/type.Weight.html）。
重量的计算应始终：
在调度前可计算。块生成器应该能够在实际决定是否接受它之前检查可调度的重量。
本身消耗的资源很少。消耗同样的资源去计算交易重量是没有意义的，当它会在执行中花费掉。因此，重量计算应该比调度轻得多。
能够在不咨询链状态的情况下确定所使用的资源。在不需要昂贵的 I/O 的情况下，重量能够很好地表示固定的测量值或仅基于可调度函数的参数的测量值。当成本取决于链的状态时，重量就不那么有用了。
在可调度的重量严重依赖于链状态的情况下，有两个选项可用：
确定或引入一个强制上限，以确定可调度的可能承受的重量。如果强制上限和可调度的最小可能重量之间的差异很小，则可以假定它始终处于重量上限，而无需咨询状态。然而，如果差异太大，那么进行较少交易的经济成本可能太大，这将扭曲激励机制，造成吞吐量的低效率。
日本央行发布央行数字货币报告，计划明年初进行第一期概念实验:日本央行在东京发布央行数字货币报告。日本央行表示，对数字货币的需求可能会迅速上升。日本央行称，为数字货币形势的变化做好准备。如果现金流通量下降，可能会发行央行数字货币进行支付。仍然致力于提供现金。将对央行数字货币进行实践实验。即使现金流通量没有下降，从提高支付结算系统的稳定性和效率的角度来看，日本央行发行数字货币也是合适的。希望确保央行数字货币能够用于跨境支付，而不仅仅是国内支付。即使日本央行要发行通用央行数字货币，也应保持两级体系，通过中介机构间接发行数字货币。计划在2021年初进行第一期概念实验。（金十）[2020/10/9]
要求将有效重量（或可用于有效计算的前体）作为参数传递给调度。收取的重量应以这些参数为基础，但也包括在调度期间验证这些参数所需的时间。必须进行验证，以确保重量参数与链上状态准确对应，如果不符合，则操作可能出错。
有几个因素会影响执行时间，从而影响重量计算。一个很大的贡献者是一个可调度执行的数据库访问数。由于数据库访问的成本在很大程度上取决于数据库后端和存储硬件，因此重量计算是参数化的，而不是数据库读写的重量成本。这些成本是通过在一些参考硬件上对每个可用的数据库后端进行基准测试来确定的。这允许在不更改所有重量计算的情况下切换数据库后端。
除了只使用常量进行预调度重量计算外，开发人员还可以将给定可调度对象的输入参数考虑在内。当执行时间取决于例如一个参数的长度时，这非常有用。重要的是，这些计算本身不需要任何有意义的工作。使用一些基本算法，可以从输入参数中轻松计算预调度的最大重量。
系统模块（System pallet ）负责在执行时累积每个块的重量，并确保其不超过限制。交易支付模块（Transaction Payment pallet）负责解释这些重量并根据这些重量扣除费用。重量功能是 runtime 的一部分，因此可以根据需要进行升级。
在某些情况下，可调度的实际重量不能从其输入中简单地计算出来。例如，重量可能取决于可调度的逻辑路径。如果在调度后没有任何方法来校正重量，我们会不断高估这些可调度的价格，然后再多收费，因为我们必须在调度前假设最坏的情况，以确保链条的安全。
发布调度后的重量修正允许任何可调度的在执行后返回其实际重量。此重量必须小于或等于调度前最坏情况的重量。要允许用户包含外部用户，他们仍然必须能够支付最大重量，即使最终付款将基于实际重量。
除了影响费用之外，重量系统的主要目的是防止一个区块被执行时间过长的交易填满。在块内处理交易时，系统模块将块的总长度（以字节为单位的编码交易的总和）和块的总重量相加。如果这两个数字中的任何一个超过了限制，则该区块不接受进一步的交易。这些限制在 MaximumBlockLength 和 MaximumBlockWeight是有定义的。
关于这些限制的一个重要注意事项是，其中一部分是为 Operational 调度类保留的。此规则适用于这两个限制，比率可以在 AvailableBlockRatio中找到。
例如，如果块长度限制为 1 兆字节，并且比率设置为 80%，则所有交易都可以填充块的前 800 千字节，而最后 200 千字节只能由操作类填充。
还有一个 Mandatory 调度类，可以用来确保外部始终包含在块中，而不管它对块重量的影响如何。请参阅交易费用文档（https://substrate.dev/docs/en/knowledgebase/runtime/fees）以了解有关不同调度类以及何时使用它们的更多信息。
下一步
了解更多
Substrate 菜谱中有包含自定义重量和重量费用的案例。
案例模块：https://github.com/paritytech/substrate/blob/master/frame/example/src/lib.rs
查看给自定义 runtime 函数添加一个交易重量的例子。https://substrate.dev/recipes/3-entrees/weights.html
交易支付模块：https://github.com/paritytech/substrate/blob/master/frame/transaction-payment/src/lib.rs
重量：https://github.com/paritytech/substrate/blob/master/frame/support/src/weights.rs
原文：https://substrate.dev/docs/en/knowledgebase/learn-substrate/weight
翻译：PolkaWorld 社区
郑重声明： 本文版权归原作者所有， 转载文章仅为传播更多信息之目的， 如作者信息标记有误， 请第一时间联系我们修改或删除， 多谢。