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 upstream version of multihash instead of a fork #1472

Merged
merged 1 commit into from
Mar 5, 2020

Conversation

vmx
Copy link
Contributor

@vmx vmx commented Feb 26, 2020

The changes from the libp2p fork have been backported to upstream, hence
upstream can now be used instead.

@vmx vmx requested review from twittner and tomaka February 26, 2020 16:53
@vmx vmx force-pushed the multihash-upstream branch 2 times, most recently from 88033dd to ebfbfa7 Compare February 26, 2020 19:13
Copy link
Member

@tomaka tomaka left a comment

Choose a reason for hiding this comment

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

Looks good to me, but I'd like to run this against a live network to see if there's nothing wrong with the upstream crate.

@vmx
Copy link
Contributor Author

vmx commented Mar 2, 2020

Is there anything I can help with running it against a live system or is this something the Rust libp2p team will take care of?

@tomaka
Copy link
Member

tomaka commented Mar 2, 2020

Is there anything I can help with running it against a live system or is this something the Rust libp2p team will take care of?

If you're motivated, my idea was to run Polkadot with a local override to this PR, and see if nothing suspicious happens.
It might be difficult to define "suspicious" if you've never used Polkadot before, but no errors printed on stdout/stderr and 25 peers is what I'd look for.

The most difficult part is waiting for the compilation to finish.

@vmx
Copy link
Contributor Author

vmx commented Mar 2, 2020

Can I opt-out again :) I thought there might be something automated, you'd need to ping people for. I've never used Polkadot, so I guess that isn't a good task for me as I really can't tell if there's anything suspicious.

@tomaka
Copy link
Member

tomaka commented Mar 3, 2020

Looks like it's working.

For note-keeping, here's the small patch to apply to Substrate:

diff --git a/client/authority-discovery/src/lib.rs b/client/authority-discovery/src/lib.rs
index 6260ac9a8..ff88765cb 100644
--- a/client/authority-discovery/src/lib.rs
+++ b/client/authority-discovery/src/lib.rs
@@ -499,9 +499,8 @@ where
 }
 
 fn hash_authority_id(id: &[u8]) -> Result<libp2p::kad::record::Key> {
-	libp2p::multihash::encode(libp2p::multihash::Hash::SHA2256, id)
-		.map(|k| libp2p::kad::record::Key::new(&k))
-		.map_err(Error::HashingAuthorityId)
+	let digest = libp2p::multihash::Sha2_256::digest(id);
+	Ok(libp2p::kad::record::Key::new(&digest))
 }
 
 fn interval_at(start: Instant, duration: Duration) -> Interval {

Copy link
Contributor

@twittner twittner left a comment

Choose a reason for hiding this comment

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

👍

//};

let canonical = canonical_algorithm.map(|alg|
multihash::encode(alg, &key_enc).expect("SHA2256 is always supported"));
alg.hasher().expect("canonical hasher exists").digest(&key_enc));
Copy link
Contributor

Choose a reason for hiding this comment

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

I would suggest to keep mentioning "SHA2-256". It is more informative than "canonical".

Copy link
Contributor Author

Choose a reason for hiding this comment

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

If the canonical hasher is always sha2-256, should perhaps then the variable also be renamed?

Copy link
Contributor

Choose a reason for hiding this comment

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

"canonical" as a variable name sounds good to me so I would leave it as is. After all SHA2-256 is our canonical hash algorithm.


let multihash = multihash::encode(hash_algorithm, &key_enc)
.expect("identity and sha2-256 are always supported by known public key types");
let multihash = hash_algorithm.hasher().expect("hasher exists").digest(&key_enc);
Copy link
Contributor Author

Choose a reason for hiding this comment

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

@twittner should I also change this message back to "identity and sha2-256 are always supported by known public key types"?

Copy link
Contributor

Choose a reason for hiding this comment

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

I would go with "identity and sha2-256 are always supported".

The changes from the libp2p fork have been backported to upstream, hence
upstream can now be used instead.
@vmx
Copy link
Contributor Author

vmx commented Mar 4, 2020

I have just rebased an changed the error messages in c976930#diff-d21ea1befb9128247a52e731c8fd3256R79-R83 as suggested by the code review. There were no other changes.

@vmx
Copy link
Contributor Author

vmx commented Mar 4, 2020

The integration test also fails for me locally on master.

Update: locally on master it was a different error. I'm trying again to reproduce it.

@vmx
Copy link
Contributor Author

vmx commented Mar 4, 2020

I've no idea what the problem is, the integration test works locally.

@tomaka
Copy link
Member

tomaka commented Mar 5, 2020

The integration test failure is obviously not caused by this PR, and we also had it in the other PR.
Let's merge and open an issue.

@tomaka tomaka merged commit 10089c5 into master Mar 5, 2020
@tomaka tomaka deleted the multihash-upstream branch March 5, 2020 15:49
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