feat: add support for spendable balances gRPC query

[alexanderbez]

Description

It's often useful for users to know their current spendable balance. Currently there is only an endpoint that gives you your total balance and an endpoint that gives you full account details. In the context of vesting accounts, it is not possible to know what part of the balance is "spendable" without doing manual arithmetic. This PR adds a query to provide that data directly.

It operates the same way as all balance query does, but filters the balance value by what's spendable.

---

Author Checklist

All items are required. Please add a note to the item if the item is not applicable and
please add links to any relevant follow up issues.

I have...

• included the correct type prefix in the PR title
• added ! to the type prefix if API or client breaking change
• targeted the correct branch (see PR Targeting)
• provided a link to the relevant issue or specification
• followed the guidelines for building modules
• included the necessary unit and integration tests
• added a changelog entry to CHANGELOG.md
• included comments for documenting Go code
• updated the relevant documentation or specification
• reviewed "Files changed" and left comments if necessary
• confirmed all CI checks have passed

Reviewers Checklist

All items are required. Please add a note if the item is not applicable and please add
your handle next to the items reviewed if you only reviewed selected items.

I have...

• confirmed the correct type prefix in the PR title
• confirmed ! in the type prefix if API or client breaking change
• confirmed all author checklist items have been addressed
• reviewed state machine logic
• reviewed API design and naming
• reviewed documentation is accurate
• reviewed tests and test coverage
• manually tested (if applicable)

[tac0turtle]

could we get a test for this please 😄

[tac0turtle]

I was thinking why not have spendable coins, vested coins, staked coins and unbonding coins under one response, https://github.com/cosmos/cosmos-sdk/blob/master/x/bank/types/query.pb.go#L78.

Something like:

type QueryBalanceResponse struct {
	// balance is the balance of the coin.
	totalBalance *types.Coin `protobuf:"bytes,1,opt,name=balance,proto3" json:"balance,omitempty"`
	spendableBalance *types.Coin `protobuf:"bytes,1,opt,name=balance,proto3" json:"balance,omitempty"`
	vestingBalance *types.Coin `protobuf:"bytes,1,opt,name=balance,proto3" json:"balance,omitempty"`
}

we could also add bonded and unbending balance here too.

seems some what simpler than introducing a new endpoint for this.

[alexanderbez]

I was thinking why not have spendable coins, vested coins, staked coins and unbonding coins under one response, https://github.com/cosmos/cosmos-sdk/blob/master/x/bank/types/query.pb.go#L78.

Something like:

type QueryBalanceResponse struct {
	// balance is the balance of the coin.
	totalBalance *types.Coin `protobuf:"bytes,1,opt,name=balance,proto3" json:"balance,omitempty"`
	spendableBalance *types.Coin `protobuf:"bytes,1,opt,name=balance,proto3" json:"balance,omitempty"`
	vestingBalance *types.Coin `protobuf:"bytes,1,opt,name=balance,proto3" json:"balance,omitempty"`
}

we could also add bonded and unbending balance here too.

seems some what simpler than introducing a new endpoint for this.

That would require more work and proto types. Also, that info is already available via other endpoints. That's also not backwards compatible.

[tac0turtle]

That would require more work and proto types. Also, that info is already available via other endpoints. That's also not backwards compatible.

the spendable would be this pr, not in a new sturct?

[alexanderbez]

That would require more work and proto types. Also, that info is already available via other endpoints. That's also not backwards compatible.

the spendable would be this pr, not in a new sturct?

It depends, are you proposing to introduce a new type or modify the existing balances gRPC query?

[tac0turtle]

It depends, are you proposing to introduce a new type or modify the existing balances gRPC query?

modify existing

[alexanderbez]

It depends, are you proposing to introduce a new type or modify the existing balances gRPC query?

modify existing

I suppose I would also be in favor of that, but:

1. It's not backwards-compatible
2. Would require an x/auth dependency (to get vesting fields)

This is why I propose we just keep it simple and have a spendable query :)

[alexanderbez]

@AmauryM or @robert-zaremba thoughts or any opposition to this new handler? If not, I'll merge.

[atheeshp]

lgtm

@AmauryM or @robert-zaremba thoughts or any opposition to this new handler? If not, I'll merge.

but it's better to wait for the response.

[atheeshp]

I think the failing tests are from this PR #10988

[alexanderbez]

I think the failing tests are from this PR #10988

@marbar3778 are you gonna fix that? How did that PR land in master with a failing test?

[robert-zaremba]

useful query. One nit to see if we can optimize the store flow.

[tac0turtle]

I think the failing tests are from this PR #10988

@marbar3778 are you gonna fix that? How did that PR land in master with a failing test?

it looks to be non deterministic. I was having issues replicating it locally, seems GitHub actions had it pass once and it worked

[robert-zaremba]

This function can be called by other transaction. So, let's charge extra gas here. Eg 20gas per iteration.

[alexanderbez]

Charge gas? This is a query, not a transaction.

[robert-zaremba]

I know. But it can be called from a transaction, in other words, a RPC Msg method, when running can do a query call.

[alexanderbez]

I don't follow?

These methods are for queries only. In fact, in a subsequent PR, I'll be removing these from the Keeper entirely, in favor of a dedicated Querier (Example). All modules should follow this approach.

[robert-zaremba]

Look at this example: https://github.com/regen-network/regen-ledger/blob/master/x/ecocredit/server/msg_server.go#L718 - The rpc Buy will call bank.SpendableCoins.

Technically we can create a QueryClient of other module, and use it when processing a transaction.

[alexanderbez]

Technically we can create a QueryClient of other module, and use it when processing a transaction.

That doesn't make any sense. Gas and txs are not involved here.

[robert-zaremba]

Probably I didn't express myself well enough. Here is the snippet (didn't test it but I believe it's possible):

/// in authz Grant Msg function
// let's imagine a scenario where we want to check spendable coins
func (k Keeper) Grant(goCtx context.Context, msg *authz.MsgGrant) (*authz.MsgGrantResponse, error) {
   ...  
   bc := banktypes.NewQueryClient(ctx)
   resp, err := bc.SpendableBalances(ctx, types.QuerySpendableBalancesRequest{...})
   ....

BTW - I think this is general discussion if we should check if we should consider checking if context provides a gas meter in queries and charge gas (so feel free to merge)