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

CountedMap with an enforced MaxValue #141

Open
kianenigma opened this issue Aug 5, 2023 · 0 comments
Open

CountedMap with an enforced MaxValue #141

kianenigma opened this issue Aug 5, 2023 · 0 comments
Assignees
Labels
T1-FRAME This PR/Issue is related to core FRAME, the framework.

Comments

@kianenigma
Copy link
Contributor

First, the current storage maps have a MaxValues that is not very well documented, and counter intuitively, it is not an enforced in any way. This MaxValues is only used in storage_info related functions.

This needs to be fixed, as a part of paritytech/substrate#13987.

Then, we could consider creating a CountedMap, possibly called BoundedMap that actually has a maximum counter enforced. This is in itself not so exciting, as once the map is filled, it is pretty useless. In other words, it is not sybil resistance. The solution is to expose an API through which an economic game can be created to allow users to kick someone out of the map and replace themselves.

fn insert(key: Self::Key, value: Self::Value) {
  // normal insert, if the map is full, this will fail
}


fn try_insert(key: Self::Key, value: Self::Value, eject: Self::Key) {
  // insert `value` under `key`, and if the map is full, try and eject `eject` from the map.
  // this should use a separate `triage`-like method, provided by the user of the map, to 
  // compare if `key` is more worthy of staying in the map or `eject`
}

This should make the creation of maps that are bounded, and allow users to compete in a position in the map based on some amount of deposit more streamlined.

@juangirini juangirini transferred this issue from paritytech/substrate Aug 24, 2023
@the-right-joyce the-right-joyce added I10-unconfirmed Issue might be valid, but it's not yet known. T1-FRAME This PR/Issue is related to core FRAME, the framework. and removed J2-unconfirmed labels Aug 25, 2023
@kianenigma kianenigma removed the I10-unconfirmed Issue might be valid, but it's not yet known. label Feb 5, 2024
@kianenigma kianenigma self-assigned this Feb 5, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
T1-FRAME This PR/Issue is related to core FRAME, the framework.
Projects
Status: Shaping up
Development

No branches or pull requests

3 participants