build a blacklist store to check the account state before any transaction.
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.
@amarts I think the approach to this issue would be
- Add the
Blacklist Pallet to the Runtime by adding it toCargo.toml. Updatingconstruct_runtime!in theruntime's lib.rsto register thepallet`. - Implement
Transaction Validation Logicby modifying the runtime'stransaction validation logicto check if an account is blacklisted. If blacklisted, reject the transaction during validation. We can use theis_blacklistedfunction 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.
Hello @amarts I was going through the network-membership pallet , It has a defined storage for MemberShipBlacklist , is it for the same purpose as mentioned in the issue above ?
And In the required blacklist pallet , what dispatchable functions might be needed apart from adding , removing and checking in a blacklist .