p2p/reactors: some additional topics for discussion (WIP) #8
Conversation
p2p/reactors/peer-kvstore.md
Outdated
| > I think we can come up with a cleaner interface for this information flow, | ||
| > ideally having all consensus-specific logic within consensus. I think we should | ||
| > look into this more closely. |
There was a problem hiding this comment.
As far as I understand now it is less about consensus per se, but just communicates the height. I guess the question we should ask is "How shall we make a node's local height, as well as the heights of the peers available to the reactors?"
There was a problem hiding this comment.
We could abstract this information as a logical clock. In the case of cometbft, logical time is measured in heights, but other algorithms can measure it in "real time", epochs, ...
There was a problem hiding this comment.
As this is mainly to keep track of things we found, I think we can merge, and discuss with the team later. @sergio-mena said that at some point he would like to see what potential work is out there, so this would be a good starting point.
Co-authored-by: Josef Widder <44643235+josef-widder@users.noreply.github.com>
p2p/reactors/peer-quality.md
Outdated
|
|
||
| func (sw *Switch) MarkPeerAsGood(peer Peer) | ||
|
|
||
| However, there is no method in the [API to Reactors][pr-851] to mark a peer as |
There was a problem hiding this comment.
Instead of marking as bad as good, we could use a point system, where points are normalized to give a rating between 0 and 1.
what reactors do based on this rating, e.g. setting a minimum rate of 0.8 to be considered good, is up to them.
this is more or less the idea of the accrual failure detector.
Rendered files under: https://github.com/cometbft/knowledge-base/tree/cason/p2p-reactor/p2p/reactors