Skip to content

[ADR] 0003 - Adopt Libp2p PeerIDs #34

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.

Sign up for GitHub

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

Open
bryanchriswhite wants to merge 7 commits into
base: main
Choose a base branch
from
Open

[ADR] 0003 - Adopt Libp2p PeerIDs #34

Changes from all commits
Commits
Show all changes
7 commits
Select commit Hold shift + click to select a range
0fb0f07
docs: add ADR0003
bryanchriswhite Apr 14, 2023
1a8845f
ADR0003: status "in review"
bryanchriswhite Apr 21, 2023
6243373
refactor: reformat using udpated template (#40)
bryanchriswhite Apr 28, 2023
78b8dd3
refactor: summary & problem statement
bryanchriswhite Apr 28, 2023
d8ffa07
fix: copy/pasta
bryanchriswhite Apr 28, 2023
ce91113
chore: replace "technical story" section with "background"
bryanchriswhite May 19, 2023
a238734
chore: remove comments
bryanchriswhite May 19, 2023
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
98 changes: 98 additions & 0 deletions ADRs/0003-adopt-libp2p-peer-ids.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,98 @@
# Adopting Libp2p PeerIDs <!-- omit in toc -->

- Status: in review
- Deciders: Pocket Network team
- Date: 2023-04-14

**Table of Contents**

- [Summary](#summary-)
- [Problem Statement](#problem-statement-)
- [Background](#background-)
- [Decision Drivers](#decision-drivers-)
- [Considered Options](#considered-options-)
- [Decision Outcome](#decision-outcome-)
- [Positive Consequences](#positive-consequences-)
- [Negative Consequences](#negative-consequences-)
- [Pros and Cons of the Options](#pros-and-cons-of-the-options-)
- [Adopting Libp2p identity/IDs](#adopting-libp2p-identityids)
- [Custom identity scheme](#custom-identity-scheme)
- [References](#references-)

## Summary

Facing the need for a unique and verifiable identifier for nodes in the peer-to-peer network, we decided to adopt Libp2p identity/IDs and neglect alternative identity schemes, to achieve a reliable and secure identification system, accepting the additional dependency and integration work, because Libp2p provides a proven solution with robust security features.

## Problem Statement
Copy link
Copy Markdown
Collaborator

@Olshansk Olshansk May 20, 2023

Choose a reason for hiding this comment

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

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


At the time of writing, there is no formal specification for identity with respect to pocket network nodes/participants.
Each node MUST be uniquely identifiable/addressable so that it may be correctly routed to.
Identities MUST be provable (e.g. via cryptographic signature).

### Context

- We've recently refactored the P2P module to use libp2p for the transport layer. As a result we're already interoperating with libp2p objects and types.
- We're simultaneously exploring consolidating and simplifying the concept of node identity throughout the codebase wherever reasonable/feasible.

## Background

[Consolidate and Refactor Node Identity - #348](https://github.com/pokt-network/pocket/issue/348)

## Decision Drivers

- Unique and verifiable node identifiers
- Secure and reliable identification system
- Proven solution in the peer-to-peer ecosystem

## Considered Options

1. Adopting Libp2p identity/IDs
2. Custom identity scheme
Copy link
Copy Markdown
Collaborator

@Olshansk Olshansk May 20, 2023

Choose a reason for hiding this comment

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

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

Copy link
Copy Markdown
Contributor Author

@bryanchriswhite bryanchriswhite May 26, 2023

Choose a reason for hiding this comment

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

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))?


## Decision Outcome

Chosen option: "Adopting Libp2p identity/IDs", because it provides a unique, verifiable, and secure identification system that is proven in the peer-to-peer ecosystem.

### Positive Consequences
Copy link
Copy Markdown
Collaborator

@Olshansk Olshansk May 20, 2023

Choose a reason for hiding this comment

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

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.

Copy link
Copy Markdown
Contributor Author

@bryanchriswhite bryanchriswhite May 26, 2023

Choose a reason for hiding this comment

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

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

Copy link
Copy Markdown
Collaborator

@Olshansk Olshansk May 30, 2023

Choose a reason for hiding this comment

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

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?


- Unique and verifiable node identifiers
- Secure and reliable identification system
- Simplified integration with other Libp2p components

### Negative Consequences

- Additional dependency on the Libp2p library
- Integration work required to adopt Libp2p identity/IDs

## Pros and Cons of the Options

### Adopting Libp2p identity/IDs

Pros:

- Provides unique and verifiable node identifiers
- Offers a secure and reliable identification system
- Proven solution in the peer-to-peer ecosystem
- Aligns with the refactored P2P module, which already uses libp2p for the transport layer

Cons:

- Introduces an additional dependency
- Requires integration work to adopt Libp2p identity/IDs

### Custom identity scheme

Pros:

- Doesn't require an additional dependency

Cons:

- May lead to a less secure and reliable solution
- Requires development and maintenance efforts
- May not be compatible with other Libp2p components or the refactored P2P module

## References

- [`go-libp2p` - `peer.ID`](https://pkg.go.dev/github.com/libp2p/go-libp2p@v0.27.1/core/peer#ID)
- [pokt-network/pocket#434](https://github.com/pokt-network/pocket/issue/434)