search

EntEthAlliance / enhanced-bft

a workspace for developing improvements to BFT consensus
Other
8 stars 3 forks source link

Permissioning for block creation #15

Open saltiniroberto opened 5 years ago

saltiniroberto commented 5 years ago

Validator set is defined here as the list of nodes that can propose a new block and participate in the consensus protocol.

Nodes that are not included in the validator set are not allowed to propose new blocks and participate in the consensus protocol.

All honest nodes must agree on the validator set for all blockchain heights.

The *BFT Consensus Protocol must allow for a mechanism for adding or removing validators to/from the set of authorised validators.

drequinox commented 5 years ago

OK, but we need to clarify “All honest nodes must agree on the validator set for all blockchain heights.”, what does this mean in practical terms? Does this mean that no block is finalised until it has enough validator seals, or does it mean from the voting point of view that all validators remain consistent of their view of correct validator set, please clarify. Note that we also need to keep the permissioning model separate from the consensus model.

saltiniroberto commented 5 years ago

What I mean by this assumption is that if node n1 is asked about the validator list for height h and node n2 is queried about the list validator list for the same height h, then node n1 and n2 must return the same answer.

kubasiemion commented 5 years ago

The issue's title is misleading. This should be something like "Dynamic quorum" requirement.

kubasiemion commented 4 years ago

Could we take THIS as the requirement: What I mean by this assumption is that if node n1 is asked about the validator list for height h and node n2 is queried about the list validator list for the same height h, then node n1 and n2 must return the same answer. ? And change the title to something like "Validator set consistency" requirement?

drequinox commented 4 years ago

agree with @kubasiemion, "Validator set consistency" seems more logical, but I would argue that this property is not a core requirement for achieving consensus, however, it can be considered a general integrity property for the blockchain "validator management sub-protocol".

chaals commented 4 years ago

Resolved in meeting 2020-05-27 to keep this open, and label to be tested in impementation