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

Use ValidatorPublicKey instead of ValidatorName #3372

Merged
merged 8 commits into from
Feb 20, 2025

Conversation

deuszx
Copy link
Contributor

@deuszx deuszx commented Feb 19, 2025

Motivation

Currently we're using ValidatorName (a newtype wrapper around ValidatorPublicKey) in many places where it's not making any quality improvements. I'd argue that it's:

  • unnecessary (it's just a wrapper around our own struct)
  • confusing (we have ValidatorName and, next to it, ValidatorSignature that we verify with validator_name.public_key )
  • might clash (in the future) with "nicknames" - i.e. onchain human-readable aliases that validators may decide to register

Proposal

Replace usage of ValidatorName with ValidatorPublicKey. Also rename field names from name to public_key - this affects the RPC format and CLI.

Test Plan

CI should catch any regressions.

Release Plan

  • Nothing to do / These changes follow the usual release cycle.

Links

@deuszx deuszx force-pushed the refactor-use-pk-instead-of-owner branch from 2061f04 to c858a43 Compare February 19, 2025 14:46
@deuszx deuszx requested review from afck, ma2bd and bart-linera and removed request for afck February 19, 2025 14:57
@deuszx deuszx force-pushed the refactor-use-pk-instead-of-owner branch from c858a43 to 7471c40 Compare February 19, 2025 15:05
@deuszx deuszx marked this pull request as ready for review February 19, 2025 15:56
@deuszx deuszx force-pushed the refactor-use-pk-instead-of-owner branch from 1c45355 to 7bcec3b Compare February 19, 2025 16:53
@deuszx deuszx force-pushed the refactor-use-pk-instead-of-owner branch from 7bcec3b to b3e6534 Compare February 19, 2025 16:54
@deuszx deuszx force-pushed the refactor-use-pk-instead-of-owner branch 3 times, most recently from 07d9ca9 to 3c76e1e Compare February 20, 2025 00:21
@deuszx deuszx force-pushed the refactor-use-pk-instead-of-owner branch from 3c76e1e to 9293417 Compare February 20, 2025 00:34
@@ -330,7 +330,7 @@ impl Ed25519Signature {
pub fn verify_batch<'a, 'de, T, I>(value: &'a T, votes: I) -> Result<(), CryptoError>
where
T: BcsSignable<'de>,
I: IntoIterator<Item = (&'a Ed25519PublicKey, &'a Ed25519Signature)>,
Copy link
Contributor

Choose a reason for hiding this comment

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

Inside the ed25519 module I wouldn't use the alias.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yes, found that in the next PR. Will push here.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Actually, I'm gonna do that in the follow-up PRs to avoid waiting for the CI again.

@@ -916,7 +916,7 @@ pub(crate) fn check_signatures(
);
// All that is left is checking signatures!
let hash_and_round = VoteValue(value_hash, round, certificate_kind);
ValidatorSignature::verify_batch(&hash_and_round, signatures.iter().map(|(v, s)| (&v.0, s)))?;
ValidatorSignature::verify_batch(&hash_and_round, signatures.iter().map(|(v, s)| (v, s)))?;
Copy link
Contributor

Choose a reason for hiding this comment

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

Suggested change
ValidatorSignature::verify_batch(&hash_and_round, signatures.iter().map(|(v, s)| (v, s)))?;
ValidatorSignature::verify_batch(&hash_and_round, &signatures)?;

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 won't work. The argument type is an iterator over references - not a reference to something that can be turned into an iterator.

Copy link
Contributor

Choose a reason for hiding this comment

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

Maybe verify_batch should actually accept an IntoIterator.

And even if not, wouldn't signatures.iter() suffice? Is the .map(|(v, s)| (v, s)) really necessary?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

verify_batch already accepts IntoIterator.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Actually - it works 🤔 IDK why it didn't compile earlier.


let committee = Committee::make_simple(vec![name1, name2]);
let committee = Committee::make_simple(vec![validator1_pk, validator2_pk]);
Copy link
Contributor

Choose a reason for hiding this comment

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

No need to introduce those two, since below you use v1.public_key anyway instead of validator1_pk.

Suggested change
let committee = Committee::make_simple(vec![validator1_pk, validator2_pk]);
let committee = Committee::make_simple(vec![key1.public(), key2.public()]);

Copy link
Contributor

@afck afck left a comment

Choose a reason for hiding this comment

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

(No blockers from my side.)

@deuszx deuszx merged commit 840430a into main Feb 20, 2025
21 checks passed
@deuszx deuszx deleted the refactor-use-pk-instead-of-owner branch February 20, 2025 12:48
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.

3 participants