algorand / algorand/go-algorand
Implementing libp2p: peer ID and a peer store for Algorand nodes
- 主要言語
- Go
- スター
- 1.4k
- フォーク
- 537
- 平均マージ
- 1日 6時間
- マージ済み PR(30日)
- 17
説明
## Problems and Background
- In a P2P world, participants should know and be able to identify and recognize trusted peers.
- Bootstrap nodes: an initial set of designated nodes (like on Ethereum, where they're in a file on github)
- people using certain vendors (e.g. algonode, purestake) to propagate their traffic need to be recognized by the vendor and vice-versa
- When a node has downtime, it should remember its peers so that it can reconnect to them
- If we wanted to introduce rate-limiting, we would not want the rate-limiting to apply to relay-to-relay traffic. Thus, relays need to be able to recognize each other.
To solve these problems, each node needs to have a persistent and provable ID, to eliminate the possibility for impersonation. In our current implementation, typical nodes have an ephemeral public key (not persistent).
In our current system, most nodes only connect to relay nodes, which are listed in the DNS SRV record. The SRV record is centrally controlled to avoid impersonation. This centralization requirement is one we want to remove.
In libp2p, each peer controls a private key and share the corresponding Peer ID (hash of the public key) to their peers. See [here](https://docs.libp2p.io/concepts/fundamentals/peers/) for more info.
## Solution
In this epic, we will implement libp2p's Peer ID and a Peer Store.
- each node knows its own Peer ID and remembers it after it goes down/up.
- A DNS record includes the Peer ID for every boot node.
- each node stores the Peer IDs of the peers it's connected to, such that if it goes offline it can reconnect to that set.
_Out of Scope:_
- Peer Discovery: the Peer ID is communicated across the gossipSub protocol. This happens "for free" with libp2p.
### Questions
When does the private key get used to prove who you are? - probably out of scope, we'll get this from libp2p "for free". And if we decide to adapt it for the legacy network system, we'll do that as a followup.
### Peerstore implementation notes
There is a default memory-backed peerstoremem, and also a disk-backed peerstore implementation in https://pkg.go.dev/github.com/libp2p/go-libp2p@v0.28.1/p2p/host/peerstore/pstoreds
If we like it, we can integrate it into our configuration & phonebook system
We could alternatively write our own custom peerstore implementation that conforms to this interface https://pkg.go.dev/github.com/libp2p/go-libp2p@v0.28.1/core/peerstore#Peerstore
## Notes
Related Trusted Peers https://github.com/prysmaticlabs/prysm/pull/12492
https://github.com/libp2p/specs/blob/master/addressing/README.md#dnsaddr-links
https://github.com/multiformats/multiaddr/blob/master/protocols/DNSADDR.md
Here is where the current network uses phonebook and knowledge about currently-connected nodes to return lists of nodes to callers, similar to a peerstore https://github.com/algorand/go-algorand/blob/master/network/wsNetwork.go#L191-L192
Connection deduplication https://github.com/algorand/go-algorand/pull/4695
downstream work to consider:
- the SRV tooling
- SRV deduplication... is the public key good for deduplicating?
- private networks. Do we add this feature to them?
- configuration documentation
- run algonet w/ these
A for-service node runner (e.g. Algonode) would probably want to set this up right away to send traffic to customers no matter what - need to be able to recognize their customers. (external trust relationship in complement to all being libp2p-based reputation)
do we need to think through how to rotate your keys (if your private key got comprised, what do you do?)?
コントリビューションガイド
評価
この issue はまだ評価されていません。