EOS超级节点，就像是在一个跨国大企业 EOS 上班的员工，不仅仅要自备机器上班，更有意思的一点是，领工资不及时，还会被扣工资！
听起来很奇怪，不过，看完这篇文章，你应该能够对EOS增发和节点奖励的方式，有更多的理解。
也会明白，比如liquidEOS这样从不领取奖励的节点，要么是笨，要么是懒。不论哪一点，都是一个称职的节点所应该做的。
要了解为什么EOS节点如果领取工资太慢了，会被扣工资？都是复利在搞鬼！
太长不看的缩略版：
- EOS节点每次领取奖励时，EOS才增发；
- EOS是连续增发的模式，连续通胀率是4.879%，年度通胀是5%；
- EOS节点领取奖励的次数，会影响到EOS增发的数量；
- 节点每天最多领取一次奖励，且得票奖励部分，需要至少要满100个EOS才能够领取；
- 综合考虑，EOS节点每天领取奖励(如果有的话)，是比较合适的方式。
提醒一点，不需要一提到通胀就害怕，EOS的温和通胀模式 + 多重锁币模式, 实际上，如果计算 EOS 的流通量，甚至可能是通缩的模型。
回到本文主题，我们先了解一下EOS的通胀率的设定方式。
奇怪数字: 4.879%
如果你有看过EOS节点奖励相关的代码(producer_pay.cpp)，你会很奇怪，其实，并没有什么5%的通胀，而是一个奇怪的数字：0.004879， 和一个陌生的名称:continious_rate
如下所示的这行代码，位于 producer_pay.cpp 文件中：
const double continuous_rate = 0.04879; // 5% annual rate
这是怎么回事？说好的5%呢？
如何保持5%的年度通胀率
简单来说：EOS是采用了连续通胀的方式，就是说，EOS的增发，并不是每年发一次，或者每个月发一次，而是，每次节点发起领工资操作的时候，就会根据一个比率，计算出来应该要新增加多少EOS来分配。
由于复利的存在，自然每次不可能是新增加5%的EOS；不然，年通胀率肯定会超过5%的，你可以自己计算下。
所以，为了维持年度通胀率为5%，倒推得来的连续通胀的比例，就是4.879%，也就是说，推到极致的情况，假设节点跟疯了似的，每分每秒都在发起领工资的请求，系统随时在制造新的EOS的情况下，增发的比例是4.879%，这样才能够限定年通胀率为5%。
我们进行一下详细的解释。
连续通胀与分批通胀：两种制造通胀的模式
通常增加供应量，有两种方式：
分批增发的通胀
第一种，也是现在现实世界中增发货币所用的，是分批印钞。
假设你是某国的大boss，你决定货币的年度通胀为5%。
你可以每年的1月1日，印一次钞票，假设此时货币的流通量是1个亿，那么，你需要下令印发五百万的货币，可以实现年通胀率5%；
第二年的1月1日，货币流通量是一亿五百万，那么，为了维持年通胀率5%，第二年1月1日，需要增发的钞票是： 一亿五百万 * 5%。
连续通胀
还有第二种方式，也就是EOS所实现的方式：连续通胀。
连续通胀，实际上可以理解为将按批次增发模式的批次，缩短到一个非常小的数值。
第一种方式中，我们是设定了每年增发一次，所以，每次增发5%就足够了；
但是在EOS这种经济体制中，节点每隔2分钟就变动一次，并且节点也要吃饭啊，如果每年增发一次的话，那么，带给节点的激励就非常有限了，节点的投入巨大，却只能一年领一次工资，还不反了才怪。
怎么办呢？
我们先理解一点，也是上篇文章我们提到过的：节点领取工资的时候(claim Reward)，是系统增发的时候。如果节点每秒都在领工资，那么，EOS就会每秒都在增发。
解释一下。
EOS采用了连续发工资的方式：只要按照规则你能够领得到钱，那么，你可以随时发起领工资的操作；
每次发起操作，系统会计算，距离上一次领取工资的时间有多久了，应该要新增加多少的EOS用于分配奖励，并且将新增的EOS分配到不同的奖励池中。
(具体的奖励规则，看我的上一篇文章。)
节点领取奖励。(例外：如果节点领取的是得票奖励，必须得到的奖励数额不小于 100 EOS，才可以领取)
假设节点是随时领取工资的，那么，每次系统计算新增EOS数量的话，肯定不会按照5%来增发，对吧？
因为复利的存在。
总结
因为EOS的增发模式是连续增发的，所以，为了维持年度通胀为5%，每次增发的比例必须是一个小于5%的数值；
运用微积分的知识，可以推导出来，假设是增发的次数是无限多次，那么，连续通胀的情景下，所设置的连续通胀率就是4.879%。每次增发的数额，根据这个4.879%来计算，如下方式来计算：
new_tokens = continuous_rate * token_supply.amount *usecs_since_last_fill / useconds_per_year;
为了精确，计算新增EOS数量用到计算时的时间单位是us，即微秒。
usecs_since_last_fill 是从上次领取奖励到现在的微秒数；useconds_per_year是指的每年一共有多少微秒。
感兴趣的话，可以查看这一Issue，里面列出来整个求解的过程：
https://github.com/EOSIO/eos/issues/1537
为什么最好每天领工资？
上面的过程比较繁琐，我们实际来看一下。
现在我们知道了，连续通胀率是4.879%，就是说，每次增发 EOS时候，都是根据流通量 * 4.879% * 时间比例，来计算增发的EOS数量。
那么，假如节点非常非常懒，每年节点才领取一次奖励，那么，实际新增的EOS就会是：
4.879% * EOS的流通量；实际的EOS年度通胀率就会成为了： 4.879%！按照流通量为10亿 EOS来计算， 如果每年才领取一次工资的话，新增的EOS数量，就少了一百多万 EOS(一亿 * (5% - 4.879%))。
所以，由于这里新增EOS是用的连续通胀的方式，尽可能的减少领取的间隔，尽可能频繁的领取奖励，对于节点而言，是利益更大化的做法。
由于得票奖励有一定的限制, 必须不小于100个EOS才能够领取。
并且，在eos.system的代码里面限定了，领取奖励的间隔，必须是要24个小时以上才行。就是说，每天最多领取一次奖励。
所以，综合看来，每天领取一次，是比较好的一个指标。当然，部分得票率少的备选节点，分配的奖励可能不足100个EOS，就只能够眼巴巴看着别人领取奖励，而自己就等着了。
如果要做的更加细化一点，对于各个节点自身而言，根据自己的得票权重的比例，来计算出来什么时候领取是最优方式，也可能能够让自己的收益更多一点。
小结
- EOS节点每次领取奖励时，EOS才增发；
- EOS是连续增发的模式，连续通胀率是4.879%，年度通胀是5%；
- EOS节点领取奖励的次数，会影响到EOS增发的数量；
- 节点每天最多领取一次奖励，且得票奖励部分，需要至少要满100个EOS才能够领取；
- 综合考虑，EOS节点每天领取奖励(如果有的话)，是比较合适的方式。
希望这篇对你理解EOS的增发模式，能够有所帮助。