EOS42 联合多名投票代理联合发起的 EOS 投票人赏金计划(EVB),旨在以投票激励的方式，促进 EOS重要基础设施的开发。
如今有 18 位投票代理（总计约 2,800 万票）参与进来，表示有意使用自己的投票权，投票支持构建开源的全历史解决方案或创建备用节点性能测试方案的团队，并且有6个团队正式提交了提案。详情请见正文。
我们也邀请更多的代理和团队参与进来，一起促进 EOS 的发展。
EOS 投票人赏金计划(EOS Voter Bounties, 下文简称为 EVB)的最初愿景是聚拢投票力量以投票激励的方式，为开发后缺乏收入回报的 EOS 重要基础设施提供”资金“支持其开发工作。
EOS 社区很快就团结起来为这一设想提供了支持。有 18 位投票代理（总计 2,800 万票）参与进来，表示有意使用自己的投票权，投票支持构建开源的全历史解决方案或创建备用节点性能测试方案的团队。
EVB 的公告发出后，很快就有多个 BP 与我们联系，如今正式提交了六项提案，两个悬赏项目各自有三个提案。
有问题或者想法，或者想参与其中讨论？点击加入 EVB 电报交流群
下文列表中的提案，按照提交顺序排列。
针对全历史节点开源方案的赏金计划
Rio Hyperion
EOS RIO 团队提出的全历史解决方案已接近开发完成，即将部署。Hyperion 方案会从操作(action)数据中移除冗余与无关的字段信息，显著压缩数据集的同时，也保留了所有的重要信息。
EOS Rio 及其他 BP 也提出了新的 API 标准以提升不同的区块历史解决方案及 dApp 之间的互操作性。
EOS Blocksmith/EOS Detroit 的提案
Blocksmith 和 EOS Detroit 提出了一个历史插件解决方案，可以将数据从 chain 插件流向 Riak 分布式数据存储中，实现高容错性。此外，这一分布式方案也更容易对读取数据请求进行横向扩展。
EOS Nariobi & EOS South Africa(EOS ZA)
EOS Nairobi 与 EOS South Africa (EOS ZA) 表示将合作开发一个 基于 Cassandra 的开源历史解决方案。该方案将受益于 Cassandra 的优势，获得横向扩展性，稳定一致的查询性能，使用普通硬件以节省成本和压缩数据。如果他们能得到足够的支持，他们计划于 4 月 20 日开始开发，预计 2019 年 7 月 1 日前实现一个具备可用功能的解决方案。
讨论
上述所有方案均具备技术可行性，不过，我们更推荐 EOS Rio 的 Hyperion 这一解决方案。Hyperion 已经开发了数月，并且已经可供测试。EOS Rio 也运行着一个流式 websocket API，并且还计划发布一个运行在 Hyperion 之上的分析层。结合这些特性，我们相信 Hyperion 解决了当前以及未来在运行全历史节点时所遇到的问题。
我们也推荐采纳这一方案的历史节点提供者使用 History API v2 这一标准，这将使dApp开发人员更容易提供一致的用户体验。
虽然 EOS Rio 最初计划将 Hyperion 闭源，但现在他们决定发布 Hyperion 的源代码，参与 EVB 计划。参与EVB计划的代理允诺 EOS Rio 可以继续运行免费 API 集群，为多条链提供高可用性的服务。
针对备选节点随机测试方案的赏金计划
ChainRift EOS
ChainRift EOS 的解决方案包含两阶段。
第一阶段无需修改系统代码，采用自主选择加入(opt-in)的方式。代理或者用户可以自主选择加入，为 ChainRift 所开发的合约添加特定的权限。
该机制下会分配一个投票名额，将随机选择一个备选节点选入前21名之列。所有参与的代理会自动协商，随机选择相同的备选 BP。
如果最终能够达成共识可以进行软分叉更改，ChainRift 将做好进一步的变更准备，会用到在第一阶段中已经部署和经过实地测试的合约。
第二阶段会涉及到将一个出块顺序选择智能合约合并到 EOS 系统合约中，并且可以将丢块的备选节点自动踢除(强制备选节点出块或者不再接受奖励)。如果丢块的备选节点马上重新注册成为 BP，但是经测试仍然丢块的话，接下来的15天内将无法再次注册为 BP (细节有待讨论)。
在自主选择加入(opt-in)的情况下，如果BP无法出块，EOS42 所提出的 regproducer 合约第八款将适用于这一机制。软分叉解决方案不需要 BP 介入。regproducer 合约中的第八款会列出被取消的 BP 若不具备出块能力却重新注册为 BP的话，会在多长时间内无法注册。
开发时间： 3 个月时间用于开发合约，开发随机信标需要 6 个月.
NodeOne
NodeOne 提议使用特定的测试网络作为预言机(oracle)，测试出块节点是否准备就绪。所有的 BP 都必须在测试网络上运行节点。在测试网络上的出块结果会广播到一个网站上。
开发时间： 不到 1 个月
持币人投票和 BP 会使用强制的模式。如果 BP 无法出块，则适用 EOS42 所提议的 regproducer 合约的第八条，用于这一机制。
Liberty Block
Liberty Block 所提出的这一解决方案需要硬分叉。有收入的 BP 会进入到出块区域。会对排名 22–25位的节点进行测试。第 21 名的出块节点会具备签署 BP 多签的标准授权。Liberty Block会尝试尽可能降低对出块顺序的变更，仅在需要时才变动。
额外目标(3月31日补充)：
第 21 名出块节点会保留对 eosio.prods 多签的全部投票权限。实现轮换而无需触发schedule的变更(保持 IBC 的紧凑性)。
开发时长： 需要获得4个月支持。需要提交全员提案。
如果 BP 无法出块，EOS42 所提议的 regproducer 合约的第八款将会特别用于此机制。
概括讨论
NodeOne 的解决方案深思熟虑，但在单独网络上运行节点会增加额外开销。另外，对备选节点在测试网络上进行测试，并不能证明在主网上这些节点也做好了毫秒级出块的准备(注： EOS 出块速度为 500 ms)。
此外，这一方案也需要就使用测试网络用于这些测试目的进行协调一致。这一方案下，强制执行仍然需要通过 BP 进行强制，或者经过代币持有者投票。
从理论上讲 Liberty Block 的解决方案是最好的，而且可以说本应当成为 EOS 网络上线后的功能之一。他们所提出了一个永久性解决方案。其核心功能包括对四个备用 BPs 进行测试。
直接对排名 22–25 的BP测试会有所帮助，但理想情况下，应该使得对出块能力的测试具备扩展性，可以对每个有收入的 BP进行测试。毕竟，设计这一机制的目的就是为了确保 EOS 网络具备适应性、有良好性能且具备总体的安全性，即使在大多数 BP 无法服务的极端情况下也能如此。
除此之外，Liberty Block 的提议缺乏一个界定清晰的计划。考虑到这一变更方案影响甚大，目前很难做出任何进一步的判断或建议。鉴于 Liberty Block 具备技术专长，很有可能可以执行精心设计的计划。不过，我们仍需要获得更多的细节，以便了解该提案的准备情况。
从投票代理们那里得到的一致反馈表示，他们不会在没有提案详情的情况下提交投票。我们已将收到的反馈告知了 Liberty Block，并建议其提供一份更为详细的提案。
ChainRift EOS 所提出的解决方案是一个包含了两个不同阶段的综合性计划。首先是自主选择加入(opt-in)的版本(由代理进行委托)，之后，会发展为对 EOSIO 系统合约的升级。
选择加入(opt-in)这一方式, 可以确保 BP 不能停止测试，也不需要15/21 多签。然而，这一方案可能会使得临时解决方案变成永久性的方案。EOS 的相关利益方可能会过于自信满满而不再继续支持该方案，或者也不会采纳第二阶段中的更改并升级系统合约。
ChainRift 提案中的随机信标(random beacon)部分是附加功能，它解决了针对备选 BP 测试的顺序的作弊风险，也有可能会对 EOS 生态系统中的其他部分有用，如博彩 dApp 等依赖于去中心化方式产生随机数的场景。
EOS42 认为 ChainRift EOS 应当直接进行第二阶段，直接测试所有的备选出块节点，并对无法出块的 BP 自动执行强制性操作。ChainRift 表示，若有足够的支持，他们同意直接进入第二阶段。
对 ChainRift 和 Liberty Block 方案的附加说明
为了减少对出块顺序的更改，ChainRift EOS 提议在 4 小时内进行 2 次变更(进入和退出21个出块节点之列)。这是个保守的决定，使得未来在轻客户端和 IBC 解决方案中所用到证明的数据量(the nunber of proofs)保持一个较低的水平。Liberty Block 也提到了要尽量减少对出块顺序的变更，但是其提案中并未提供任何关于实现方式的细节信息。
Liberty Block 的方案涉及硬分叉，而 ChainRift 的第二阶段的方案需要软分叉。
软分叉意味着需要 15/21 的出块BP(eosio@active 的权限)以升级系统合约，并且所有的节点会自动更新。
硬分叉则意味着需要所有的节点都升级其节点的代码。如果节点拒绝升级或者忘记升级，会导致节点挂起，无法与 EOS 主网同步。如果无法得到 EOS 代码库核心贡献者的广泛支持，硬分支的部署方案会难以进行。任何用到硬分叉的变更都需要将其合并为一项更改，并且，需要提前数月与所有的 EOS 利益相关方(开发人员、BP、dApp、交易所等)进行协调。
因此，软分叉的方法更具吸引力和可行性。
总结
感谢所有 EVB 计划的参与者。EVB 计划产生了一个开源的全历史解决方案，可以预期在未来会解决当前 EOS 在全历史节点方面所面临的问题。此外，EVB 计划也展示了在 EOS 投票者和 BP 之间 设定明确激励这一做法所带来的益处。
最后，我们对参与这个项目的优秀团队们致以诚挚的谢意。
EOS42 开创去中心化的未来
EOS42的账号为: eos42freedom。
请为EOS42投票，支持我们继续不停开拓去中心化解决方案的未来。
