Bank module supports the function of dynamically adding blacklist

[dreamer-zq]

Summary

Members of the blacklist should support dynamic addition and deletion, but should not be fixed when the network is started, so for users who use cosmos-sdk to develop other applications, the scalability is not very good.

Problem Definition

The custody account of each module of the system may be dynamically generated. If you need to add to the blacklist list, if you want the bank module to introduce the function of dynamically adding a blacklist

Proposal

The bank module provides interfaces that can be dynamically added and removed. The blacklist requires persistent storage.

For Admin Use

• Not duplicate issue
• Appropriate labels applied
• Appropriate contributors tagged
• Contributor assigned/self-assigned

[alexanderbez]

Right now the blacklist is solely intended for module accounts which are known at compile-time and are static. We never intended to support dynamic capabilities because you cannot dynamically generate module accounts post-chain-start.

That being said, can you please list some specific uses cases where we'd want to blacklist accounts dynamically?

[dreamer-zq]

Scenario 1: We have implemented a uniswap protocol, using an account model as a liquidity pool (which is relatively simple), and each two types of tokens that need to be exchanged require a dynamically produced independent liquidity pool. If it is impossible to control other users to directly transfer funds to the liquidity pool, it will affect the ratio of these two tokens, causing errors in the conversion ratio.

Scenario 2: Use the port in the IBC module to generate the relevant escrow account for recording the locked tokens. My understanding is to facilitate the tracking of the total amount of tokens transferred through the port. The transfer will also cause the port to transfer the total amount of tokens, although there is no major harm.

The above case about the dynamic blacklist function may not be very appropriate, but I think that applications developed based on cosmos-sdk in the future may have more use cases

[alexanderbez]

@zhiqiang-bianjie understood. I can see how this will be beneficial. I propose we update NewBaseKeeper by removing the blacklistedAddrs param and instead have a BaseKeeper#SetBlacklistAddress.

Then, BaseKeeper#SetBlacklistAddress will be called under two cases:

1. At network initialization (e.g. module accounts)
2. In the state-machine/modules where this needs to happen dynamically (e.g. liquidity token-pair pools)

[alexanderbez]

We may have to kick this out to 0.40.

[github-actions]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.