Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Permissioning for block creation #15

Open
saltiniroberto opened this issue Jun 19, 2019 · 6 comments
Open

Permissioning for block creation #15

saltiniroberto opened this issue Jun 19, 2019 · 6 comments
Labels
to test in implementations Requirements that we need to demonstrate succeed in real implementations TODO after implementation Issue deemed relevant, but to be taken care of after the interop bft protocol

Comments

@saltiniroberto
Copy link
Contributor

saltiniroberto commented Jun 19, 2019

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.

@saltiniroberto saltiniroberto changed the title Dynamic Validator Set Validator Set Jun 19, 2019
@saltiniroberto saltiniroberto changed the title Validator Set Permissioning for block creation Jun 19, 2019
@drequinox
Copy link

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
Copy link
Contributor Author

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
Copy link
Contributor

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

@kubasiemion
Copy link
Contributor

kubasiemion commented Oct 30, 2019

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
Copy link

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 chaals added the to test in implementations Requirements that we need to demonstrate succeed in real implementations label May 27, 2020
@chaals
Copy link
Contributor

chaals commented May 27, 2020

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

@kubasiemion kubasiemion added the TODO after implementation Issue deemed relevant, but to be taken care of after the interop bft protocol label Jun 8, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
to test in implementations Requirements that we need to demonstrate succeed in real implementations TODO after implementation Issue deemed relevant, but to be taken care of after the interop bft protocol
Projects
None yet
Development

No branches or pull requests

4 participants