在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
如果你不清楚该投哪个见证人或者支持哪个提案，可以考虑把我：设置成你的见证人代理哦！