作者: MEET.ONE 实验室 支持我们，请投票给 rex.m
众所周知，EOS 账户可以使用的 CPU 运算资源与账户抵押的 CPU 有关，抵押的越多，可以使用的资源就越多。质押的 EOS 对应的 CPU 资源计算公式为:
可用 CPU 微秒数 = max_block_cpu_usage * (account_cpu_usage_average_window_ms / block_interval_ms) * your_staked_cpu_count / total_cpu_count
其中 max_block_cpu_usage 是可配置的，当前主网配置为默认值 default_max_block_cpu_usage = 200000
所以 max_block_cpu_usage * (account_cpu_usage_average_window_ms / block_interval_ms) = 34560000000
以主网 2018-10-19 为例，当前 CPU 总质押量为 280053493.80756617 EOS，那么可以算出每个 EOS 可以使用 123.40 us，也就是说质押 1000 个 EOS，才可以使用 123.40 ms的计算资源。
这样会带来一个问题就是质押量少的账户无法发起任何操作，不能转账，不能质押等等。
如同现实生活中的水、电和流量，忙时和闲时是分开定价的，使用价格手段鼓励用户错峰用电。EOS也允许用户在系统闲时使用更多的资源，在系统忙时保证能使用对应权重的资源，解决了以太坊拥堵时低gas交易无法打包的问题。
同样的钱，在闲时可以买到很多的水电，同理，抵押同样的代币，在系统闲时可使用更多的资源。 这里就引出 EOS 使用资源的基本原则：使用一分，记录一分。
为了实现动态调节的机理，EOS 引入了虚拟资源这一概念，最大可使用的虚拟资源为实际可使用的资源的1000倍，也就是说，用户在系统闲时可用的最大资源为实际可用的1000倍。
现实生活中的水、电的忙闲是通过时段区分的，比如白天是忙时，半夜是闲时。EOS则需要通过监测60s内的区块资源的使用情况来区分，现阶段是60s内的区块资源使用低于最大可用的10%，就（小比例）增加系统可用的虚拟资源，否则就（小比例）减少。
因此 EOS 设计了两种 CPU 模式：拥堵模式、空闲模式。
-
空闲模式下，可用 CPU 资源会放大 1000 倍。按前面的公式计算，再乘以 1000，实际 1 EOS = 123.40 ms。了解过金融的同学，可以把这个 1000 理解为市盈率。
-
拥堵模式下，可用 CPU 为实际数值，1 EOS = 123.40 us。
之前有个账户叫 blocktwitter 不知道大家有没有印象，为什么可以一直往主网发送垃圾消息，就是因为空闲模式下，他可以使用自己质押量 1000 倍的 CPU 资源。当这个账户被 BP 加入灰名单以后，相当于进入了拥堵模式，只能使用实际抵押的资源。
主网账户拥堵模式的触发条件有以下两种：
- 个别账户拥堵模式：个别 EOS 账户被节点加入灰名单。可用资源的变化立刻生效。
- 全网拥堵模式：过去 60 秒平均每个块的 CPU 使用量达到 max_block_cpu_usage * target_block_cpu_usage_pct。全网拥堵时，可用资源的变化缓慢生效，具体是：可用量每分钟乘以 0.99，如果 CPU 使用量一直没有降下来，直到触底需要大约 687 分钟 (log(0.001) / log(0.99))，每个质押 EOS 的 CPU 可用量回到实际质押的换算值。之前这个阈值是 200000us * 10% = 20ms，昨天调整以后为 200000us * 20% = 40ms。
当然这个变化过程是可能随便改变方向的，类似多头和空头拉锯。比如使用量下降到阈值以下，可用量又会开始上升。
下图是过去一周，主网每个 EOS 对应的 CPU 使用量变化图，每一分钟都在变化。
有同学问为什么不直接把 max_block_cpu_usage 跟 target_block_cpu_usage_pct 的值调到最大呢，这样可以最大范围的减少主网进入拥堵模式的次数。
昨天我们在 BP 群里有讨论过这个问题，主要考虑的因素是，目前各个 BP 的机器性能参差不齐，如果贸然的把这两个值调高，可能会导致节点 replay 变的更慢，同时对于配置低的机器来说，同步区块也会很吃力。总之大家还是决定稳一点慢慢来，目前来看昨天的调整，对节点之间的同步，CPU 使用率没有太大影响。不出意外的话下次会把 target_block_cpu_usage_pct 调到 30%。