✨ class hash whitelist

[EvolveArt]

Pull Request type

Please add the labels corresponding to the type of changes your PR introduces:

• Bugfix X Feature
• Code style update (formatting, renaming)
• Refactoring (no functional changes, no API changes)
• Build-related changes
• Documentation content changes
• Testing
• Other (please describe):

What is the current behavior?

Resolves: #NA

What is the new behavior?

Introduces a new class hash whitelisting mechanism. Adds 2 new extrinsics to whitelist/blacklist class hashes that can only be called by root. The validation happens both in the mempool and at the declare extrinsic level. If no class hashes have been whitelisted (by default), everything can be declared.

Does this introduce a breaking change?

No

Other information

[tdelabro]

Can you rebase?

Also, do we want this in the vanilla codebase? Or should we put it behind a flag? As not all chain will want it. It's our first "out of spec" feature

[EvolveArt]

I am confused with the feature flag option. Technically, it feels correct to add it behind the feature flag but

• if we add more features like this eventually, we might end up with multiple flags A, B, C etc.
• the only way to ensure they are maintained is to add their test cases in the CI. this can eventually complicate things as maybe some feature works with flags A and B but not when you enable C. so do we test all combinations or do we test the trivial ones?

I am not sure what the pragmatic thing to do here is. What codebases would be good examples for this?

Agreed I'm really not sure of the best approach here. For this small feature, let's put under a feature flag and add it in CI for now? We can think of a solution for next times

[github-actions[bot]]

There hasn't been any activity on this pull request recently, and in order to prioritize active work, it has been marked as stale. This PR will be closed and locked in 7 days if no further activity occurs. Thank you for your contributions!

[tdelabro]

Should be easier to impl after #1590