Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Collator Protocol Revamp: reputation database #7751

Open
alindima opened this issue Feb 28, 2025 · 0 comments
Open

Collator Protocol Revamp: reputation database #7751

alindima opened this issue Feb 28, 2025 · 0 comments
Labels
T8-polkadot This PR/Issue is related to/affects the Polkadot network.

Comments

@alindima
Copy link
Contributor

Implement a reputation database which supports (at least) the following basic operations:

trait Db {
    fn query(PeerId, ParaId) -> Option<Score>;
    fn modify_reputation(PeerId, ParaId, Score);
}

Properties:

  • Persistent, but allows for occasional data loss (due to unexpected exits). Persistence is only needed so that data is not lost across validator restarts and so that validators don't hold too much useless data in memory.
  • Single-threaded access
  • The set of allowed paraids is predefined (as the set of registered paraids). When a para is unregistered, their reputations can be dropped.
  • Each paraid has a maximum predefined capacity for peers (maybe 100). Once capacity is reached, use an LRU approach.

Conceptually, it should work like a BTreeMap<ParaId, LruMap<PeerId, Score>>. Using the parachains db is probably the best option.

Start with a simple implementation that doesn't do premature optimisations. See if they are needed through testing and benchmarking.

Some ideas for improving performance:

  • have an in-memory write overlay that supports a flush operation every X amount of time
  • pre-load in memory the values for the scheduled paraids
  • the per-para LRU is tricky to implement efficiently in the parachains key-value DB. Start simple with a naive O(N) lookup for the oldest item when inserting while at capacity. N is at most 100 and it should rarely be reached, so this could be ok. An idea for improving the algorithmic complexity would be to encode a heap in the key-value DB over the 0..N keys , achieving O(logN) operations.
@alindima alindima added the T8-polkadot This PR/Issue is related to/affects the Polkadot network. label Feb 28, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
T8-polkadot This PR/Issue is related to/affects the Polkadot network.
Projects
Status: Backlog
Development

No branches or pull requests

1 participant