在HIVE硬分叉25(HardFork 25)中引入了诸多共识变化,其中一个非常重要的变化就是:治理投票的失效机制。
(图源 :pixabay)
治理投票 & 失效机制
很多新用户可能一头雾水,治理投票是什么鬼?治理投票失效机制又是什么鬼?别急,听我慢慢道来。
先说治理投票,作为POS(股权证明)区块链,见证人负责出块以及更新共识(硬分叉)等诸多重要事项,而见证人又是用户通过投票选举产生的,这就是见证人投票;用户除了可以自己投票以外,还可以把投票权委派(代理)给别人,这就是见证人代理;还有一种投票就是提案投票,也就是说用户可以通过投票,决定基金池的钱怎么花。
所以总结起来,治理投票有以下三种:
- 见证人投票
- 见证人代理
- 提案投票
再说失效机制,假设用户们选举了一批见证人,但是由于懒惰,投票之后就不管了,哪怕这个见证人的节点常年处于死机状态也不去撤票,那样投票就失去了意义。如果某体量巨大(HP超多)的用户从不更新投票,对整个系统而言,无疑不是什么好事。
如何让用户经常更新投票,让被选举出来的见证人(或者提案)更符合民众(或者说股权所有者们)的真实意愿?为了解决这个问题,HF25中引入了一个重要的共识变化:治理投票的失效机制。
治理投票的失效机制简言之就是:
一年以上没有参加治理投票的用户,他的见证人投票& 见证人代理 &提案投票都会重置。
失效机制的生效时间
原本我以为,从HF25开始,这个规则就会被应用,但是HF25之后,我研究了一下代码,发现事实并非如此。这主要有两方面原因:
第一个原因:代码中一个常量的定义,使得整个规则被应用,延后了一年:
#define HARDFORK_1_25_FIRST_GOVERNANCE_VOTE_EXPIRE_TIMESTAMP (fc::time_point_sec(HIVE_HARDFORK_1_25_TIME) + HIVE_GOVERNANCE_VOTE_EXPIRATION_PERIOD)
上述代码,我认为改成如下代码就没问题了:
#define HARDFORK_1_25_FIRST_GOVERNANCE_VOTE_EXPIRE_TIMESTAMP (fc::time_point_sec(HIVE_HARDFORK_1_25_TIME))
第二个原因:为了避免HF25时,集中处理老旧投票影响区块链性能,代码中通过一个求余操作,将老旧投票过期时间,分布在一个半年的时间窗内:
const int64_t DIVIDER = HIVE_HARDFORK_1_25_MAX_OLD_GOVERNANCE_VOTE_EXPIRE_SHIFT.to_seconds(); governance_vote_expiration_ts = HARDFORK_1_25_FIRST_GOVERNANCE_VOTE_EXPIRE_TIMESTAMP + fc::seconds(governance_vote_expiration_ts.sec_since_epoch() % DIVIDER);
其中:
#define HIVE_HARDFORK_1_25_MAX_OLD_GOVERNANCE_VOTE_EXPIRE_SHIFT (fc::microseconds(HIVE_GOVERNANCE_VOTE_EXPIRATION_PERIOD.count()/2))
所以,最终的效果就是:
- HF25之后的治理票,一年以后过期;
- HF25之前的治理票,会随机分布在HF25一年之后的半年时间内。
吓人的expired_account_notification
而如今,HF25已经过去了一年零一个月,所以老旧的投票(一年以上没更新的)将会在未来5个月内陆续失效。如果你的治理票已经失效,在https://hiveblocks.com/ 中将会看到类似如下的信息:
不得不说,这个expired_account_notification命名起得挺吓人的,不知道的以为账户过期了呢。😰
如何避免治理票失效?
想必通过上述介绍,答案已经呼之欲出了,那就是: 至少每年参与一次治理投票(见证人投票、设置见证人代理或者提案投票)。
这里顺便求一下见证人票,欢迎大家支持见证人(witness):@abit 以及 @oflyhigh
如果你不清楚该投哪个见证人或者支持哪个提案,可以考虑把我:设置成你的见证人代理哦!