This repository has been archived by the owner on Feb 23, 2022. It is now read-only.
Expose proposer selection over ABCI with new field in ResponseEndBlock #193
Labels
C:abci
Component: ABCI
C:consensus
Component: Consensus
S:proposal
Status: Proposal
T:enhancement
Type: Enhancement
We have recently done a lot of work on getting the proposer selection algorithm right in tendermint. See for instance tendermint/tendermint#3049, tendermint/tendermint#3140, tendermint/tendermint#3222. There are still some open issues and a new
proposer-selection
label to tag them, but it seems we've addressed most of the concerns and have settled on a reasonably fair algorithm that can handle large validator set changes. Great work team!One thing we have discussed is exposing the proposer selection to the applications. Currently, the only control apps have is to change the validator set, but otherwise all selection is left to Tendermint.
We should consider adding a new field to ResponseEndBlock which gives applications more control over proposer selection. This could be a list of {PubKey, Priority}, for instance, that would otherwise use the same Tendermint algorithm, but where the app specifies with every block who can be a proposer for the next block and what their respective initial priorities are.
This will need more design work and an ADR, and we need to specify when and how the default behaviour kicks in. But otherwise could be quite valuable to applications, and would for instance allow them to implement randomness in their proposer selection before we do it in Tendermint (#763), and would allow for proposers who aren't even in the validator set, which might be useful for certain configurations.
The text was updated successfully, but these errors were encountered: