[ADR] 0003 - Adopt Libp2p PeerIDs

[bryanchriswhite]

Summary

This pull request adds an Architecture Decision Record (ADR) for adopting Libp2p identity/IDs to simplify and consolidate node identity in our system. The ADR explains the context, problem statement, decision drivers, considered options, and the decision outcome, along with the positive and negative consequences of the chosen option.

The chosen option is to adopt Libp2p identity/IDs, as it provides a unique, verifiable, and secure identification system that is proven in the peer-to-peer ecosystem.

Please review the ADR and provide feedback on:

• The clarity of the problem statement and context
• The thoroughness of the decision drivers and considered options
• The appropriateness of the chosen option given the decision drivers
• Any additional considerations that may have been overlooked
• Any changes in formatting, grammar, or language for better readability

Related Issues

• [P2P][LibP2P][SPIKE] Consolidate and Refactor Node Identity pocket#348
• [TECHDEBT][Consensus] Review Hotstuff Node IDs pocket#434

[Olshansk]

All of this makes sense to me and I approve.

My only question as a reader (which may be outside the scope of this ADR) is what a LibP2P PeerId ends up looking like

[bryanchriswhite]

All of this makes sense to me and I approve.

My only question as a reader (which may be outside the scope of this ADR) is what a LibP2P PeerId ends up looking like

@Olshansk, I think this is related to https://github.com/pokt-network/pocket-network-protocol/pull/32/files#r1199028895.

These are supposed to be living documents and we have yet to update one. Wdyt about merging this as is and updating it with some examples / practical application, once we've decided what that looks like and updated the template once more?

[Olshansk]

No

[Olshansk]

Do you think it's worth mentioning that this ADR builds on top of #32 to adopt multiaddr and LibP2PPeerIDs use multiaddr underneath?

[Olshansk]

Is it worth saying "A custom wrapper" around multiaddr?

[bryanchriswhite]

Multiaddr is orthogonal to peer IDs. It's used represent the network address of a node for the purpose of establishing a network transport connection. A peer ID can be encapsulated in a multiaddr to encode identity information in addition to the network address, for the convenience of the consumer. However, this ADR is coming from a different, more peer-ID-centric, perspective where multiaddr isn't specifically relevant.

Examples of "custom identity scheme"s would be something like what we talked about in the decentralized identity protocol hour. Ranging from something simple, like a self-signed public key (key plus signature) or something more sophisticated, like an X509 certificate chain (self-signed or otherwise). Perhaps these examples could be added using the structure you suggested (#32 (comment))?

[Olshansk]

Fwiw, I was thinking of throwing a 🔧 into the mix after reading #32 right before this (which I fully support) and start hesitating a bit about this one. Going through these positive consequences convinced me otherwise.

With that said, calling adopt that doing this manually, even if we adopt LibP2P multiaddr, would be a non-trivial amount of work that does not enable anything Pocket might need in the future.

[bryanchriswhite]

I'm not quite sure I followed the second part, can you say more?

[Olshansk]

I had some typos so understand why you were confused...

Going to consolidate this with your comment in https://github.com/pokt-network/pocket-network-protocol/pull/34/files#r1206682770.

---

You said that a A peer ID can be encapsulated in a multiaddr but I think of it as a A single peer ID can map to multiple multiaddr since a multiaddr is lower on the network stack and used for network communication rather than authenticating/authorizing another networking peer.

As such, adopting multiaddr feels like a very easy decision for me to make, but adopting libp2p for peer IDs comes with more hurdles. We can easily build Pocket identity wrappers around multiaddr, but adopting PeerID from libp2p natively may give us less optionality in the future.

My argument is that "Because we have decided to adopt multiaddr, and libp2p PeerID incorporated multiaddr natively, this will reduce the workload and maintenance on Pocket's side.`

---

Does that make more sense in terms of:

1. My concerns
2. The arguments we need to consider to adopt/withdraw this?

[Olshansk]

I had some typos so understand why you were confused...

Going to consolidate this with your comment in https://github.com/pokt-network/pocket-network-protocol/pull/34/files#r1206682770.

---

You said that a A peer ID can be encapsulated in a multiaddr but I think of it as a A single peer ID can map to multiple multiaddr since a multiaddr is lower on the network stack and used for network communication rather than authenticating/authorizing another networking peer.

As such, adopting multiaddr feels like a very easy decision for me to make, but adopting libp2p for peer IDs comes with more hurdles. We can easily build Pocket identity wrappers around multiaddr, but adopting PeerID from libp2p natively may give us less optionality in the future.

My argument is that "Because we have decided to adopt multiaddr, and libp2p PeerID incorporated multiaddr natively, this will reduce the workload and maintenance on Pocket's side.`

---

Does that make more sense in terms of:

1. My concerns
2. The arguments we need to consider to adopt/withdraw this?