[LibP2P] - Quorum - Create new topic for Entropy broadcasting. (Needs Spike)

[mibuono]

Requirements:

• [ ] Need new filtering system
• [ ] Do an announce for entropy
• [ ] Needs to stop rebroadcast

Note: The DHT is recording peers and topics. The DHT has a mechanism that says you are part of this topic and update. When you update entropy - this is where it should go. Key is the topic, and value is the peer ID, and appended to it is the entropy.

[mibuono]

In a high sync environment, what happens? If there is inefficiency in the request and syncing systems, this may or may not be a problem.

[mibuono]

A point to to discuss - this is not sybil resistant (!@wizeguys opinion)

Kilts - thinks that peer ranking is inefficient which could cause the blooming of the network to take a really long time.

There is a dfiscussion of IF this is a problem And another dfiscussion whether this IS the right topic to create for this (DHT providing)

[mibuono]

Raw notes:

Broadcasts can't flood - to do this you have to have banning and truncation of broadcasts that are _____

I want to be efficient for who I am asking for data if there is a large % of the network always syncing.

Side path:
We never ask bad peers every minute - but we should maybe ask the bad bucket to 1% of the time we can ask them for data to let them have the opportunity to upgrade their peer ranking.

Let's trim % of traffic we are sending to the low priority buckets.

Getting lively information of entropy of all peer is an all to all problem.

We do not have a liveliness filter - we are marking broadcast as lively.

maybe we should remove the filter from the broadcast hook, and as we are making requests and we get to the latest announce header - and if peers respond, then it tells us they are lively.

If you're at the tip

Summary: Gossipsub is all about broadcasting - not request and response. We need a proper responsive and lively metric. Lively metric hasn't been correct. Responsive means I respond to requests - and can get up rated for that. Lively - means I am synced to the tip of the network.

If we can make the rating aysmmetric (+1 for good data, and -100 for bad) John is good with this.

Responsive - is only network reachability - running goquai, handshakes and responds. Update responsiveness on boardcasts. In the future, we want to be able to add how quickly someone responds as a part of this rating. (issue for later)

Liveness - Can I get data from a peer that is close to where I am in the chain? If I pass them, they are no longer have liveness to me, but still have a responsive score. If you are syncing, anyone who is able to advance your state, you mark them as lively. Has to be updated on requests.

Our Main definitions:

1. Responsiveness = The peer responds to the request - connected to the network and willing to talk to me. We will can make the rating asymmetric (+1 for broadcast, +10 for successful response.) - this also applies to gossipsub
2. Lively = "they have the data that I am requesting" - especially towards the tip - OR if they are further in the syncing process or closer to the TIP than I am.

What happens when we are synced?

Liveness and responsiveness decay with time. So when you are synced these numbers go down. And it's not a problem because the node will very quickly figure out who is live.

Task after meeting:

• [ ] Someone should figure out the ratio of these and assign numbers for each based on how much they are called.

• Broadcast

• Response with data

• Response without data

• Not responding at all

Future Tasks:

• [ ] Define responsiveness related to the ping (latency) of the responses coming back after a request. There is something we can possibly do here in the aggregation of data in peer ranking that aggregates all of these numbers and spits out a value versus the maximum.

-- The thought here is that the ping will help load balance the requests across the network - as ping will go up for nodes that are overloaded, and this score could help spread out requests to other nodes as this value goes down. -- How much resource do I have and bandwidth to pipe it - which is more relative to resource i have.
-- If we can provide a n(ack) response - this might be another option that is simpler.
-- Service time is the number - if I am just doing service time, once my service times start to suck, I start n(ack)ing. -- n(ack)ing causes liveness score to go down.

• [ ] Task: We need to add flow control - If your system is overloaded by measured service time, refuse requests with a n(ack) - Also - need to be taking an average on service times.

• [ ] Someone should pick a number to start the nacking and test it.

• [ ] Need to define how far back we need to average on the service time calculation

• [ ] Collate LibP2P into one quality score Rating function needs to Broadcast = +1 Respond to a request +10 Respond to a request with a nack -10 Dont respond -20 Max value = 1000 , min = -1000 if we bound- we don't need the decay function anymore