build a blacklist store to check the account state before any transaction.

[amarts]

Having an option to have a blacklist member check during the runtime config for any permission'd network is a better than 'allowing' membership.

In a permission'd network, it is good to approve the node-authorization based on account and nodeKey, but any account with a balance should be able to transact on the network, which makes the job of governance more simpler. With ability to approve the revoking of membership, governance council can still take control of any account which got balance by mistake.

Similar to membership (isMember()) pallet, implement a blacklist pallet.

[ritankarsaha]

@amarts I think the approach to this issue would be

1. Add the Blacklist Pallet to the Runtime by adding it to Cargo.toml. Updating construct_runtime! in the runtime's lib.rsto register thepallet`.
2. Implement Transaction Validation Logic by modifying the runtime's transaction validation logic to check if an account is blacklisted. If blacklisted, reject the transaction during validation.
   We can use the is_blacklisted function from the pallet to check an account.
   Also for any pallet where extrinsics need to prevent blacklisted accounts from acting we can add a check inside the extrinsic’s logic using ensure!(!is_blacklisted(who), "Account is blacklisted");. Finally ensuring only authorized entities (like governance or root) can add or remove accounts from the blacklist.

The structure would be somewhat:-
/pallets
/blacklist
├── src
├── lib.rs
├── mock.rs (for testing)
├── tests.rs (for runtime tests)

Is this implementation correct or do I need to consider something else for this as well? I would also like to try out this issue.