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

Remove AvailabilityBitfieldsStorage #3675

Closed
2 tasks
eskimor opened this issue Mar 13, 2024 · 2 comments · Fixed by #3479
Closed
2 tasks

Remove AvailabilityBitfieldsStorage #3675

eskimor opened this issue Mar 13, 2024 · 2 comments · Fixed by #3479
Assignees
Labels
C2-good-first-issue A task for a first time contributor to become familiar with the Polkadot-SDK.

Comments

@eskimor
Copy link
Member

eskimor commented Mar 13, 2024

This storage seems to be only ever written to, never read. We should kill it.

  • Remove code
  • Write migration killing the storage
@eskimor eskimor added the C2-good-first-issue A task for a first time contributor to become familiar with the Polkadot-SDK. label Mar 13, 2024
@burdges
Copy link

burdges commented Mar 14, 2024

We write directly into the transposed core bitfields prumably, which makes sense.

@alindima
Copy link
Contributor

Good catch!

We write directly into the transposed core bitfields prumably, which makes sense.

correct. we directly track the availability bits on the pending candidate storage

@alindima alindima self-assigned this Mar 15, 2024
github-merge-queue bot pushed a commit that referenced this issue Mar 21, 2024
Changes needed to implement the runtime part of elastic scaling:
#3131,
#3132,
#3202

Also fixes #3675

TODOs:

- [x] storage migration
- [x] optimise process_candidates from O(N^2)
- [x] drop backable candidates which form cycles
- [x] fix unit tests
- [x] add more unit tests
- [x] check the runtime APIs which use the pending availability storage.
We need to expose all of them, see
#3576
- [x] optimise the candidate selection. we're currently picking randomly
until we satisfy the weight limit. we need to be smart about not
breaking candidate chains while being fair to all paras -
#3573

Relies on the changes made in
#3233 in terms of the
inclusion policy and the candidate ordering

---------

Signed-off-by: alindima <alin@parity.io>
Co-authored-by: command-bot <>
Co-authored-by: eskimor <eskimor@users.noreply.github.com>
dharjeezy pushed a commit to dharjeezy/polkadot-sdk that referenced this issue Mar 24, 2024
…h#3479)

Changes needed to implement the runtime part of elastic scaling:
paritytech#3131,
paritytech#3132,
paritytech#3202

Also fixes paritytech#3675

TODOs:

- [x] storage migration
- [x] optimise process_candidates from O(N^2)
- [x] drop backable candidates which form cycles
- [x] fix unit tests
- [x] add more unit tests
- [x] check the runtime APIs which use the pending availability storage.
We need to expose all of them, see
paritytech#3576
- [x] optimise the candidate selection. we're currently picking randomly
until we satisfy the weight limit. we need to be smart about not
breaking candidate chains while being fair to all paras -
paritytech#3573

Relies on the changes made in
paritytech#3233 in terms of the
inclusion policy and the candidate ordering

---------

Signed-off-by: alindima <alin@parity.io>
Co-authored-by: command-bot <>
Co-authored-by: eskimor <eskimor@users.noreply.github.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C2-good-first-issue A task for a first time contributor to become familiar with the Polkadot-SDK.
Projects
Status: Completed
Development

Successfully merging a pull request may close this issue.

3 participants