EOS 社区里有成员问到：“为什么当前 TPS 并不高，CPU 的价格怎么会遇到居高不下的情况？”
image
今天上午 CPU 资源的提案通过，主网全局参数 TARGET_BLOCK_CPU_USAGE_PCT 从 10% 提升到 20%，至少提升了 2 倍的可用 CPU 资源。但需要明白这只是临时的解决方案，而要更长远的思考 EOS 资源模型，需进行更多的工作来增强 EOS 的易用性。
image
EOS 可用的 CPU 资源量如何计算？
我们先看一下，单个 EOS 能兑换多少 CPU 资源是怎么计算的？
单个 EOS 所能够得到的资源量 = 总的资源量 / 抵押的 EOS 总量(现在是五亿多个)
类似于电价的忙闲时收费不同的设计，为了进行动态调节，EOS 上引入了虚拟资源这一概念，最大的虚拟资源量为实际资源量的1000倍。当忙的时候，就会逐步减少系统可用的虚拟资源量。
image
拥堵指标
在 EOS 上，衡量“拥堵”的程度，会计算过去一分钟内的区块资源使用量与最大可用量的比值，比如说，过去一分钟内，总共用了20%的量；然后拿这个量跟一个固定的参照数值比较。
如果使用的比值< 拥堵指标，那么，就增加虚拟资源总量，意味着现在是闲时，可以分配更多的资源给用户使用；
而如果使用的比值> 目标参考值(即拥堵指标，10%), 就减少虚拟资源总量，意味着现在是忙时，需要收缩一下资源量，留给真正的需求。
忙时的价格，cpu 的价格会越高，就像现在这样，因为： 单个 EOS 所能够得到的资源量 = 总的虚拟资源量 / 抵押的 EOS 总量(现在是五亿多个)
当忙的时候，总的虚拟资源量会降低降低降低(重要事情说三遍)，所以，导致单个 EOS 所能够换取的 CPU 的量降低了很多。
image
解决方式
暂时的解决方式： 调整上面所提到的10%这个参考值。现在的计划是调整到：20%。通过这种方式，让分配到虚拟资源总量更多一些，这样 CPU 的价格便会降低。
这也就是今天麒麟测试网络上所测试的全局参数的调整。经过了在麒麟测试网络上的多轮调整，EOSRIO向EOS主网正式发起了一个提案，将target_block_cpu_usage_pct这一参数(即上文所说的参考值)从当前的1000（10％）更改为2000（20％）。
image
现状
image
现在，判断区块拥堵的指标是，平均每个区块的实际使用时间是0.04s(200ms * 20%)。
另外一个解决方向，是将每个区块的最大可用时间从现在的0.2s(200ms)提升到一个更高的数值, 增加 CPU 的资源总量。
不过，正如开头所提到的那样，通过参数的调整来增加资源供应量的方式，是临时的解决方式，仍然需要社区和 Block.one 一起探讨，提供更好的优化方案。
注：内容来源于 EOS42
End
image
网友评论