揭开EOS资源的面纱(一)CPU设计背后的经济原理

EOS原力
EOS原力 得得号

Nov 13, 2019 去中心化的高性能智能合约平台。

摘要: EOS是一款以“降低开发者成本,让用户交易免费”为目标的公有链。

揭开EOS资源的面纱(一)CPU设计背后的经济原理
00:00
08:43

EOS是一款以“降低开发者成本,让用户交易免费”为目标的公有链。也就是说用户在交易中,不需要收取交易费。为了做到这一点EOS设计了CPU、NET和RAM三种资源。用户在拥有这三个资源之后才能免费交易。但是绝大多数用户来说分不清这些资源是什么。尤其在近期EIDOS活动中,很多用户的CPU质押不足,导致无法转账。这究竟是为什么呢?本文将详细讲解EOS中的CPU究竟是什么?以及CPU资源设计背后经济原理。

什么是CPU资源?

我们在EOSIO上每一次交易时,我们的这笔交易数据会被超级节点(BP)们执行和检查,超级节点在执行这项工作时需要花费计算时间。我们把这个所需要计算的时间的资源称之为CPU。所以CPU是指节点在处理、验证交易时必须花费的执行时间,EOS中CPU以微秒(μs)为单位。因为每个节点使用时间是有限的。为了合理使用每个超级节点的计算时间。EOS设置了一套CPU资源的使用模型。

资源如何分配?

我们知道了,CPU是节点在处理、验证交易时必须花费的执行时间。在EOSIO中, 用户为了使用CPU资源可以使用EOS抵押来获取CPU, (第一次注册的账户将自动购买一定比例的CPU资源,这也是为什么EOS账户注册需要收费的原因)。这个抵押过程相当于用户买了超级节点的一部分运算时间,那么 EOS中CPU资源是如何分配的呢?这里我会把背后的原理进行详细论述,想看结论的直接跳至最后一章。

为了方便大家理解我们这里来做个类比,我们把EOS交易类比成火车运货。

首先,我们想一想,这列火车是否可以免费运货呢, 如果这样就可能有用户不停的发送大量的垃圾到B地, 这样其他人就用不了这列火车了, 不能免费就要收费, 既然收费, 就要有个定价的方式。

假设从A地到B地有一列火车, 每10分钟一班列车, 每个列车上能装10吨货物, 用户使用列车从A地到B地发送货物(我们先忽略装车和卸车的时间和列车的空间)。

首先最简单的定价方式,就是确定每吨货物需要多少钱, 如果定每吨100元钱, 那么一个用户如果需要运3吨货物到B地, 那就需要支付300元运费。 这么做有什么不足之处吗?有的。如果如果当前需要运输货物的需求很少, 那么货运火车就会空跑, 此时火车的运力就浪费掉了, 不如减价吸引更多的用户发货. 其次如果当前需要运货的用户很多而发生了拥堵, 那此时着急发货的用户也会想要多支付一部分运费来使得自己的货物可以更加快速的发到B地。

这种方法其实就是类似于以太坊的手续费模型, 在以太坊中每笔交易需要支付手续费, 用户可以自行确定自己的费率, 此时矿工就可以根据费率来选择打包那些用户的交易。

EOSIO是如何设计的?

在EOSIO中, 用户为了使用CPU资源可以使用EOS抵押来获取CPU。类比一下就是火车的管理者印发了一些“运费券”。

假设每张运费券可以运送10千克的货物, 用户要想发货那么就要得到一些“运费券”,用户把“运费券”给火车的列车员, 这样列车员就会有很多“运费券”,当然列车员为了支付火车的成本, 会把“运费券”卖给用户, 完成循环.。 但是考虑到火车的运力将会随着技术的发展而不断增强, 这也就意味着按理说“运费券”的总量应该不断增多, 而价格应该不断下降, 否则用户就没法享受到技术发展而带来的好处。 另外, 如果“运费券”的价格因为某些原因增长的很多, 类比EOSIO就是如果EOS的价格增长了(这显然是很多人所希望的), 如果此时每张“运费券”所等运送货物的重量没有增长, 那就会反过来导致原来的用户支付不起运费, 这显然是不合理的, 因为列车员得到了更多的收益, 此时他就会升级自己的火车来运送更多的货物, 但是如果是固定的“运费券”, 那就会导致运力上涨了但是用户却用不起火车, 另一方面, 有些时候“运费券”的价格会下降, 那么会导致火车的总运力下降, 此时会出现“运费券”无法使用的情况。

EOSIO采取的是基于使用权的资源模型, 从上面的叙述中可以得出“运费券”所对应的重量应该是浮动的, 这个值即和当前的需求总量相关, 也应该和供给总量相关。

为何会CPU不足?

这时就有一个问题: 如果Alice一次要运5吨货物怎么办, 如果简单的要求Alice抵押更多的“运费券”,那么如果Alice要抵押的“运费券”就会十分多, 多到大多数用户没法承受, 另外考虑到大多数时间火车都不是满载的, 让Alice多放些货物也无所谓。 顺着这个思路, 火车的管理者提供了一个“折扣率”的东西, 如果现在是1折, 那就意味着Alice可以运10吨的货物, 如果当前火车比较空, 那么“折扣率”就可以很优惠, 如果火车运的东西很多, 那么“折扣率”就不能太优惠, 最终如果火车一直很满, 那就不应该打折, 所有用户只能按照自己的实际份额运货。

EOSIO中有一个叫做virtual_cpu_limit的数值, 这个数值就是这个“折扣率”, 当然EOSIO中这里是以用户CPU资源的倍率来表示的, 恶意使用优惠的账户会被列入“灰名单”中, 这时这个账户是无法享受到“折扣”的。

总结

所以,综上所述,我们知道CPU是指节点在处理、验证交易时必须花费的执行时间,而CPU的资源是采取的是基于使用权的资源分配方式,使用比例根据总抵押比例进行调整。简单的说,如果整个EOS网上有1000个代币被抵押在CPU上,而我的账户抵押了20个,那么我保证会拥有CPU总容量的2%的使用权。同时,平时我们使用的CPU在空闲状态下都是通过折扣率享受的优惠状态,而在EIDOS这次的情况下,CPU突然使用暴增,随之而来的折扣率也低了。所以在同样的CPU抵押下能够使用的计算资源变低。从而导致CPU资源不足。

这解释了为什么BM在EIDOS事件上的那句话:抱怨当前主网的CPU紧缺状态是没必要的,这就跟抱怨Uber用车高峰期打不到车/车费溢价的道理一样。不要抱怨市场通过提高价格来平衡供求,要关注实际总供给。

(作者:EOS原力,内容来自链得得内容开放平台“得得号”;本文仅代表作者观点,不代表链得得官方立场)

链得得仅提供相关信息展示,不构成任何投资建议
本文系作者 EOS原力 授权链得得发表,并经链得得编辑,转载请注明出处、作者和本文链接

更多精彩内容,关注链得得微信号(ID:ChainDD),或者下载链得得App

分享到:

相关推荐

    评论(0

    Oh! no

    您是否确认要删除该条评论吗?

    分享到微信