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

Add ValidatorPubkeyTypes as a consensus param #2636

Merged
merged 10 commits into from
Oct 30, 2018

Conversation

ValarDragon
Copy link
Contributor

@ValarDragon ValarDragon commented Oct 14, 2018

Ref #2414

  • Updated all relevant documentation in docs - updated all I'm aware of.
  • Updated all code comments where relevant
  • Wrote tests
  • Updated CHANGELOG_PENDING.md

@codecov-io
Copy link

codecov-io commented Oct 14, 2018

Codecov Report

Merging #2636 into develop will decrease coverage by 0.18%.
The diff coverage is 60%.

@@             Coverage Diff             @@
##           develop    #2636      +/-   ##
===========================================
- Coverage    61.72%   61.54%   -0.19%     
===========================================
  Files          207      207              
  Lines        16942    16939       -3     
===========================================
- Hits         10458    10425      -33     
- Misses        5622     5649      +27     
- Partials       862      865       +3
Impacted Files Coverage Δ
evidence/pool.go 56.14% <0%> (ø) ⬆️
state/store.go 70.07% <0%> (ø) ⬆️
evidence/reactor.go 65.93% <100%> (ø) ⬆️
state/execution.go 75.67% <100%> (ø) ⬆️
state/validation.go 65.62% <100%> (ø) ⬆️
consensus/state.go 76.17% <0%> (-2.82%) ⬇️
consensus/reactor.go 70.96% <0%> (-1.04%) ⬇️
tools/tm-monitor/monitor/network.go 88.5% <0%> (-0.75%) ⬇️
node/node.go 65.24% <0%> (-0.31%) ⬇️
p2p/node_info.go 89.23% <0%> (ø) ⬆️
... and 2 more

@ValarDragon
Copy link
Contributor Author

Should ValidatorPubkeyTypes instead be PubkeyTypes as a sub-component of ValidatorParams?

Copy link
Contributor

@melekes melekes left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🍰 🌮 🍉

types/params.go Outdated
@@ -77,6 +86,10 @@ func (params *ConsensusParams) Validate() error {
params.EvidenceParams.MaxAge)
}

