在之前的文章RC系统解密之最大MANA(max_mana) / 如何提升，我们知道了max_mana的计算规则。

max_mana的计算规则如下：

用户vests - 代理出去的vests + 收到代理的vests + 注册费vests + 下次power down vests

(图源 ：pexels.com)

对于其它几项内容，我们可以通过API读取用户信息获得，但是注册费对应VEST_SHARES却一个历史数据，也就是说在用户注册账户当时是可以通过注册费(STEEM)以及当时的STEEM与VEST_SHARES比例计算出来的。

很显然，除非REPLAY整个STEEM区块链，否则我们没法确定某个账户注册当时的注册费价格以及STEEM与VEST_SHARES的换算关系。那么，我们该如何拿到这个注册费vests这个计算max_mana的关键因素之一呢？

好消息是STEEM区块链帮我们想到了这一点，它在注册账户这一操作之后，直接注册了一个对应的：rc account 亦即create_rc_account，并将对应的内容保存至rca.max_rc_creation_adjustment：

所以，我们不用操心如何计算rca.max_rc_creation_adjustment了，只需读取即可。

那么如何读取呢？其实也很简单，只需调用RC API读取对应的账户即可，以我的账户为例，调用方法如下：

{"jsonrpc": "2.0", "method": "rc_api.find_rc_accounts", "params": {"accounts": ["oflyhigh"]}, "id": 1}

返回内容为：

其中max_rc_creation_adjustment的数值为：12518977945，精度为6，对比一下steemd.com上查询的结果：

可见二者是一样一样的，至此我们已经获得了计算max_mana的所有因素。等等，RC API的find_rc_accounts都返回了什么？其中竟然包括了max_rc（就是max_mana啦），那我们还为什么要费劲周折的计算呢？

(图源 ：pexels.com)

答案是确实不需要计算，但是知道它来龙去脉有助于我们理解这个系统，不是嘛！

This page is synchronized from the post: RC系统解密之：RC相关信息(max_rc_creation_adjustment)的获得

先来一张之前发过的图做封面，否则图片太大，加载太慢，我怕会挨骂😆。

好吧，原本我是计划上传原图的，因为只有未经缩略和裁剪的原图，点开查看才更由韵味。为此我特意在标题上添加了警示说明：巨大无比，爪机勿入。

然而事实证明我的宽带相当不给力，我拖原图上来，进度根本不动。您问我原图多大，其实也不大，几张图片加起来不过才寥寥185M。

没办法，只好缩略一下喽，缩略之后总计才4.83M，是原本的四十分之一。哎！标题的巨大无比，爪机勿入成了笑话。

不过就这么将就体会一下吧，毕竟号称3000亩的花海，只放普通照片太浪费了。

This page is synchronized from the post: 补发花海360°照片(巨大无比，爪机勿入)

半夜快10点了，哥们微信上喊我：“快来救我，我被工人锁楼上了”。我哥们是车会所的老总，他在会所楼上搞了个娱乐室，能喝茶、看电影、开会、打台球啥的。

咋还被工人锁楼上了呢？我好奇的问。他回答说：“这不工人们出去吃饭了吗，然后把无尘车间的小门从外边锁上了，我在楼上，就出不去了！”

“哈哈哈哈，太好笑了。”我说，“那就等工人们回来放你出来呗”，“不行，我要饿死了！”，好吧，为了避免哥们被饿死，我只好去救援了。

到会所之后，我从外边底下抠啊抠啊，找到门销，把外边大门打开。然后又非好大力气打开无尘车间的门，然后又在无尘车间里打开通往楼上的门，我的哥们总算放出来了。

放出来之后，他非拉我去喝酒，其实我晚上都吃得挺饱了，可是他非要感谢我的救援。不过要我看来，救援啥的是假，拉我喝酒才是真正的目的吧。

不过既然出来了，就陪他喝些吧。

又是喝到半夜，哎，这样下去，我估计我很快就会胖起来的，比如啤酒肚啥的，纠结啊~~

看来以后救援什么的信不得啦，想想也是，他打个电话喊员工快点回来就是了，哪需要我救援呢？

This page is synchronized from the post: 紧急救援

