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

✨ class hash whitelist #1550

Conversation

EvolveArt
Copy link
Collaborator

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
Copy link
Collaborator

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

Copy link
Collaborator

@apoorvsadana apoorvsadana left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

@@ -157,6 +157,8 @@ pub mod pallet {
type ProtocolVersion: Get<u8>;
#[pallet::constant]
type ProgramHash: Get<Felt252Wrapper>;
#[pallet::constant]
type WhitelistedClassHashes: Get<Vec<CasmClassHash>>;
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why do we've a pallet constant and a storage variable?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

should we also add a vector in the genesis config where the chain can set the class hashes on start?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hm yea we can probably do that, in this case I'll remove the constant then right ?

@@ -552,6 +563,15 @@ pub mod pallet {
// This ensures that the function can only be called via unsigned transaction.
ensure_none(origin)?;

// Check if class hash is whitelisted
let whitelisted_class_hashes = Self::whitelisted_class_hashes();
if !whitelisted_class_hashes.is_empty() {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

should we have a boolean variable for whitelist class hash enabled? i can think there would be cases where a chain starts with whitelisted but later opens it to everyone. i guess Pragma might want to do this as well right?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes would make sense

@EvolveArt
Copy link
Collaborator Author

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

Copy link

github-actions bot commented Jun 2, 2024

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!

@github-actions github-actions bot added the stale label Jun 2, 2024
@tdelabro
Copy link
Collaborator

tdelabro commented Jun 2, 2024

Should be easier to impl after #1590

@tdelabro tdelabro closed this Jun 2, 2024
@github-actions github-actions bot locked and limited conversation to collaborators Jun 7, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants