1票30投的的优化方案：
现在投票给每个节点都是总票数的数量，可以变成这样：
30投加起来等于总票数。
如果你投30个节点，每个节点得到30分之1的票数，
你投3个节点，每个节点就得到3分之1票数。
目前的问题是原本想投几个节点，但是剩下的投票不投也浪费，容易形成寻租现象。
我这个优化方案既可以1票1投，也可以1票30投，灵活投票。
实行生效后节点的排序不会改变，只是得到投票的总数变少了，投票人重新投票才会改变节点排序。
欢迎大家讨论。
这实际上就是允许一个账号平均分配票数投给 1 - 30 个节点的一票一投。
eos 是可以无限分割的，我认为应该改为一个账号可以投给任何个数的节点并且对每个节点的票数自由划分的一票一投，这样才能最大程度反应一个人对现有每个节点的偏好。
你好，“容易形成寻租现象”，其实没太懂这句话。如果寻租是指 寻租（rent seeking），在没有从事生产的情况下，为垄断社会资源或维持垄断地位，从而得到垄断利润（亦即经济租）所从事的一种非生产性寻利活动。“实行生效后节点的排序不会改变，只是得到投票的总数变少了”这样的结果对于节点不是好结果，节点奖励一方面是根据获得总票数多少定的，票数越多排名越高获得奖励越高。方案改变前后对于普通社区成员投票者好像没有影响和变化。
其实我不太赞同“剩下的投票不投也浪费”这样得想法，如果投票 <30，这对于“原本想投几个节点”是负责任的，因为这样才能让这几个节点的票数更高，排名更靠前，节点奖励更高，真正作为普通社区成员支持自己认可的这几个节点的发展，聚少成多，汇聚力量。
你好@Josh-Chung 其实你说的对，“一个账号可以投给任何个数的节点并且对每个节点的票数自由划分的一票一投，这样才能最大程度反应一个人对现有每个节点的偏好”。
嗯，其实可以说EOSIO是生态，一家节点，或者说三家节点都很难很好地维持一个生态的持续发展，如果可以“投给任何个数的节点并且对每个节点的票数自由划分的一票一投”，那么就一定会出现节点间票数差巨大的情况，这又会引出奖励分配差额不均，那怎么保证头部节点会持续或有能力维持EOS生态的持续良好发展。现在每家节点都有不同的主打项目，尽可能多的支持这些真正做事的节点，就是支持这些节点背后的人才，留住人才，才可以促进EOS的长久和繁荣。
这个问题可以通过设置合理的奖励计算机制缓解。在票数达到前 21 名之后，票数对奖励多少的影响可以设置得小一点。备选节点的奖励计算也是同样的道理。
我们可以把节点奖励看作是网络为节点的提供的服务所付的服务费。这个服务可以划分为: 出块、提供 API等。对所有出块节点来说，出块奖励和提供 API 服务的奖励应该是一样的，再加上共识算法的考量，奖励的计算方式就是这个相同的奖励的基础上加上以票数为变量的奖励计算部分。现在的节点奖励也是这么计算的～
抱歉我描述的不精确，寻租现象是指我本来投我想投的几个节点就好了，但是别的节点给我好处我也可能考虑投给它，因为我可以投30个，不在计划内的投票不会影响我已投节点的票数。
生效后不会影响当前节点的排名，它们的得票数是同时减少了，实际上总票数同时减少了，每个节点得票的比例没有变化。
假如以前你有30的票数，你投30个节点，每个节点得到30票，你的总票数实际有900票。优化后你30票投30节点，每个节点得到1票，总票数仍然是30票，节点得到的票数少了，但是注意是大家同时少了，排名占比没有变化。
至于说投每个节点应该自定想给投的票数这种操作是提高了投票自由度，但是考虑实施后操作比较繁琐，而且可能不好过渡，如果能无痛过渡成功，肯定要在生效的时候不会引起节点排名大的波动。
每个节点应该自定想给投的票数这种操作是提高了投票自由度，但是考虑实施后操作比较繁琐，而且可能不好过渡，如果能无痛过渡成功，肯定要在生效的时候不会引起节点排名大的波动。
过渡不是问题。过渡期默认将原来的投票 30 等分。如果未投满 30 个，多余的票变为未投出状态。这样的话，只要投票账号不重新投票，排序就没有变化