cleos system claimrewards Error 3050003 “quantity exceeds available supply”
在测试网中，获取出块奖励时，报错
surou@bcskillsurou:~$ cleos -u http://127.0.0.1:8000 system claimrewards bcskillsurou -p bcskillsurou
Error 3050003: eosio_assert_message assertion failure
Error Details:
assertion failure with message: quantity exceeds available supply
pending console output:查询supply
surou@bcskillsurou:~$ cleos -u http://127.0.0.1:8000 get currency stats eosio.token EOS
{
"EOS": {
"supply": "10000000000.0000 EOS",
"max_supply": "10000000000.0000 EOS",
"issuer": "eosio"
}
}发现supply已经不小于max_supply。
由于bp每次claimrewards时，根据距离上次claim的时间差先增发，然后再从奖池里面拿。所以每次claimrewards时，supply都会增加相应的值，但必须小于max_supply。
继续跟进
创建代币
cleos -u http://127.0.0.1:8000 push action eosio.token create '["eosio","10000000000.0000 EOS",0,0,0]' -p eosio.token
发布代币
cleos -u http://127.0.0.1:8000 push action eosio.token issue '["eosio","10000000000.0000 EOS","issue"]' -p eosio.token发现是当时启动测试网时，issue发行了最大的值，一般应小余最大值10倍，及创建100亿代币的最大值，只发行10亿，之间的差额用于增发。
参考：https://github.com/EOSIO/eos/issues/4325
"Dapp"你们走的太快了,请等等你们的"EOS"
80天80亿流水， EOS DApp生态大爆发，CPU价格水涨船高，这是一个很正常的市场行为，需求大了，价格自然上涨。但是如果你仔细看看数据就会发现，目前EOS TPS平均只有50，理论上CPU肯定是空闲的。既然是空闲的，CPU没有涨价的理由啊。所以这里就存在一个问题，要么是CPU价格虚高，要么就是目前系统配置下，EOS TPS极限就是50左右。
为了一探究竟，就必须先分析分析CPU价格的计算机制。
CPU资源价格计算机制
CPU的价格是指1个EOS可以使用多长时间的CPU，所以CPU价格自然受两个指标影响：一个是CPU资源总量，一个是CPU需求量。
由于EOS投票必须抵押，因而系统中抵押的EOS有很多只是用来投票而不是用来使用CPU的，自然没法判断当前CPU的真实需求量，自然没法计算出CPU的价格。于是EOS提出了虚拟CPU资源的概念，CPU的价格=虚拟CPU资源总量/系统总的EOS抵押量。这个虚拟CPU资源总量是动态调整的，是根据过去1分钟CPU真实使用量动态调整的，当CPU真实使用量大于某个阈值(目前是CPU总量的20%)时，认为CPU处于繁忙了，会调低虚拟CPU总量即提高CPU价格以降低需求量，如果CPU使用量还是没下来(交易量还是没减少)，虚拟CPU总量会继续降低，直到很多用户因为CPU不够或超支没法发起交易，然后CPU使用量自然就下降了。反之CPU闲时，CPU价格会降低，用户能够发起的交易增多，自然交易量就大了，CPU使用量就会上升。因此，这个机制还是非常市场化和实时的。这个虚拟CPU量最大为真实CPU量的1000倍，这其实间接认为，抵押的EOS中用来兑换为CPU的那部分占比最少为1/1000。这个虚拟CPU总量没有下限，下限是根据CPU使用量来调整的。下限是直到CPU的使用量低于真实CPU总量的20%才开始不降低或回升。
由于这个CPU价格实时动态调整机制，在一个活跃的市场内，CPU的使用量应该会在阈值(20%)这个量上下波动。事实上数据显示也如此
同时CPU价格应该也有忙闲之分
从上可以看出，凌晨2点开始变闲，凌晨4点到6点最闲，从一定角度可以看出，EOS中国及东南亚国家玩家多。
更长时间的CPU价格图也表明几乎每天都是4点到6点最闲。
上面分析提到CPU的最大使用量就在阈值附近。所以在CPU真实总量确定的情况下，这个阈值是EOS最大TPS的唯一影响因素。那这个阈值又是如何确定的呢？这个阈值就是前一段时间广泛报道的TARGET_BLOCK_CPU_USAGE_PCT。
10月18号EOS通过决议将TARGET_BLOCK_CPU_USAGE_PCT
的值从10%提升到20%，所以TPS在10.18号后得到提升，还是继续看数据。
从上面可以看出，10.18后的2天，社区立马做出了恰当的反应，TPS在短短2天内快速从20左右提升到50的极限TPS并一直保持。
再看看看这个变动后，CPU的真实使用量变化
从上可以看出CPU的使用量也从10%缓慢上升到了20%极限附近。
TPS极限
EOS通过区块CPU总量来调节TPS的极限值。
区块CPU总量=MAX_BLOCK_CPU_USAGETARGET_BLOCK_CPU_USAGE_PCT=2000.2
0.5s产生一个区块，也就是1s中可用2000.22=80ms的CPU
我们以EOS转账为例来说明一个transaction的CPU消耗，目前一个转账交易需要消耗1ms CPU,所以如果EOS中都是EOS转账交易，那么目前EOS TPS理论最高值是80, 但是由于目前很多交易是game类的Dapp，一个交易可能有很多inline action,所以一个交易的耗时是EOS转账交易的2倍左右，从而TPS下降到50左右，和上面的数据分析结果吻合。
TPS如何提升
1）提高TARGET_BLOCK_CPU_USAGE_PCT，这个参数是一个配置，自然可以通过BP提议修改以提高TPS上限，并降低目前CPU价格
2）TARGET_BLOCK_CPU_USAGE_PCT的提升是有限的，最多提升到100%，也就是目前TPS的5倍，所以TPS上线最多达到50*5=250
3) 目前MAX_BLOCK_CPU_USAGE设置为200ms, 1s两个区块，所以1s限定使用400ms, 只占了总时间的40%，这个参数不配置为100%是因为BP节点的CPU除了处理交易，还需要处理网络请求等其他业务，比如交易接收广播，系统软件自身CPU损耗。但是这个40%比例偏低，有提升的可能。
4）EOS系统优化，目前EOS是单线程，BP的超级多核(128核)使不上力，如果并行优化加入，应该可以提升不少。
CPU资源生态优化方向
富人的无成本“倒奶行为“
只提升TPS对改善CPU生态是治标不治本的行为。因为TPS一提升，在达到TPS阈值之前，CPU的价格就会很便宜，由于CPU是免费的，自然会有人发起廉价的交易消耗掉掉这个提升的TPS。上面提到的TARGET_BLOCK_CPU_USAGE_PCT从10%到20%将TPS提升1倍，两天就被吃掉就是一个实例。
CPU资源有价格，但是却是免费的，是CPU资源生态乱像的根源。cpu不够的时候，会出现两个极端。穷人没有CPU，富人一大堆，且有一天有效期，很有可能低效使用甚至乱用。
免费从来就不是资源的最佳分配方式，因而我个人觉得适当的收费是CPU资源生态的一个可能方向。
CPU资源适当收费方向(租赁模式)
CPU资源已经设计成免费模式了，直接在代码中更改为收费不太合理，改动量也大。因而从经济学生态角度来实现CPU适当收费是一个相对安全软改动的方向。具体就是大力发展CPU租赁业务，用户大部分交易通过低价但非免费的租赁方式购买CPU资源。
目前CPU租赁生态已经很红火了，几乎所有钱包(TP, Hoo, MeetOne, 麦子钱包)都支持法币租赁CPU，各大超级节点比如EOS42， Laomao也搭建了租赁平台。但是目前的CPU租赁业务没法承载CPU资源适当收费功能，因为目前租赁生态里的可用EOS太少了，会导致CPU租赁价格过高。租赁生态可用EOS太少原因如下：
EOS所有权目前有3类：资源使用权，投票权，糖果权，由于糖果权属于不确定性资产(需要其他人给你空投)，这里只考虑资源使用权和投票权。同时，用户在投票前必须先抵押EOS，而CPU资源的“租客"是一个动态积累撮合的过程， 用户投票前，很难立马找到"租客"出租抵押EOS，但为了投票，它只好给自己抵押，哪怕他并不需要使用CPU，所以投票的那些EOS很难流入租赁市场。你可能会说，用户可以先抵押给自己然后投票，等有租客了取消抵押，然后再租给租客。但是要想将已经抵押的EOS重新抵押给其他人，需要先取消抵押，而取消抵押有3天的回收期，租客是等不了的，同时3天的无票期也是用户不能接受的。所以事实上目前EOS这个投票权是一个不太自由的权利，它依赖抵押这一行为。那为啥EOS要这样设计呢？这是因为投票后，你相应的EOS需要冻结，要不你投票后立马转账，计票模块还需要更新投票信息，相当于需要监控转账等其他行为，于是通过先抵押这一统一的操作先冻结相应的EOS。所以，为了发展健康的CPU租赁市场，必须切割投票权和资源使用权（抵押行为）。具体怎么做呢？就是用户不用抵押即可投票，EOS仍需冻结，但是这些投票冻结的EOS可以继续抵押给自己或者抵押给别人(出租)，这样分割后，那些投票大户自己就可以开设CPU租赁平台赚钱，或者无心打理的可以交给第三方专业的CPU租赁公司。其实REX就在往这方面尝试，购买REX的EOS可以投票就是一种不抵押投票行为，REX本身又是一个CPU租赁平台，所以投票用户通过购买REX完成了投票和出租EOS两个操作，可见REX从一定角度上是能完善CPU生态的。REX对目前”民营“租赁平台的影响后续我可能会单独写一篇文章，大家可以关注。
完善后的CPU生态可用房市来类比，租售并举，租是一种普世的保障措施。
总结
目前的CPU价格是真实的市场反馈，目前的50TPS是极限TPS，TPS长时间保持满负荷运行，说明需求旺盛。
EOS价格有忙闲之分，凌晨4-6点最闲，CPU紧张的可以试试这个时段。
在TPS极限没有提升之前(TARGET_BLOCK_CPU_USAGE_PCT)，Dapp的推广者不要花全部精力在拉交易量上了，因为TPS总量是定的，市场总交易量几乎是固定的了，整个系统是交易存量市场，零和游戏，一个Dapp多了交易，其他Dapp就会少一些交易，大家可以尝试优化优化下智能合约，尽量少耗一些CPU吧。
目前这个状态，用户经常不能操作，新用户的体验肯定是谈不上爽的，所以在引入新用户的时候，适当给与关怀和指引。
EOS社区需要多花点心思在EOS性能优化和TPS上了，REX也请快点发布吧。
”Dapp“你们走的太快了，请等等你们的“EOS"。
附录
EOS进化“臆想"图
时不时被冻结的资产头脑风暴
普通用户可能只会抵押少量EOS，但是CPU价格的波动导致用户CPU不足或者超支，进而用户没法执行任何交易，用自己的EOS给自己抵押CPU的交易也执行不了了，账号处于冷冻状态。这就存在一个问题，我明明有EOS余额的，但是我没法抵押CPU。我的资产已经不由我做主了。针对这种状态，已经有“民间”商业活动解决了，法币租赁CPU，用租赁的CPU解冻，然后就可以用自己的余额抵押更多的CPU。但是本来是可以设计成用自己余额给自己抵押CPU的，为啥要多出这个花钱租赁操作呢？所以在EOS系统层面增加CPU不足时允许用余额抵押CPU这一功能是有必要的。如果系统层面不能做出改动，那民间是可以想办法的。我这里就有一个想法：
当一个账号CPU不够时，肯定是需要第三方来抵押CPU激活的。作者很早以前就做过免费互助抵押，但是目前这CPU价格，免费业务做不下去了，需要太多EOS了，没法及时补充。所以我想到另外一个思路，被救账号（A)先用scatter等工具发起一个离线交易签名(不需要CPU)，比如A签署一个A转给B 10 EOS的离线交易T1，并将这个数据发给B。有了这个离线交易T1，B就给A抵押10EOS, A就有了足够的CPU.然后B发起离线交易T1, T1执行后就返回了10EOS给B，这样B的EOS池的容量保持不变，可以继续这个免费业务。这个过程可以这样类比，借方A在银行有1万元钱，取钱需要手续费100元，但是A身无分文，取不出来。A就向B借100元钱，B知道A有1万元钱，但是B担心A借了钱不还，所以B需要A写一个“A欠B100元钱"的借条，有了借条，B就无后顾之忧了，于是借给A100元， A拿着100元就可以取钱了，B凭借借条也可以拿回100元。上面1万元就是A用户的EOS余额，借条就是离线交易签名。当然这个方案有一些小问题，需要大家更加完善，比如同步问题。
CPU计算逻辑源码
转载自区块链斜杠青年
Returning WAST from get_code is no longer supported
问题来自 https://github.com/EOSIO/eos/issues/5640
解决方案：
To clarify: get code still works, but now retrieves wasm instead of wast. To function correctly your cleos version must match the api node’s version because of the changes.
澄清：获取代码仍然有效，但现在检索wasm而不是wast。 要正常运行，由于更改，您的cleos版本必须与api节点的版本匹配。
在没有装cleos的机器无法获取，则在rpc机器添加运行参数code_as_wasm=true
还可以使用
get_raw_code_and_abi，然后把返回里的wasm字段先base64解密 然后再求sha256
1.3.x没有这个get_code_hash，之后版本如果只要code_hash 的话 不要用 get_code 直接用 get_code_hash 这个API。