Overview of Standby Block Producer Proposals
The following was transcribed from the April 1, 2019 EOS Town Hall by Stuart Tweedie (@stu_tweedie).
Kedar’s Thoughts on Standby BP Proposals (9:50)
The Chainrift solution can be implemented without a hard fork but the tradeoff for that is increasing schedule changes. We’re eventually going to have to develop IBC, which everyone has been avoiding. The Kyber network put out a proposal that works pretty well.
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.
Later on, if we want a different solution like a hard fork we can take votes out of the contract and it’ll disappear. If we want something permanent more work will be required to get block producers behind it. Block One has a hard fork scheduled for a few months from now. We’d probably have to modify the schedule somewhat but ideally, we would do this without modifying the schedule.
Currently, there are 21 producers that are in the schedule along with 21 signing keys. If the block comes from any of the valid signing keys then it is considered valid. We could keep the schedule as-is and rotate block producers in, but this is an ongoing area of research. We would likely to avoid having to add signing keys to the valid set.
The block producer multisig is set up so it’s 15/21. The way to handle multisig is to not change it at all. Any backup block producers that get voted in won’t have access to the 21st voting slot. If you’re in the top 21 you maintain voting rights that you get as being part of the top 21. Backup cycling in is just to make sure you’re prepared for production.
One overall issue of the rotating producers in the system is that block producers optimize latency between previous and next producers in production. If we’re having rotating producers coming in we’ll see a lot of dropped blocks between number 20 and 21 because none of the connections will be optimized.
It’s unrealistic to expect the producer behind the 21st slot to sync good latency connections with 20–30 backups. We have to make sure before implementing any of this that rotating producers isn’t going to lead to dropped blocks where we end up testing not necessarily production readiness of backup block producers, but latency connections with the final producer in the schedule.
