# GossipSub Audit Notes
#gossipsub

# Repositories in Question
https://github.com/LeastAuthority/go-libp2p-pubsub
https://github.com/LeastAuthority/libp2p-specs

*Flood publishing* - what is the nodes mesh?
With flood publishing, a node sends messages to all of the nodes it is connected to and not just the nodes in its mesh.

So node connections are not based on message subscriptions.

FloodPub is meant to mitigate against a situation where a node is connected to mostly or even all Sybil nodes.

*Question*: Is there a way to trick nodes into naive-flooding the network since it has `(O(n^2) message complexity)`

* What triggers a naive flood in the spec?

## Scoring system
I’m hesitant about this - reputation as a whole is a really difficult problem to solve and I’ve worked on those systems before.
* Tally system / zero sum scoring system
* Nodes with bad scores are remembered even if they drop off the network
* Nodes with positive scores are not remembered

## Behaviors / Claims
* 100% delivery rate is interesting property/claim

> Desirable behaviours include the uptime of a peer in a mesh and timely forwarding of messages to other peers.
* How are these verified? Are there proof of uptimes or something?
* Incentives need to be carefully considered and simulations will probably not catch all of the weird behavior real users do with regards to reputation scoring.

*Tipset* - same set of 5 latest blocks in a chain, the “tip” of the chain

# Time constraints
6 second hard limit for block propagation in the network. Longer than that and the network starts to run the risk of hard forking because nodes won’t be working on the same tipset.

# Network Degree
`D` is the variable assigned to the network degree in this report - or how many peers each node in the network should emit messages to.

> Nodes emit gossip messages to a number of peers proportional to the number of peers they are connected to. The proportion is set by a parameter called the gossip factor and is set to 0.25 by default.

# Eager propagation vs Lazy propagation
Eager message propagation happens through the mesh
* What is the mesh?

Lazy message propagation happens on pull model and it happens through gossip.

## Flood Issues with messages
`IWANT` requests are limited to up to 3 retransmissions / forwards - which is the same as the number of gossip rounds

*NB* Opportunistic grafting seems like a vector for possible attacks - this should be studied carefully

# Scoring System
* `DoPX` will be true if score of 0

## Peer Exchange - PX attack
> gaming peer churn to induce a sybil attack

number of peers to include in prune Peer eXchange
`GossipSubPrunePeers = 16`

* Mesh maintenance happens in `gossipsub.go`
* Nodes score other nodes on a per topic basis

### Testing in simulation
* We want peers to behave honestly, and then randomly be bad to get pruned.
* The trick is that we induce higher churn than a node would naturally be exposed to against network factors (e.g. partitions, dropped connections, etc…)
* During higher churn we only recommend our own sybil peers. Although we can’t choose who they pick recommendations from, if they ever ask us, we can only recommend our own Sybil peers.
* For each peer they get from us, our chances of being able to sybil them go up.
* The difficult part of this attack is that they have to ask us for peers, so how do we get them to ask our sybil nodes for peers more often than not?
* This basically becomes "spreading seeds and seeing what grows” as the attack would rely on some degree on random GRAFT/PRUNE messages from other nodes in the network.
* The gossipsub implementation does note that Peer Exchange should only be enabled in bootstrappers and well-connected/trusted nodes. I’m not sure what percentage of nodes this would actually be in the network.

// WithPeerExchange is a gossipsub router option that enables Peer eXchange on PRUNE.
// This should generally be enabled in bootstrappers and well connected/trusted nodes
// used for bootstrapping