EOS Voter Bounties (EVB) began with a vision to pool votes in order to “fund” the development of important EOS infrastructure that lacks post development monetary returns. The EOS community quickly rallied behind the idea. Eighteen proxies totaling 28 million votes signaled intent to commit their voting power to the teams that build an open-source full history solution, or mechanism to test standby performance.
Several BPs reached out shortly after the announcement. Six official proposals were submitted. Three for each bounty.
You can view the current list of participating proxies here
Questions? Ideas? Want to be a part of the conversation?
Join the EVB Telegram Channel
All of the proposals are listed in the order we received them.
Full History Bounty
Rio Hyperion
The EOS RIO team has a near fully developed full history solution that is ready for deployment. The Hyperion approach prunes a number of redundant and irrelevant fields present in action data, resulting in a much more compact dataset, that still retains all information of interest.
EOS Rio and other BPs are also proposing a new API standard to facilitate interoperability between different history solutions and dApps.
EOS Blocksmith/EOS Detroit Proposal
Blocksmith and EOS Detroit are proposing a history plugin solution to stream data from the chain plugin into a Riak distributed datastore, allowing for a high degree of fault-tolerance. This distributed approach also makes horizontal scaling of the read requests easier.
EOS Nairobi & EOS South Africa (EOS ZA)
EOS Nairobi and EOS South Africa (EOS ZA) have signaled that they will collaborate to develop an open source Cassandra based History solution. The solution is set to benefit from the advantages of Cassandra, including horizontal scaling, consistent query performance, cost savings by using commodity hardware, and data compression. Given they receive enough support, they plan to start on April 20th and have a functional solution by July 1st, 2019.
Discussion
While all approaches are technically sound and feasible, we suggest EOS Rio’s Hyperion solution. Hyperion has been in development for several months and is already available for testing purposes. EOS Rio also has a streaming websocket API in the works, and is also planning to release an analytics layer operating on top of Hyperion. Combined with these features, we believe Hyperion solves the current and foreseeable challenges in running full history nodes.
We also recommend providers adopt the History API v2 standard, which will make it easier for dApp developers to provide a consistent experience.
While EOS Rio originally planned to keep Hyperion closed-source, they decided to release it open-source for the EVB program. Commitment from proxies participating in the EVB program will allow them to continue running their free api cluster with high-availability for multiple chains.
Random Standby Bounty
ChainRift EOS
The ChainRift EOS solution has two phases. Phase one leverages an “opt-in” approach that requires no system code changes. Proxies and regular users can opt-in by adding permission specifically for the contract developed by ChainRift.
The mechanism allocates one voting slot that randomly selects a standby BP, and puts them into the 21st position. All participating proxies are automatically coordinated to randomly select the same standby BP.
If consensus is eventually reached for soft-forking changes, they will prepare further changes that will leverage the already deployed and battle-tested contracts from phase one.
Phase two would involve merging of order selection smart-contract in the system contract, and feature automatic unreg a SBP misses blocks (forcing standby BPs to produce or never able to receive rewards). If they immediately re-register, but miss blocks again when tested, they can’t register for the next 15 days (details can be debated).
In the opt-in scenario, if a BP fails to produce, article 8 of the proposed EOS42 regproducer will be specifically catered to this mechanism. The soft-fork solution does not require BP intervention. Article 8 of the proposed regproducer would instead indicate the the amount of time a BP is unreg’ed if they rereg without having the ability to produce.
Development time: 3mo for building the contract, and 6mo for random beacon.
NodeOne
Node one is proposing that a dedicated testnet is used as an “oracle” to test standby readiness. All BPs are required to run a node on the testnet. Results of production on the testnet can be broadcast to one website.
Development time: Less than 1mo
Token holder vote and BPs are used as mechanisms of enforcement. If a BP fails to produce, article 8 of the proposed EOS42 regproducer will be specifically catered to this mechanism.
Liberty Block
Solution requires a hard fork, in which paid BPs will be entered into a producing position. Positions 22–25 will be tested. The 21st producer will have the standard authority to sign BP msigs. They will attempt to minimize schedule changes by modifying it if necessary.
Additional objectives stated on 3/31:
The 21st producer will retain full voting power on the eosio.prods multisig.
Implement the rotation without signaling a schedule change (maintain the compactness of IBC).
Development time: requested support for 4 months. Full scope proposal needed.
If a BP fails to produce, article 8 of the proposed EOS42 regproducer will be specifically catered to this mechanism.
Overview Discussion
The NodeOne solution is thoughtful, but introduces additional costs for running a node on a separate network. Furthermore, testing SBPs on a test doesn’t prove millisecond readiness to produce blocks on main-net. This approach would also require coordinating the usage of a test-net for these purposes. Enforcement would also require BP enforcement, or token holder vote.
In theory the Liberty Block solution is the best approach, and arguably should have been an aspect of network functionality at launch. Their solution is a permanent solution. The core feature involves testing of four standby BPs. While testing the immediate 22nd-25th BPs in the rankings is helpful, monitoring ability to produce is ideally extended to every paid BP. After all, the point of this mechanism is to ensure network resilience, performance, and overall security, even in the case that most BPs are taken out of service.
Furthermore, the Liberty Block proposal lacks a clearly defined plan. Considering the magnitude of this kind of change, it’s difficult to make any further judgements or suggestions. Given the technical expertise of Liberty Block, it’s very likely that a well crafted plan could be executed. However, additional details are needed in order to indicate the readiness of this proposal, and we’ve received consistent feedback from proxies that they will not commit votes without a detailed proposal. Liberty Block has been informed of feedback we’ve received, and the suggestion that a detailed proposal is provided.
The ChainRift EOS solution is a comprehensive plan that consists of two distinct phases. First, the opt-in version (proxies delegated), and later evolves into upgrading the eosio system contract.
The opt-in approach guarantees that BPs can’t stop testing, nor would 15/21 MSIG be required. However, it might make a temporary solution permanent. EOS stakeholders might be too complacent to continue supporting this approach, or adopt the changes and upgrade system contracts in phase two.
The random beacon portion of the ChainRift proposal is an additional perk that addresses the risk of gaming the order of standby BPs testing, and might prove useful for the other parts of the EOS ecosystem that to rely on a decentralized way to supply random numbers (gambling dApps etc.).
EOS42 believes ChainRift EOS should move directly to phase 2, which tests all standby BPs and has automated enforcement for BPs that cannot produce. ChainRift has agreed to move directly to phase 2 with enough support.
Additional notes on Chain Rift Solution vs. Liberty
In order to reduce the number of schedule changes, ChainRift EOS is proposing 2 changes (in and out of 21 spot) in 4 hours. This is a conservative decision to keep the number of proofs used in future light clients and IBC solutions light. Liberty Block offered to minimize schedule changes as well, but the proposal didn’t specify any details on how.
Liberty Block approach requires a hard-fork, and ChainRift phase two approach requires a soft-fork.
Soft-fork means 15/21 BPs (eosio@active permissions) can upgrade any (system) contract, and all the nodes would automatically update.
Hard-forks require all nodes to upgrade their node code. Those who forget or refuse to update would halt, and no longer synced with EOS mainnet. Hard forks are can be very difficult to deploy without widespread support from the core contributors to the EOS codebase. Any change proposed using hard-forks needs to be combined into one change, and coordinated months in advance with all EOS stakeholders (developers, BPs, dapps, exchanges). Consequently, the soft-fork approach is far more appealing and practical
Conclusory Remarks
We’d like to thank everyone for participating in the EVB initiative. EVB has resulted in an offering for an open-source full history solution that will solve the issue for the foreseeable future. Additionally, this program shows the advantages of explicitly aligning incentives between voters and BPs. Last, we’d like to express our appreciation for the excellent teams who participated in this program.
EOS42 — Pioneering a Decentralized Future
WEBSITE | MEDIUM | TWITTER | TELEGRAM | LINKEDIN
EOS Voter Bounties (EVB)는 개발 후 금전적 보상이 없었던 중요한 EOS 인프라에 대한 개발에 “자금”을 지원하기 위해 투표를 모으는 비전에서 출발했습니다. EOS 커뮤니티는 신속하게 아이디어를 서포트 하기 시작했습니다. 총 2천 8백만 개의 투표권을 가지고 있는 18개의 Proxy (투표 대리인) 들은 오픈소스 “전체 히스토리 솔루션을 구축 한 팀” 또는 “대기 BP 성능을 테스트하는 메커니즘을 구축한 팀” 에 투표를 행사하겠다는 의도를 보여주었습니다.
몇몇 BP 들의 제출을 시작으로, 현재 6건의 공식 제안서가 제출되었습니다. 각각의 프로젝트에 대한 3건씩의 제안이었습니다.
이 움직임에 참여하는 프록시의 현재 목록을 볼 수 있습니다.
질문이 있으십니까? 아이디어가 있으시거나, 대화의 일부가되고 싶습니까?
모든 제안은 저희가 받은 순서대로 나열됩니다.
전체 히스토리 솔루션 바운티
EOS RIO 제안 (RIO HYPERION)
EOS RIO 팀은 거의 개발이 완료되어 출시를 앞두고 있는 전체 히스토리 솔루션을 보유하고 있습니다. Hyperion 접근법은 액션 데이터에 존재하는 중복되고 관련성이 없는 여러 필드를 잘라 내고, 훨씬 더 컴팩트한 데이터 세트를 만들어 내면서 여전히 모든 관련 정보를 보유합니다.
EOS Rio 및 다른 BP는 다양한 히스토리 솔루션과 dApp 간의 상호 정보교환을 용이하게 하는 새로운 API 표준을 제안합니다.
EOS Blocksmith/EOS Detroit 제안
Blocksmith와 EOS Detroit은 체인 플러그인으로부터 Riak 분산 데이터 저장소로 데이터를 스트리밍하여 높은 수준의 내결함성을 허용하는 히스토리 플러그인 솔루션을 제안합니다. 이 분산된 접근법은 읽기 요청의 수평 확장 또한 더 쉽게 만듭니다.
EOS Nairobi & EOS South Africa (EOS ZA)
EOS의 나이로비와 EOS 남아프리카 공화국 (EOS ZA)은 오픈소스 Cassandra 기반의 히스토리 솔루션을 개발하기 위해 협력할 것이라고 하였습니다. 이 솔루션은 수평 확장, 일관된 쿼리 성능, 상용 하드웨어를 사용한 비용 절감, 데이터 압축 등 Cassandra의 이점을 활용할 수 있도록 설정되었습니다. 충분한 지원을 받으면 4월 20일에 시작하여 2019년 7월 1일까지 기능적 솔루션을 제공 할 계획입니다.
토론
모든 접근 방식은 기술적으로 건전하고 실현 가능한 방법이지만, 저희는 EOS Rio의 Hyperion 솔루션을 추천합니다. Hyperion은 몇 달 동안 개발 중이었으며, 테스트 목적으로 이미 사용할 수 있습니다. EOS Rio는 또한 작동하는 스트리밍 websocket API를 가지고 있으며 Hyperion 위에서 운영되는 analytics 레이어를 출시 할 계획입니다. 이러한 기능과 결합하여 Hyperion은 전체 히스토리 노드를 실행하는 데있어 현재 및 예측 가능한 문제를 해결할 수 있습니다.
또한 저희는 공급자들이 History API v2 표준을 채택하는 것을 추천합니다. 그러면 dApp 개발자가 일관된 환경을 보다 쉽게 제공 할 수 있습니다.
EOS Rio는 원래 Hyperion을 closed-source로 유지할 계획 이었지만, EVB 프로그램을 통해 이를 오픈소스로 출시하기로 결정했습니다. EVB 프로그램에 참여하는 Proxy(투표 대리인) 들의 노력은 이들이 멀티-체인에 대해 사용 가능한 무료 API 클러스터를 계속 실행할 수 있게 해줄 것입니다.
대기 BP 테스트 바운티
ChainRift EOS
ChainRift EOS 솔루션에는 두 단계가 있습니다. 1단계는 시스템 코드 변경이 필요 없는 “옵트-인 (opt-in)” 방식을 활용합니다. Proxy 및 일반 사용자는 ChainRift가 개발한 컨트랙트에 특별 권한을 추가하여 옵트-인 할 수 있습니다.
이 메커니즘은 무작위로 대기 BP를 선택하는 투표 슬롯 하나를 만들고, 이를 21 번째 위치에 배치합니다. 참여한 모든 Proxy 는 자동으로 조정되어 동일한 대기 BP를 무작위로 선택합니다.
결국 소프트-포크 변화에 대한 합의가 이루어지면 1단계에서 이미 배치되고 테스트를 마친 계약을 활용할 수 있는 추가 변화를 준비 할 것입니다.
2단계는 시스템 컨트랙트에서 주문 선택 스마트 컨트랙트를 병합하고, 자동적으로 블록을 놓치는대기 BP를 자격 해제 시키는 기능을 담고 있습니다. (대기 BP를 강제 생산시키거나, 또는 보상을 받을 수 없게 만듦). 만약 그들은 즉시 재등록하고, 테스트 할 때 다시 블록을 놓치는 경우 향후 15일 동안 자격 등록을 할 수가 없습니다 (세부 사항은 논의 될 수 있음).
옵트-인 시나리오에서 BP가 생산에 실패하면, EOS42가 제안한 regproducer 의 제 8조가 이 메커니즘에 특별히 제공 될 것입니다. 이 소프트-포크 솔루션은 BP 개입을 필요로 하지 않습니다. 제안 된 regproducer 의 제 8조는 BP 생산 능력이 없는 상태에서 재등록 할 경우, BP 자격을 해제하는 기간을 표시합니다.
개발 시간: 스마트컨트랙트 개발 — 3개월, Random Beacon — 6개월.
NodeOne
노드원은 대기 BP를 테스트하기 위해 전용 테스트넷이 “오라클”로 사용되도록 제안합니다. 모든 BP는 테스트넷에서 노드를 실행해야 합니다. 테스트넷에서 블록생성한 결과를 하나의 웹 사이트로 broadcast 할 수 있습니다.
개발 시간: 1 개월 미만
토큰 홀더 투표 및 BP들이 집행/처벌의 메커니즘으로 사용됩니다. BP가 생산에 실패한다면, EO42가 제안한 regproducer 의 제8조가 이 메커니즘에 특별히 제공 될 것입니다.
Liberty Block
이 솔루션은 유급 BP가 생산포지션에 입력되는 하드 포크가 필요합니다. BP순위 22–25 위 위치가 테스트됩니다. 21 번째 생산자는 BP 멀티시그(다중서명)에 서명할 수 있는 표준 권한을 갖습니다. 이들은 필요한 경우 수정하여 스케쥴 변경을 최소화 하려고 시도합니다.
3/31 에 명시된 추가 목표 :
21 번째 프로듀서는 eosio.prods 멀티시그에 대한 전체 투표 권한을 보유합니다.
스케쥴 변경을 알리는 신호 없이 로테이션을 구현합니다. (IBC의 컴팩트함을 유지).
개발 시간: 4개월 동안 지원이 요청됨. 전체 범위 제안이 필요함.
BP가 생산에 실패한다면, EOS42 가 제안한 regproducer의 제8조가 메커니즘에 특별히 제공 될 것입니다.
총평
NodeOne 솔루션은 사려 깊지만 별도의 네트워크에서 노드를 실행하는 데 추가 비용이 발생합니다. 또한 테스트넷에서 대기 BP를 테스트해도 메인넷에서 블록을 생성할 millisecond 의 준비성은 보장되지 않습니다. 이 접근법은 BP 테스트 목적으로 테스트넷의 사용/생성을 조정해야 하며, 집행/처벌 또한 BP가 집행하거나 토큰 홀더의 투표를 요구할 것입니다.
이론적으로 Liberty Block 솔루션이 가장 좋은 접근 방법이며, 런칭시 가졌어야 할 네트워크 기능적 측면일 것입니다. 그들의 해결책은 영구적인 해결책입니다. 핵심 기능은 4개의 대기 BP 테스트입니다. 22위-25위 BP를 테스트하는 것이 유용한 동시에, 생산 능력을 모니터링 하는 것이 모든 유급 BP에 확장될 수 있습니다. 결국, 이 메커니즘의 요점은 대부분의 BP가 서비스를 중단 한 경우에도 네트워크 탄력성, 성능 및 전반적인 보안을 보장하는 것입니다.
Liberty Block 제안에는 명확하게 정의된 계획이 부족합니다. 그들이 제안하는 변화의 정도를 고려할 때, 더 이상의 평가를 하는 것은 어렵습니다. Liberty Block의 기술적 전문성을 고려할 때 잘 만들어진 계획이 실행될 가능성이 큽니다. 하지만, 제안의 준비 상태를 나타내기 위해 추가 세부 사항이 필요하며, 그들의 상세한 제안 없이는 투표하지 않을 것이라는 일관된 의견을 프록시로부터 받았습니다. 리버티 블록 (Liberty Block)은 이러한 요청을 전달 받았습니다.
ChainRift EOS 솔루션은 두가지 단계로 구성된 포괄적인 계획입니다. 먼저 옵트-인 버전 (프록시가 위임 됨) 이 되고, 나중에 eosio 시스템 컨트랙트를 업그레이드하는 과정입니다.
옵트-인 방식은 BP들이 테스트를 중단 할 수 없게 만들며, 15/21 다중서명을 필요로 하지 않습니다. 하지만 이는 임시 해결책을 영구적으로 만들 수 있습니다. EOS 이해당사자들은 너무 안이해서 이 접근방식에 머무르며 2단계로의 변경 및 업그레이드된 시스템 컨트랙트를 채택하지 못할 수 있다.
ChainRift 제안의 Random Beacon 부분은 대기 BP 테스트의 순서를 게임에 의거하여 다루는 추가적인 특성으로, 탈중앙화된 방식으로 난수를 제공하는 데 의존하는 EOS 생태계의 다른 부분에 유용하게 사용될 수 있습니다 (도박 dApps 등).
EOS42 는 ChainRift EOS 가 모든 대기 BP를 테스트하고, 블록을 생산 못하는 BP를 자동적으로 처벌하는 방식인 2단계 방식을 바로 적용해야 한다고 생각합니다. 체인리프트는 충분한 지원을 받을시 바로 2단계를 적용하는 것을 합의하였습니다.
Chain Rift Solution VS. Liberty에 대한 추가 참고 사항
스케쥴 변경 횟수를 줄이기 위해 ChainRift EOS는 4시간 안에 2회(21위 안팎)의 변경을 제안하고 있습니다. 이는 향후 경량 클라이언트와 경량 IBC 솔루션에 사용되는 증명 갯수를 가볍게 하기 위한 보수적인 결정입니다. Liberty Block 또한 스케쥴 변경을 최소화하겠다고 제안했지만, 그 방법에 대한 자세한 내용은 밝히지 않았습니다.
Liberty Block 접근방식은 하드-포크, ChainRift 2단계 접근방식은 소프트-포크를 필요로 합니다.
소프트-포크는 15/21 초대다수 BP(eosio@active 권한)가 어떤 (시스템) 컨트랙트라도 업그레이드할 수 있고, 따라서 모든 노드가 자동으로 업데이트되는 것을 의미합니다.
하드-포크는 모든 노드가 그들의 노드 코드를 업그레이드 해야 합니다. 업데이트를 잊거나 거부하는 사람들은 중단될 것이고, 더 이상 EOS 메인넷과 동기화되지 않을 것입니다. 하드-포크는 EOS 코드베이스에 대한 핵심 기여자들의 광범위한 지원 없이는 배치하기가 매우 어려울 수 있다. 하드-포크를 사용하여 제안된 모든 변화는 하나의 변화로 결합되어야 하며, 모든 EOS 이해관계자(개발자, BP, Dapp, 거래소)와 몇 개월 전에 조정되어야 합니다. 결과적으로, 소프트포크 접근방식은 훨씬 더 매력적이고 실용적일 수 있습니다.
결론사항
EVB(EOS Voter Bounties) 이니셔티브에 참여해 주신 모든 분들께 감사드립니다. EVB 의 노력은 가까운 미래에 오픈소스 전체 히스토리 문제를 해결할 솔루션을 제공할수 있게 하였습니다. 또한 이 프로그램은 토큰 홀더(voter)와 BP간의 인센티브를 명시적으로 일치시키는 장점을 보여줍니다. 마지막으로, 저희는 이 프로그램에 참여하는 훌륭한 팀들에게 대해 감사를 표하고 싶습니다.
EOS42 — Pioneering a Decentralized Future
WEBSITE | MEDIUM | TWITTER | TELEGRAM | LINKEDIN
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 之间 设定明确激励这一做法所带来的益处。
最后，我们对参与这个项目的优秀团队们致以诚挚的谢意。
