[EOS] 为什么一票三十投？为什么采用赞成投票制？为什么基于持币权重计票？

Thomas Cox五月一日在medium发表一篇文章，详细介绍了EOS 的投票机制，题目是： 为什么 EOSIO的投票，是基于所持通证权重的赞成投票制(Approval voting)？ 为什么采用一票三十投的方式？

8o1b0whaha41.png

以下为正文。

很多人跟我联系，告诉我他们的想法。他们说 EOSIO不应该采用默认的赞成投票制，而应该采取其他的方式。

(译者注：Approval Voting，赞成投票制，又叫做同意投票，或者认可投票。在选举之中，可以多选的投票制度)

具体而言，EOSIO 软件默认采用了一票三十投的方式，即，一个账户可以为三十个出块节点投票。假设一组候选人总数为N，那么，投票者可以投票选择他们自己青睐的节点，最多可以为三十个节点投票。系统会根据得票数，选出来前21个区块生产者作为活跃节点，接下来的49个节点，作为备选节点。排名在71名及以后的节点，会被忽略，这是考虑到出块节点的状态而设定的。

（译者注：BM明天会发布文章，解释为什么备选节点从100个缩减到了49个。我猜测，主要的原因还是从节点收益和节点稳定性这两个方面去考虑的）

另外，每个账户的投票的权重，和账户所持有的抵押token的数量相关。所持有的token越多，则投票权重越大。例如，Alice 抵押了100个token，那么，她所投出的30票中的每一张投票，都具有100的权重；Bob 抵押了50 token，则他为自己青睐的节点所投出的每一张票，都是50的权重。如果Alice 和 Bob 都投票给了候选出块节点 ‘EOSfoo’，那么， EOSfoo的得分就是150.

(译者注： 这里简单解释一下，为什么是抵押token。在EOSIO中，账户要想投票，需要通过系统的合约，抵押自己的token以获得投票权，锁定期为三天；抵押token的同时，这部分token仍然可以得到RAM/存储/带宽的使用权。换句话说，将token抵押以获得投票权，与为了使用系统的资源而做的抵押，两者是相互独立的。)

为什么采用赞成投票制(Approval voting)

基于我对投票相关文献的理解，赞成投票制的效率，略逊于记分投票制(Score voting，或者Range voting). 但是记分投票制和赞成投票制，都比排序投票制(Rank voting)要好。

感兴趣的同学，我推荐可以看下这个投票机制模拟器.

对排序投票制问题的研究，可以追溯到二十世纪五十年代；请参看：阿罗不可能定理.

根据阿罗的发现，我们可以排除掉排序投票制了。下面我们来看一下对投票机制的剩余选项的贝叶斯分析 -- 向下滚屏，你会看到下面的一张图片，来自William Poundstone的著作 《操控选举》(Gaming the Vote) ，在书中第239页：

1.png

有如下的选项：

1. 随机选择
2. 多数制 (当前美国的标准模式)
3. Borda 计数法(Borda count)(https://zh.wikipedia.org/wiki/%E6%B3%A2%E9%81%94%E8%A8%88%E6%95%B8%E6%B3%95)
4. 孔多塞法（Condorcet method ）
5. 记分制
6. 赞同投票制

你可以看到，记分投票制略好于赞同投票制，但是，赞同投票制要简洁得多，也好过其他的方式。

上述的投票制度模拟中，只是投票选出来一名获胜者—如果要选择21个出块节点，情况要复杂得多。所以，选择赞同投票制，可以更加简洁高效。

这就是我们将EOSIO 软件所默认安装的投票方式设置为赞同投票制的原因。

如果你需要采用不同投票系统的EOSIO，那么， 我建议你可以在主链上线后，提交宪法修正案，或者去说服大多数的出块节点和投票人，在主网启动时安装不同的投票方式。(如果你在私有或者分叉链上使用EOSIO，你当然可以选择任意的投票系统了，你喜欢就好)

为什么一个账户可以投三十张票，而不是一个账户投一张？

EOSIO社区的一位合作者Todor 自己创建了对EOSIO 出块节点使用赞同投票制的模拟，他模拟了每个账号投票1次到50次的不同情况。他的数学探索显示，每个账户投票三十次与投票一次相比，前者的风险更小，尤其是在区块链被少数贿选节点控制的风险方面。

对我而言，一个账户可以投票多次这一机制在BitShares 和 SteemIt项目中运行良好，这是个不错的的兆头。

为什么采用基于持币权重的投票权机制？

在真实世界中，我们习惯了选举时候只投一张票，选一个人(至少在理论上是这样)。许多采用 DPOS 机制的区块链，包括BitShares 和 SteemIt，采用了基于持币权重的投票机制。这有时候也被称为“一token，一选票”(这说法有些困扰)。实际上，每个账户可以投30次，每一次投票的权重(如前面所描述的)，都等同于账户所持有的token的数量。每一个区块生产者的总票数，等于该节点的全体投票人所持有token的总数。

难道这不是寡头垄断，或者财阀统治么 -- 富人占据了统治地位？

是的。区块链是完全基于财产的；区块链没有监狱，无法逮捕犯罪者，无法定义或防御国界线，无法维持常规军队。在真实世界统治之中使得“一人一票”显得重要的那些原因，在基于财产的区块链上，却并非如此。拥有越多的token，你会拥有更大的权力 -- 也会让你面临更大的风险。

拥有更多的token，也会让人更容易受到区块链上的负面事件的影响。

不止是财阀统治

尽管如此，仍然有一些建议，EOSIO 软件应该允许关于投票的多重 “引力中心”的存在 -- 通过附加的单独的投票方式，对现有的token-集中式的投票模型加以平衡。有如下的备选方案：

• 每个得到强烈认同(strong-identity)的人， 都有一张选票 (这里“强烈认同” 意味着满足某些明确的人性证明标准)
• 每个 DApp 开发者, 都有一张选票 (或者根据DApp的人群多少，来决定投票权重的区间值) 详见此处的描述.
• 每个区块生产者，都有一张选票
• 链上的一个供应商，都有一张选票
• 如此等等

这些提议的方案，与基于token的投票系统并行存在，基于token权重的投票者是某种类型的上议院(大鲸议院？)，其他的类似众议院(或者Dapps或其他的议院)。

通用的计划可能是，对于大型的系统决策(宪法修正，协议升级等事项)，需要得到议院中的大多数甚至超级多数投票同意。

上述关于多议院的想法，都没有在公链上实验过，不过，我很想知道，一旦尝试这些想法，会有什么样的结果。

上述的想法都没得到足够的发展，因此无法在六月份主网上线时作为 EOSIO 软件的默认配置。

幸运的是， EOS 社区可以通过两种方式修改默认的宪法： 在上线时候采纳不同的宪法，或者，在上线之后，使用宪法修正的流程，对所采纳的宪法进行修改。

总结

总而言之，我们期待 使用 EOSIO 软构建的的区块链可以使用赞同投票制。赞同投票在其他的DPOS 区块链上有良好的记录，并且，针对先前实现中存在的一些问题，做了调整。

我们可以期望，赞同投票制(Approval voting)会产生相对良好的结果(远远好于其他的投票系统)。我们能够期待，它会产生相对简洁的用户体验(只需要选择30个你青睐的节点) — 这取决于社区会创造出什么样的界面（或者只是用命令行工具来投票）.

最重要的是，我们可以期望，基于持有通证权重的投票系统，会产生更好的区块生产者的选择结果。