在之前的文章RC系统解密之最大MANA(max_mana) / 如何提升中提到下次Powerdown要变现的vesting_shares是影响max_mana的关键因素之一。

(图源 ：pixabay)

微信公共号之前就有一个Power Down的查询功能，会显示用户下次Power Down的时间以及STEEM数量。之前帖子详情可以参考微信公众号增加账户Power Down信息查询

但是现在去看，好像不是那么完善，比如用户计划提多少？已经提了多少？当前是第几周（一共13周)？所以决心对Power Down的查询功能进行一些更新，更新后的查询支持显示以下信息：

• 计划提多少
• 已经提了多少
• Power Down 速率（每次提多少）
• 已经进展到第几周
• 下次Power Down数量
• 下次Power Down时间

使用方法，直接输入@yourid就可以，以我的账户为例，输入应为：@oflyhigh.

为了测试，我Power Down了200 STEEM，测试的部分返回内容为：

(请忽略命名和排版，这方面我是弱智）

公众号添加方法

• 方式一：
  进入微信通讯录->点击公众号->点右上角加号->搜索steemit，关注即可。

• 方式二：
  直接扫描以下二维码：
  

相关链接

• RC系统解密之最大MANA(max_mana) / 如何提升
• 微信公众号增加账户Power Down信息查询

This page is synchronized from the post: 公众号Power Down查询功能更新

家附近有一所大学，有时候就想着没事去大学操场跑跑步，体验一下大学生的感觉。这两天抽空去转了转，大学的校园还真美啊。

不过我把去大学操场的照片发给朋友们，他们都关切地问我，有没有小姑娘小伙子来扶老爷爷过马路？并且告诉老胳膊老腿一定要注意安全，毕竟骨折什么的太麻烦了。

This page is synchronized from the post: 去操场运动

想必STEEM HF20以来最让人又爱又憎的东西莫过于RC系统了(Resource Credit System)，爱它是因为它的引进会防止STEEM网络被滥用，为STEEM的可持续发展铺平道路；恨它是因为它曾给我们很多人带来困扰，尤其是对于一个SP小户而言，这个困扰可能至今尚未消除。

(图源 ：pexels.com)

为了搞明白RC系统到底是啥玩意，我准备去刻苦学习一下，请不要鄙视我用刻苦这个词，因为对于一个半吊子程序员，要搞明白这个复杂系统的那怕一小小丁点功能，其实也是很困难的。

闲话少叙，之前STEEM的带宽系统(bandwidth)中，用户有一个可用带宽概念，简单来讲，就是对于某个用户而言系统中有多少带宽可以被使用。在RC系统中也有一个类似的概念，它的名字叫做max_mana。

以我的账户 @oflyhigh 为例，可以在steemd.com中查询到如下内容：

其中

max_mana 164,858,794,024,586

看起来好长一串数字(是不是代表我有好多资源可用😀），那么这个max_mana是如何计算出来的呢？

通过阅读代码，我发现max_mana使用如下代码获取：

mbparams.max_mana = get_maximum_rc( account, rc_account );

而get_maximum_rc的代码如下：

从中我们不难看出max_mana的计算规则：

• 当前用户持有的vesting_shares
• 减去用户代理出去的vesting_shares
• 加上用户收到的vesting_shares代理
• 加上max_rc_creation_adjustment
• 减去下次Powerdown要变现的vesting_shares

其它几项都好理解，但是max_rc_creation_adjustment这个是什么鬼？通过阅读代码我们不难发现，这个值是在创建RC账户时就被确定的了create_rc_account

在create_rc_account的实现中

通过上述分析，不难得出结论，max_rc_creation_adjustment就是注册RC账户时注册费(STEEM形式)按当时状况计算的vesting_shares。（这个也解释了为何有的用户持有0SP，但是RC还不少，因为注册费高呀）

所以max_mana的计算规则简单来讲就是：

用户vests - 代理出去的vests + 收到代理的vests + 注册费vests + 下次power down vests

(图源 ：pexels.com)

所以如果RC不够用，如何提升max_mana的方法就显而易见了（当然了，你RC够用就随便喽）

• Power up SP
• 减少对外代理
• 避免Power Down

参考链接

• https://github.com/steemit/steem

This page is synchronized from the post: RC系统解密之最大MANA(max_mana) / 如何提升