Bank Module Send Disabled Token Configuration

[iramiller]

Summary of Bug

The bank module stores the Send Disabled status for coins in a configuration block. This approach does not scale to a large number of token denominations. As additional coins are added to this parameter configuration the gas read/write costs for maintaining the list becomes excessive.

Version

latest/main

Steps to Reproduce

The current implementation of the Send method checks parameter configuration on every call to determine if a coin is allowed to be sent.

cosmos-sdk/x/bank/keeper/send.go

Lines 316 to 319 in 567a6be

	// IsSendEnabledCoin returns the current SendEnabled status of the provided coin's denom
	func (k BaseSendKeeper) IsSendEnabledCoin(ctx sdk.Context, coin sdk.Coin) bool {
	return k.GetParams(ctx).SendEnabledDenom(coin.Denom)
	}

cosmos-sdk/x/bank/types/params.go

Lines 62 to 69 in 567a6be

	func (p Params) SendEnabledDenom(denom string) bool {
	for _, pse := range p.SendEnabled {
	if pse.Denom == denom {
	return pse.Enabled
	}
	}
	return p.DefaultSendEnabled
	}

This approach is extremely inefficient and does not scale to a large number of restricted coins. Within the Provenance Blockchain there are many coin denominations which are set to "send disabled" so that users can not transfer these coins directly and must use appropriate APIs to do so.

A more efficient approach would be to store the send disabled status directly in the KVStore using a key based on the denomination. This would remove a significant amount of processing from each send call as well as allow a much larger number of tokens to be restricted/send disabled without impacting transaction performance.

---

For Admin Use

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

[alexanderbez]

Hey @iramiller. Thanks for opening up the issue.

A more efficient approach would be to store the send disabled status directly in the KVStore using a key based on the denomination.

This is essentially how it already works. The main difference the param blob is stored as a single object, rather than individual KV records. So yes, the gas costs would increase proportionally to the number of denoms your chain supports.

I think having these as direct values in the x/bank store could make sense. I'm all for the proposal, but I'm just trying to get the team better about prioritizing and creating roadmaps.

@marbar3778 are you in favor of such a change? I'd be happy to tackle it.

[iramiller]

So yes, the gas costs would increase proportionally to the number of denoms your chain supports.

For reference we are exceeding our 4M gas per tx limits when working with this data structure on our testnet. Granted our testnet has a lot of extraneous data but I expect our mainnet will get there eventually. Our network is a unique case because we model securities on it and those require a smart contract facilitated transfer to move between accounts--thus the send disabled flag settings.

cc: @dwedul-figure who also has some thoughts on this and was looking at how we might need to solve this using our fork.

[alexanderbez]

Yes, totally makes sense. The proposed solution is trivial and makes sense. I just want buy-in from a few other folks before I start working on it.

[dwedul-figure]

I can also pick this up if you'd like. Just let me know.

[alexanderbez]

@dwedul-figure go for it! Just make sure we have a migration for it as well 👍