[Libp2p] Add libp2p module directories and helpers (part 1)

[bryanchriswhite]

Description

This is the first of a series of PRs split out from #500. Here we set up the new libp2p module directory structure and add crypto and identity / network helpers.

Issue

#347

Type of change

Please mark the relevant option(s):

• New feature, functionality or library
• Bug fix
• Code health or cleanup
• Major breaking change
• Documentation
• Other

List of changes

• prepare pocket repo new libp2p module
• add pocket / libp2p identity helpers
• add url <--> multiaddr conversion helpers for use with libp2p (see: https://github.com/multiformats/go-multiaddr)
• add pokt --> libp2p crypto helpers

Testing

• make develop_test
• LocalNet w/ all of the steps outlined in the README

Required Checklist

• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas
• I have tested my changes using the available tooling
• I have updated the corresponding CHANGELOG

If Applicable Checklist

• I have updated the corresponding README(s); local and/or global
• I have added tests that prove my fix is effective or that my feature works
• I have added, or updated, mermaid.js diagrams in the corresponding README(s)
• I have added, or updated, documentation and mermaid.js diagrams in shared/docs/* if I updated shared/*README(s)

[bryanchriswhite]

Changelog validation failure

I think this is a false positive caused by the changelog in question having no previous version (as it's new). To prove this locally:

1. Apply the following diff by copy/pasting to a new file (e.g. ./patch):

diff --git i/libp2p/docs/CHANGELOG.md w/libp2p/docs/CHANGELOG.md
index fc69f1ad..8b10fe54 100644
--- i/libp2p/docs/CHANGELOG.md
+++ w/libp2p/docs/CHANGELOG.md
@@ -5,11 +5,13 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0
 
 ## [Unreleased]
 
-## [0.0.0.0] - 2023-03-01
+## [0.0.0.1] - 2023-03-01
 
 - prepare pocket repo new libp2p module
 - add pocket / libp2p identity helpers
 - add url <--> multiaddr conversion helpers for use with libp2p (see: https://github.com/multiformats/go-multiaddr)
 - add `Multiaddr` field to `typesP2P.NetworkPeer`
 
+## [0.0.0.0] - 2023-03-01
+
 <!-- GITHUB_WIKI: changelog/libp2p -->

2. Run the changelog validation hook to ensure it passes: bash ./.githooks/pre-receive $(git diff --stat --name-only pokt/main..HEAD)

[Olshansk]

A few minor comments, but for the most part super clean and well compartmentalized as a separate PR. Appreciate making it easy for the reviewer

[Olshansk]

Where is this being used?

[bryanchriswhite]

This is called by zerolog and is required by the zerolog.LogArrayMarshaler interface, which is the type of the second argument to zerolog.Evt#Array.

I don't have a strong opinions on doing it this way, this just seemed to me like the most appropriate way to convey the information available via our structured logging. I've simplified as you suggested and added comments so nobody else has to ask the same question. 😅

[Olshansk]

@bryanchriswhite Going to take a look at this tomorrow, but I think it should be good to go after the next set of changes.

[okdas]

Thank you for leaving thorough comments in your code - that definitely helps me to understand what's going on! :)

[okdas]

Though having multiple A DNS records for the same hostname should not happen often in our case, I can see a scenario when nodes are provisioned behind a multi-zone LB, which is often a default for Kubernetes set up in clouds (I suppose they make more 🤑 that way).

Do you think there might be issues when the same node has a hostname that resolves to multiple IP addresses?

I assume PeerID has no correlation with Multiaddr. I suppose it should be fine if one PeerID has different addresses. Imagine a situation with multiple network interfaces, e.g. internet and local networks on one machine, both interfaces have different addresses in that case. But the same node can be exposed on both interfaces. In that case, (I assume) the PeerID stays the same, but other peers should be able to connect to it just fine even if IP addresses are different. Not sure if that makes sense, I'm just kind of fascinated by this topic and my guess is random address should work as long as packets flow correctly. :)

[okdas]

puts us in the driver seat

Do you mean something like we could sort the IP addresses and always use the first one so all nodes in the network predictably connect to the same IP even if there are multiple A DNS records?

[gitguardian]

⚠️ GitGuardian has uncovered 2 secrets following the scan of your pull request.

Please consider investigating the findings and remediating the incidents. Failure to do so may lead to compromising the associated services or software components.

🔎 Detected hardcoded secrets in your pull request

GitGuardian id	Secret	Commit	Filename
5841025	Generic High Entropy Secret	b694338	build/localnet/manifests/configs.yaml	View secret
5841025	Generic High Entropy Secret	b694338	build/config/genesis.json	View secret

🛠 Guidelines to remediate hardcoded secrets

1. Understand the implications of revoking this secret by investigating where it is used in your code.
2. Replace and store your secrets safely. Learn here the best practices.
3. Revoke and rotate these secrets.
4. If possible, rewrite git history. Rewriting git history is not a trivial act. You might completely break other contributing developers' workflow and you risk accidentally deleting legitimate data.

To avoid such incidents in the future consider

• following these best practices for managing and storing secrets including API keys and other credentials
• install secret detection on pre-commit to catch secret before it leaves your machine and ease remediation.

---

<sup>🦉 GitGuardian detects secrets in your source code to help developers and security teams secure the modern development process. You are seeing this because you or someone else with access to this repository has authorized GitGuardian to scan your pull request.

Our GitHub checks need improvements? Share your feedbacks!</sup>

[bryanchriswhite]

@Olshansk, @okdas thanks again for taking the time! 🙏

Apologies for changing things at the last minute, but as was surfaced in discussion with @okdas, we should be selecting a random record from the DNS response until we decide to support multiple IPs natively. As a result, There's a bit more code in getPeerIP than there was previously which collects the valid IPs before selecting one randomly.

I've added a test for the error case of getPeerIP where the resolution contained no records. I've also added a skipped test for the success cases of getPeerIP, skipped because to implement would require more time with net.Resolver and understanding how to get gomock to generate mocks for stdlib interfaces (e.g. net.Conn).

[okdas]

Thank you!

I am not 100% sure if you can merge the PR unless @Olshansk reviews again due to his prior review, maybe resolving all conversation can help? Otherwise, I should be able to bypass.

Feedback resolved

[Olshansk]

👍