EOS Town Hall - April 1, 2019
/Notes Created By: LibertyBlock
Purpose
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. This week we discussed EOS42’s SWOT analysis of current proposals.
Key Takeaways
Voter Bounty Updates (1:18)
The EOS community quickly rallied behind the idea of funding the development of important EOS infrastructure. Eighteen proxies totaling 28 million votes signaled an intent to commit their voting power to the teams that build an open-source full history solution, or mechanism to test standby performance.
Standby Proposal Overview (6:55)
Kedar’s Thoughts on Standby BP Proposals (9:50)
A major worry is additional bloat from schedule changes. Mandating a schedule change every fours hours would increase the data required to run a light node by 3–5x. That number might be manageable but there’s a concern it could get out of hand.
Another issue is having to hit a threshold of votes for the smart contract to be useful. We could end up in a weird situation where testing standby block production is cycled in and out every twelve hours due to intermittently running out of votes.
Hyperion Overview (18:52)
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.
ChainriftEOS’ Solution Overview (30:50)
The ChainRift solution 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.
NodeOne’s Solution
NodeOne proposes a dedicated testnet where all paid BP candidates are mandated to run a full node. In the testnet, all participating BPs, regardless of being in top 21 or not in the mainnet, will have their turn producing blocks. Their track record of performance in the testnet will be monitored and fed back into mainnet on-chain in real-time
LibertyBlock’s Solution
In order to ensure that backup block producers are always ready to produce blocks, LibertyBlock proposes the following:
Replace the 21st slot in active production with a rotating slot that allows backup producers rank 21–25 to rotate into the production schedule. Each of the five backups will take turns producing blocks. Implementing this solution will require a hard fork.
Next Week’s Call
To be determined. Stay tuned for an announcement in the EOS Town Hall Telegram!
Connect
A special thank you to:
Tim & Kedar - LibertyBlock
Luiz & Igor— EOS RIO
Luka - ChainRiftEOS
Ryan - EOS42
Joe - MentorMarket
Rhett - EOS Amsterdam
Sam - Everipedia
