gossipsub v1.1: Security extensions to improve on attack resilience and bootstrapping about js-libp2p-gossipsub HOT 6 CLOSED

Thanks for bringing this up!
We'll be needing v1.1 for our purposes sooner rather than not. ethereum/consensus-specs#1792

We can start the implementation initiative in the next few weeks.
Do you see any potential blockers for implementing this? Should we wait for libp2p 0.28 for the refactored peer store?

from js-libp2p-gossipsub.

We foresee libp2p to provide the node's signed addresses via its API (it would be cached interally and updated when the addresses change).

So, I would say for you to not worry about that. Me or Jacob can work on that, and then we integrate this in gossipsub as a follow up PR. It should be straightforward. However, if you want to get it in js-libp2p as well, I would not say no 😆 But let's focus first on updating everything here, and than we can just call this API method

from js-libp2p-gossipsub.

taking notes on https://github.com/libp2p/specs/blob/master/pubsub/gossipsub/gossipsub-v1.1.md for my own organization
see also: libp2p/go-libp2p-pubsub#263

• explicit peer agreements:
  • list of peers, similar to bootnodes
  • connect on router boot, periodic reconnect check
  • forward all messages to them (peer agreements are not per-topic)
  • do not graft, do not accept graft, respond with prune
• peer exchange (PX) on prune
  • ensure pruned peers do not regraft, maintain an entry for a backoff period
  • regrafting violations result in pruning and backoff period extension
  • prune control message optionally includes "peer infos" of other peers in the topic
  • "peer infos" include peer id and (optionally during transitional phase) signed peer record (fetched via libp2p api)
  • if pruned, attempt to reform full mesh by connecting to peer infos we receive, if peer score is above acceptPXThreshold
• flood publishing
  • optional feature, should be configurable (defaulted on?)
  • publish all own messages to all peers above publish threshold
  • peers must be above publishThreshold
• adaptive gossip dissemination
  • send gossip to random max((peers above gossip threshold) * gossip factor), D_lazy) peers
  • gossiped peers must have score above gossipThreshold
• peer scoring
  • configurable thresholds (gossipThreshold, publishThreshold, graylistThreshold, acceptPXThreshold, opportunisticGraftThreshold)
  • maintain score for each peer
  • one score per peer, 6 parameters feed the score, 4 parameters are per-topic, 2 are global
  • score maintained for some time after a peer disconnects
• heartbeat maintenance
  • peers with negative scores get pruned from all meshes
  • when pruning bc of oversubscription, sort peers by score to prune lowest scoring peers first, randomly pick in case of tie
  • when grafting bc of undersubscription, filter out negative scored peers
• opportunistic grafting
  • periodically check for median score of peers in mesh (per topic?)
  • if score is below opportunisticGraftThreshold, graft two peers above the score to graft
• extended validators
  • validator function must support at minimum 3 outputs: accept, reject, ignore
• Topic Parameter Calculation and Decay
  • configurable decay interval, param-specific decay factor
• each score param
  • read spec
• new configurable params
  • see spec for list
• spam protection measures
  • graft from unknown topics are ignored, no prune returned
  • track iwants responded to by peer, limit to certain number, drop after threshold reached

from js-libp2p-gossipsub.

I was thinking about that last week, but I think that only the gossipsub protocol here needs to be updated. We aim to get the [email protected] release candidate soon, but this can be a parallel effort, since we will not need to do any release for it. We just need to guarantee that [email protected] comes in earlier because the update here will come with no PeerInfo.

Anyway, let me know here when you start working on it, so that we get aligned and I can unblock you with anything that is needed :)

from js-libp2p-gossipsub.

Ok, thanks for the info, I had forgotten that we are already ready to go for 0.28 here.
I've read through the specs and some supplemental docs. Planning on setting aside time late this week as well as next week to start a branch.

One question I have is around the signed envelopes and peer routing records described here libp2p/specs#217
How do you see those standards implemented for js-libp2p? Will these live in separate repos, to be (re)used here and elsewhere?

from js-libp2p-gossipsub.

🎉

from js-libp2p-gossipsub.