if len(params.ValidatorPubkeyTypes) == 0 {
return cmn.NewError("len(ValidatorPubkeyTypes) must be greater than 0.")
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

no . at the end please

Copy link
Contributor

@ebuchman ebuchman left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So this is just to add it to the ConsensusParams. Enforcement will come in a second PR? Or do you want to add that here.

types/params.go Outdated
@@ -17,8 +18,9 @@ const (
// ConsensusParams contains consensus critical parameters that determine the
// validity of blocks.
type ConsensusParams struct {
BlockSize `json:"block_size_params"`
EvidenceParams `json:"evidence_params"`
BlockSize `json:"block_size_params"`
Copy link
Contributor

@ebuchman ebuchman Oct 16, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thinking about this, we can probably drop the Params and _params suffixes from these fields.

Also I wonder if the ConsensusParams is a good place for Version to live? Then we don't need to add anything to EndBlock for the app to update the versions, its just part of the ConsensusParams.

As for this PR, maybe we should have a new struct to hold the pubkey types? Could be called Signatures or Cryptography or Validators or something ?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This makes a lot of sense for app version imo.

Re new struct, sure I think Validators makes sense! I do think having the params suffix is nice for disambiguation when your looking at types.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Cool. Let's go with Validators.

Yeh, Params makes sense for the types, but it's redundant for the field names. I guess here it's all embedded structs, but maybe it shouldn't be, and then we can have proper field names and struct type name distinctions.

types/params.go Outdated
@@ -55,6 +58,12 @@ func DefaultEvidenceParams() EvidenceParams {
}
}

// DefaultValidatorPubkeyTypes Params returns a default set of pubkey types to
// be accepted for validators.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Comment should tell us what the default is

types/params.go Outdated
@@ -106,5 +140,8 @@ func (params ConsensusParams) Update(params2 *abci.ConsensusParams) ConsensusPar
if params2.EvidenceParams != nil {
res.EvidenceParams.MaxAge = params2.EvidenceParams.MaxAge
}
if params2.ValidatorPubkeyTypes != nil {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Works for structs but not sure if we might just end up with a non-nil empty list here?

@ValarDragon
Copy link
Contributor Author

My plan was to add enforcement in a second PR. (Primarily because I was unsure what function should be aware of the consensus params when getting the validator set updates)

@ValarDragon
Copy link
Contributor Author

Is this good to merge? I'd like to get it in soon before we make another .proto change and I have to fix the merge conflict

Copy link
Contributor

@ebuchman ebuchman left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure if we want to use the Amino routes here. Technically ABCI knows nothing about amino routes, and the pubkey types just have two string types now, "ed25519" and "secp256k1". We should be consistent here - either we add the amino routes to the base pubkey types, or we use the simple names in the validator pubkey types...

Otherwise, this looks great. Thanks Dev.

types/params.go Outdated
@@ -77,6 +90,10 @@ func (params *ConsensusParams) Validate() error {
params.EvidenceParams.MaxAge)
}

if len(params.Validator.ValidatorPubkeyTypes) == 0 {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we also validate that the types given are known?

types/params.go Outdated
@@ -94,6 +111,27 @@ func (params *ConsensusParams) Hash() []byte {
return hasher.Sum(nil)
}

func (params *ConsensusParams) Equals(params2 *ConsensusParams) bool {
if params.BlockSize == params2.BlockSize &&
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We can just return this conjunction instead of using the conditional

@ValarDragon
Copy link
Contributor Author

ValarDragon commented Oct 25, 2018

I'm not sure if we want to use the Amino routes here. Technically ABCI knows nothing about amino routes, and the pubkey types just have two string types now,

I'll change it here, but I don't really get why ABCI wouldn't just use the amino routes / why we don't make the amino routes match whats used in ABCI. (I actually think the amino routes should be whats currently used in ABCI. The tendermint prefix in amino routes will unnecessarily break compatibility with other potential consensus algorithms or make other consensus algorithms crypto more confusing)
I extracted this to a separate issue.

@ValarDragon ValarDragon force-pushed the dev/add_validator_pubkey_type_consensus_param branch from 96b7d2c to 241bf3d Compare October 27, 2018 04:01
@ebuchman
Copy link
Contributor

The redundant field names components (#2698) were driving me nuts so I fixed it :P

Copy link
Contributor

@melekes melekes left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🍐

@@ -24,6 +24,12 @@ const (
ABCIPubKeyTypeSecp256k1 = "secp256k1"
)

// TODO: Make non-global by allowing for registration of more pubkey types
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

is there an associated issue?

stringSliceEqual(params.Validator.PubKeyTypes, params2.Validator.PubKeyTypes)
}

func stringSliceEqual(a, b []string) bool {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

move to cmn#string.go?

res.Evidence.MaxAge = params2.Evidence.MaxAge
}
if params2.Validator != nil {
res.Validator.PubKeyTypes = params2.Validator.PubKeyTypes
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we copy here?

Also I wonder if it makes sense to use Amino naming in the types#ConsensusParams but ABCI naming in the abci#ConsensusParams. Is that crazy? Or maybe we put an empty PubKey of the respective type in the types#ConsensusParams instead of strings.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good idea, it probably is best to copy.

@ebuchman ebuchman merged commit 56d7160 into develop Oct 30, 2018
ValarDragon added a commit that referenced this pull request Nov 1, 2018
@ebuchman ebuchman deleted the dev/add_validator_pubkey_type_consensus_param branch November 7, 2018 06:51
ebuchman pushed a commit that referenced this pull request Nov 28, 2018
* Enforce validators can only use the correct pubkey type

* adapt to variable renames

* Address comments from #2636

* separate updating and validation logic

* update spec

* Add test case for TestStringSliceEqual, clarify slice copying code

* Address @ebuchman's comments

* Split up testing validator update execution, and its validation
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants