类似于ETH每笔交易都需要手续费,CPUEOS主网上令开发者和用户都头疼的一项资源,更痛苦的是EOS的CPU经常爆了,转账无力....

今天小编将系统的谈谈如何解决CPU资源问题,内容比较专业,先看结论。

1. 用户不需要给自己的EOS账户质押CPU, 闲散的EOS都应该租出去,等需要时直接从自由市场租赁;
2. 未来,用户使用CPU的成本应该由dApp支付,dApp支付的市场前提是CPU已具备完善的定价机制,因此必须具备若干个大规模的CPU租赁服务平台;

3. 从资源利用的角度,EOS 应该缩短解除质押的3天赎回期。

下面的分析主要参考了 MEET.ONE 实验室早前发布的《EOSIO CPU 资源分配原理分析》,内容有难度,但如果你看懂了,不仅会感慨BM不可否认的天才性,也会对CPU资源形成更深的理解。毕竟行情不好的时候,多看看书,苦练内功。

你的1个EOS, 究竟可以分配到多少CPU?

我要抵押多少个EOS才够用?

最近都没有用过,怎么CPU就爆了呢?

我都抵押了100个EOS, 怎么没用几次就爆了?

这些都是新手用户最常问的问题,通常我们会告诉用户,你的CPU资源分配数是实时波动的,网络繁忙的时候CPU常常不够用,如果等恢复的话需要24小时,急的话可以从cpubaole.com付费租, 那么究竟CPU怎么分配的呢?

看公式1, 我如果抵押1个EOS,24小时所获得的CPU资源是实时变动的,因为全网总抵押的EOS数是实时变动的。

EOS 108讲 | 1. 解决CPU的终极出路-oheos.com

公式2则计算了24小时可分配CPU这个数值,它只受max_block_cpu_usage影响,只要这个数字短期内系统不调整,那么24小时可分配CPU这个数值就不会变动。

EOS 108讲 | 1. 解决CPU的终极出路-oheos.com

EOS Charge统计当前热门操作所需消耗的CPU

因此,如果主网总抵押了4.98亿EOS,则抵押1个EOS每天可获得69.40μs的CPU,而每进行一次EOS转账就需要约1008μs(据EOS Charge数据),也就是说质押100个EOS 只够转6笔账,如果真是这样,那么EOS真要凉凉,但好在天才的BM又为EOS设计了“空闲”和“拥堵”两种模式。

空闲模式下,CPU资源可放大1000倍

现实生活中,通过峰谷电、阶梯价等手段有效实现了电力资源的错时分配和供给。而BM也设计了类似的机制,即空闲模式下分配到的CPU比拥堵模式下扩大1000倍(考虑到抵押EOS的用户不是每时每刻用CPU,所以空闲时你可以“借用”别人的CPU),而在系统“拥堵”时,按照原先计算的质押比例去使用。

那他是怎么定义“拥堵”的呢?

当过去一分钟每个块的平均CPU使用量大于

max_block_cpu_usage * target_block_cpu_usage_pct

则进入“拥堵”模式。

前段时间,大家看到MEET.ONE快讯经常报道关于节点投票对target_block_cpu_usage_pct参数进行调整的新闻。现在就懂了,调整这个参数就是为了调高“拥堵”的临界值,使得“拥堵”状态更难触碰。从10%调到20%,再调到30%。 但是后来发现如果一旦调到 30% ,会出现丢块等问题,出现丢块的原因是多方面的,比如节点的配置跟不上,因此又把这个参数调到了 25%。

CPU分配的“涨跌停板”保护机制

既然拥堵和空闲模式下,分配到的可用CPU有1000倍的差距,那么EOS主网的CPU为什么没有出现剧烈的直上直下走势呢?

EOS 108讲 | 1. 解决CPU的终极出路-oheos.com

EOS Titan 统计过去1小时内每一个EOS可获得的CPU

答案是EOS系统设置了类似股票中的涨跌停板的保护机制。全网拥堵时,可用资源的变化缓慢生效,具体是:可用量每分钟乘以 0.99,如果 CPU 使用量一直没有降下来,直到触底需要大约 687 分钟 (log(0.001) / log(0.99)),从绝对拥堵完全恢复则更慢,是 log(1000) / log(1000/999) = 6904 分钟。

当然这个变化过程是可能随便改变方向的,类似多头和空头拉锯。比如使用量下降到阈值以下,可用量又会开始上升。

CPU为什么老是爆?

充分剖析了CPU的分配和运行机制,现在我们可以深度思考EOS的CPU老是爆的问题。

EOS的CPU鼓励错峰使用,忙的时候使用CPU等于下雨天打车,出价高的人可以打到车,但只要打车的人稍微多了就触发下雨,只要下雨,打车的人就更多了。

EOS 108讲 | 1. 解决CPU的终极出路-oheos.com

这似乎是一个死循环,该怎么解决呢?

普通用户不需要给自己抵押CPU,dApp应该为用户买单

其实,当大家在抱怨CPU总是爆了,EOS辣鸡的时候,完全可以从生活的角度考虑问题,CPU 本身是一种云计算资源,它和水、电等生活物资一样,但为什么在主网只有60多万用户的时候,我们就得面临CPU经常爆了的情况?或者说,普通用户压根就不应该去面对CPU爆了的问题。

如同我们在现实生活中,根本就不需要知道电厂如何发电,因为用户不需要同时承担生产电力和使用电力两个角色。往深处说,落后的小电力厂、落后的电力产能也会逐渐被市场淘汰掉,还有通过国家电力局统一的峰谷电定价等调控措施,最终实现了电力资源的有效分配,让普通用户用得起,用得够。

类比到CPU资源也是一样的。普通用户自己给自己抵押,就是产生了大量“游离”的、小规模的CPU, 这些CPU平时闲着不用,就是无效产能,非常浪费!合理的做法是什么?把EOS租给大平台,让大平台去集中调度,这样CPU要么以“经济实惠”的价格租给dApp开发者,要么在你需要的时候按需租赁。

目前CPU租赁规模比较大的有Chintai平台,MEET.ONE的付费租赁 cpubaole.com ,还有即将闪亮登场的 REX(Block.one 开发)等等,这些租赁平台生产“有效”的CPU,租赁价格渐渐趋于一致,构成完整的市场定价机制。

EOS应缩短原3天质押赎回期

前面的CPU分配公式中,小编一直在强调一个概念叫做24小时可获得的CPU和24小时可分配CPU,这个细节很重要。BM 在设计这个循环单位的时候,应该是经过慎重考虑的。

1. 质押一次EOS,获得的是24小时的CPU,为什么不是每秒、每分,也不是每月,每年?

如果是每分、每秒,每几个小时,按前面的公式,将导致质押同样的EOS,分配到的可用CPU更少了,更快进入爆了的状态,尽管此时等待CPU恢复的时间是短了,但对于用户而言其实更加不友好。因为一般我们倾向于一个时间段内集中使用EOS网络。如果是一个星期,一个月,一年,虽然你分配的CPU多了,用的时候一时爽,用完等半年....

EOS 108讲 | 1. 解决CPU的终极出路-oheos.com

小编的试验账户在今天下午2点和傍晚7点的CPU可用情况

因此,人以一天为一个作息单位,EOS也一样,充分考虑了用户习惯,一次性获得一天的CPU使用量,想用就用,用完恢复再等一天。

2. 由于用户获得的是24小时的CPU, 所以恢复时间也设置成24小时,从CPU的分配和恢复上讲,这个模型是比较合适的,但由于获得CPU的前提是质押EOS, 而一旦质押EOS,要解除EOS质押的状态却要等三天,这个时间我们认为是非常不合理的。理由如下:

a. 等待恢复状态的这部分EOS,不能继续抵押获得CPU,也不能交易,什么都不能做,这是一种资源浪费;

b. 由于解除质押将导致3天不能用,从行为心理上看,普通用户倾向于如果质押了就放着懒得动,而大户则通过质押获得安全性上的保障(质押时不能转账,账户被盗了有3天时间向ECAF求救)。事实上,站在资源利用的角度,如果你放着半天不用是合理的,但是十天八天半个月都不用,就是大大的浪费!过去EOS主网刚启动,为了达到1亿(10%)的激活启动花了不少时间,但是如今质押的雪球越滚越大,有近5亿EOS质押了。从前面的公式可以估算出,同样质押1个EOS,过去1个亿的时候,实际可以获得300μs的CPU, 现在只能获得60μs多。

EOS 108讲 | 1. 解决CPU的终极出路-oheos.com

EOS Flare 显示当前主网EOS质押情况

c. 不少操作过赎回的用户都知道,我今天赎回一个EOS,如果明天再赎回1个EOS,那么这两个EOS都要再等3天才能赎回,我们站在CPU租赁服务平台的角度去思考,如果质押赎回时间缩短的话,进入租赁市场的EOS将获得更好的流动性,有利于CPU使用单价下降,提高EOS主网的可用性。

这就是结论3:从资源利用的角度,EOS 应该缩短解除质押的3天赎回时间。

小编总结:

60万用户只是EOS的一个小小开始,从长远看,大规模CPU租赁市场的崛起是解决CPU资源分配的基础。只有解决了CPU经常爆的问题,让更多用户用得更舒服,更多的dApp才能发展起来,而繁荣的生态推动EOS价格的上涨,也将促使节点更主动地进行技术升级,整个生态才能实现正向的生长。

EOS 108讲 | 1. 解决CPU的终极出路-oheos.com