EOSIO 资源分配机制

本文为 MEET.ONE 发布的《EOSIO CPU 资源分配原理分析》 的个人版本，稣是其主要编辑之一。

1. 相关概念

您没看错，以下要介绍的几个概念，都是金融词汇。稣的柚子系列文章，又名《程序员转行做金融》，并兼职卖柚子……

• 存款准备金率

  Deposit-reserve Ratio。存款准备金是指金融机构为保证客户提取存款和资金清算需要而准备的，是缴存在中央银行的存款，中央银行要求的存款准备金占其存款总额的比例就是存款准备金率。

  经常能听到的“降准不降息，等于装牛逼”里面的“降准”全称就是“降低法定存款准备金率”。

  举个外星的例子：如果存款准备金率为 1‰，就意味着金融机构每吸收 1000 元存款，要向央行缴存 1 元的存款准备金，用于发放贷款的资金为 999 元。

• 挤兑

  Run on Banks。在银行券流通的条件下，银行券持有者争相到发行银行券的银行要求兑现贵金属货币的现象。当一家银行的信用发生动摇，准备金不足，银行券兑现发生困难，就会发生挤兑。挤兑可能使一家银行倒闭，甚至波及整个银行业。现在一般是指存款户集中地大量地到银行提取现钞。

• 涨跌停板制度

  这个不解释了……就问一句：连续 5 天跌停和一天暴跌 41%，您喜欢那种？如果您喜欢没有板的，再多问一句：一天暴跌 99.9% 您觉得怎么样？

• 峰谷电价

  又称“分时电价”，也很好理解。再举个类似的例子：下班高峰期打的，不加价基本打不到，因为别人加价优先接单。

2. 资源分配基本原则

EOS 账户可用资源与其抵押给资源的柚子数量的关系是：可用资源 = 总可用资源 * 本用户抵押数量 / 全体用户抵押数量。从这个关系上看，存在两个风险：

• 大户挤兑散民；
• 占着茅坑不拉屎。

第一个问题，用成本来解决，要通过加仓把别人的比例减少，按目前 3-4 亿的抵押量来说，需要付出的代价极高。

第二个问题，则通过引入一个放大因子来解决。之所以能放大是因为，某个时间点不拉屎的确实占大多数。只要把您拉屎的时间，除以一天的时间，就可以算出您一天拉屎的占用率。相信是很小的，笑……虽然您有柚子，就有拉屎的权利，但您自己不拉，让给需要拉的也是合理的，毕竟资源利用起来才是好事。

以 CPU 为例，计算公式为：

可用 CPU 微秒数 = max_block_cpu_usage * (account_cpu_usage_average_window_ms / block_interval_ms) * staked_cpu_count / total_staked_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。注意：这个数值是没有放大过的。

3. 堵车问题

EOS 定义了两种资源使用状态：拥堵、空闲，由过去一分钟每个块的平均使用量来界定。还是用 CPU 说事：大于 max_block_cpu_usage * target_block_cpu_usage_pct 则进入拥堵。

两个状态下的可用量本来应该有 1000 倍的差距，但因为有涨跌停板保护，并不会直上直下。每一分钟，只能跌到 99/100，只能涨到 1000/999。所以从拥堵开始到绝对拥堵，有 log(0.001) / log(0.99) = 687 分钟之长；从绝对拥堵完全恢复更慢，是 log(1000) / log(1000/999) = 6904 分钟。目前的 target_block_cpu_usage_pct 已经从 10% 调整到 20%，它提高了总使用量临界值，使拥堵状态更难触碰。

可用量的变化过程是可能随时改变方向的，类似多头和空头拉锯。比如拥堵时，可用量变少，能够使用资源的用户也随之减少，使用量降到阈值以下，可用量又会开始慢慢上升。

4. 阈值的设定

max_block_cpu_usage 和 target_block_cpu_usage_pct 都是可以配置的，为什么不一次性配高点呢？主要考虑的因素是，目前各个 BP 的机器性能参差不齐，如果冒然的把这两个值调高，可能会导致节点 replay 变慢，同时对于配置低的机器来说，同步区块也会很吃力。别忘了，我们的准备金率才 1‰，属于严重超发，提高可用率，虽然会使拥堵来得晚点，但真到拥堵的那刻，爆发的能量可是更大的哦！

总之，还是稳一点好，慢慢涨经验。目前来看昨天的调整，对节点之间的同步、CPU 使用率没有太大影响。

5. 参考

EOSIO 代码

EOS资源模型