参考
宣布调治后的重量批改
案例模块：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
· 可以或许在不咨询链状态的环境下确定所利用的资源。在不需要昂贵的 I/O 的环境下，重量可以或许很好地暗示牢靠的丈量值或仅基于可调治函数的参数的丈量值。当本钱取决于链的状态时，重量就不那么有用了。
宣布调治后的重量批改答允任何可调治的在执行后返回其实际重量。此重量必需小于或便是调治前最坏环境的重量。要答允用户包括外部用户，他们仍然必需可以或许付出最大重量，纵然最终付款将基于实际重量。
链的可用资源是有限的。资源包罗内存利用、存储 I/O、计较、生意业务/块巨细和状态数据库巨细。有几种机制可以打点对资源的会见，并防备链中的各个组件耗损过多的资源。重量（Weights）是用于打点验证区块所需时间的机制。一般来说，这来自于限制存储 I/O 和计较。
关于这些限制的一个重要留意事项是，个中一部门是为 Operational 调治类保存的。此法则合用于这两个限制，比率可以在 AvailableBlockRatio中找到。
案例
除了影响用度之外，重量系统的主要目标是防备一个区块被执行时间过长的生意业务填满。在块内处理惩罚生意业务时，系统模块将块的总长度（以字节为单元的编码生意业务的总和）和块的总重量相加。假如这两个数字中的任何一个高出了限制，则该区块不接管进一步的生意业务。这些限制在 MaximumBlockLength 和 MaximumBlockWeight是有界说的。
相识更多
Substrate 菜谱中有包括自界说重量（https://github.com/substrate-developer-hub/recipes/tree/master/pallets/weights）和重量用度（https://github.com/substrate-developer-hub/recipes/tree/master/runtimes/weight-fee-runtime）的案例。
区块重量和长度限制
· 自己耗损的资源很少。耗损同样的资源去计较生意业务重量是没有意义的，当它会在执行中耗费掉。因此，重量计较应该比调治轻得多。
重量的成果
除了只利用常量举办预调治重量计较外，开拓人员还可以将给定可调治工具的输入参数思量在内。当执行时间取决于譬喻一个参数的长度时，这很是有用。重要的是，这些计较自己不需要任何有意义的事情。利用一些根基算法，可以从输入参数中轻松计较预调治的最大重量。
· 在调治前可计较。块生成器应该可以或许在实际抉择是否接管它之前查抄可调治的重量。
· 要求将有效重量（或可用于有效计较的前体）作为参数通报给调治。收取的重量应以这些参数为基本，但也包罗在调治期间验证这些参数所需的时间。必需举办验证，以确保重量参数与链上状态精确对应，假如不切合，则操纵大概堕落。
· 确定或引入一个强制上限，以确定可调治的大概遭受的重量。假如强制上限和可调治的最小大概重量之间的差别很小，则可以假定它始终处于重量上限，而无需咨询状态。然而，假如差别太大，那么举办较少生意业务的经济本钱大概太大，这将扭曲鼓励机制，造成吞吐量的低效率。
重量：https://github.com/paritytech/substrate/blob/master/frame/support/src/weights.rs
在某些环境下，可调治的实际重量不能从其输入中简朴地计较出来。譬喻，重量大概取决于可调治的逻辑路径。假如在调治后没有任何要领来校正重量，我们会不绝高估这些可调治的价值，然后再多收费，因为我们必需在调治前假设最坏的环境，以确保链条的安详。
譬喻，假如块长度限制为 1 兆字节，而且比率配置为 80%，则所有生意业务都可以填充块的前 800 千字节，而最后 200 千字节只能由操纵类填充。
重量因素
Substrate 将一个重量单元界说为在牢靠参考硬件（Intel Core i7-7700K CPU，64GB RAM 和 NVMe 固态硬盘）上执行时间的皮秒（微微秒）。参考硬件上的基准测试使重量在 runtime 之间具有可比性，，从而答允来自差异来历的软件组件的可组合性。为了针对差异的验证人硬件假设去调理 runtime，可以配置差异的最大块重量。譬喻，为了答允验证人参加，速度只有参考呆板的一半，最大块重量应该是默认值的一半，保持默认的块时间。
最大块重量应便是方针块时间的三分之一，分派三分之一用于块结构，三分之一用于网络流传，三分之一用于导入和验证。双倍块时间会双倍最大块重量。这些优化选项为 runtime 开拓人员提供了一种要领，使其可以或许在每秒生意业务数与硬件需求之间为其场景举办最佳衡量。这些衡量可以通过 runtime 更新举办调解，以跟上硬件和软件的改造。
有几个因素会影响执行时间，从而影响重量计较。一个很大的孝敬者是一个可调治执行的数据库会见数。由于数据库会见的本钱在很洪流平上取决于数据库后端和存储硬件，因此重量计较是参数化的，而不是数据库读写的重量本钱。这些本钱是通过在一些参考硬件上对每个可用的数据库后端举办基准测试来确定的。这答允在不变动所有重量计较的环境下切换数据库后端。
块可以包括的重量是有限的，可选的重量耗损（即不需要作为块的初始化或终结阶段的一部门陈设的重量，也不需要用于强制的固有外部重量）凡是通过经济法子来限制，可能简朴地说，通过生意业务用度来限制。重量系统的用度寄义包括在生意业务用度文档中（https://substrate.dev/docs/en/knowledgebase/runtime/fees）。
重量暗示必需验证区块的有限时间。这包罗计较周期和存储 I/O。自界说实现可以利用巨大布局来暗示这一点。Substrate 重量只是一个数值（https://crates.parity.io/frame_support/weights/type.Weight.html）。
尚有一个 Mandatory 调治类，可以用来确保外部始终包括在块中，而不管它对块重量的影响如何。请参阅生意业务用度文档（https://substrate.dev/docs/en/knowledgebase/runtime/fees）以相识有关差异调治类以及何时利用它们的更多信息。
留意：重量不是用于限制对其他资源的会见，譬喻存储自己或内存占用。有其他机制用于这个。
郑重声明：本文版权归原作者所有，转载文章仅为传播更多信息之目的，如作者信息标记有误，请第一时间联系我们修改或删除，多谢。
