Deposit Module

[aaronc]

Following up from #8224, I'd like to propose a new x/deposit module to specifically target the part of the spam problem that can be solved by redeemable deposits. Two specific cases where this could be applied right away would be the authorization and fee grants in the new x/authz and x/feegrant modules, where fees would need to be deposited in order to create a grant and where they would be returned when the grant is revoked. Creating a grant adds a small amount of persistent state that is freed when the grant is revoked so the idea with a deposit is to a) create a small but meaningful incentive to revoke grants when they're done rather than needing to implement a separate pruning layer and b) prevent spam.

Deposit Keeper Interface

Modules would interface with the x/deposit module using the DepositKeeper which would have three basic operations: RequireDeposit, ReleaseDeposit and SlashDeposit.

RequireDeposit method

Keepers would call the RequireDeposit method with:

• a deposit key which is scoped to the calling module and describes the type of deposit. Different types of deposits would have certain base deposit amount which would be set by x/params or some other mechanism
• the depositor address
• some multiplier which scales the base deposit amount

Ex:

module authz

func (k Keeper) Grant(ctx sdk.Context, grantee, granter sdk.AccAddress, authorization exported.Authorization, expiration time.Time) error {
  err := k.depositKeeper.RequireDeposit(ctx, "authzGrant", granter, 1)
  ...
}

Release Deposit

Calling ReleaseDeposit would turn the deposited amount for the provided deposit key/depositor pair.

Ex:

module authz

func (k Keeper) Revoke(ctx sdk.Context, grantee sdk.AccAddress, granter sdk.AccAddress, msgType string) error {
  k.depositKeeper.ReleaseDeposit(ctx, "authzGrant", granter)
  ...
}

Slash Deposit

A SlashDeposit method would also be available to slash all or part of the deposit in certain conditions

Fee.deposit field

A deposit field would get added to Fee so that:

• deposits are handled through the ante handler and explicitly declared in a transaction rather than needing to add a deposit field to every message which uses them
• deposits can be paid for using the x/feegrant module - Allowances could have a flag which indicates whether they can be used for deposits or not

Deposit pricing

The simplest model would be to have fixed base deposit amounts set by governance using x/param. In the future, if there is an algorithm like EIP 1559 for base fees, it could potentially be used as a scaling factor for deposit amounts, but that would be a research topic for the future.

---

This module should be relatively straightforward to implement and could address part of the spam problem.

[robert-zaremba]

Could you frame the problem we are trying to solve here? I guess it's paying fees for users who have locked tokens (when the transfers are disable on the network level)?

[aaronc]

It's just what I said here:

Two specific cases where this could be applied right away would be the authorization and fee grants in the new x/authz and x/feegrant modules, where fees would need to be deposited in order to create a grant and where they would be returned when the grant is revoked. Creating a grant adds a small amount of persistent state that is freed when the grant is revoked so the idea with a deposit is to a) create a small but meaningful incentive to revoke grants when they're done rather than needing to implement a separate pruning layer and b) prevent spam.

The whole idea (which I believe you suggested initially) is that the user locks up a deposit when they grant an authorization in authz and gets the deposit back when they revoke it so there's an incentive for them to delete the old state and save storage.

[aaronc]

What you posted here in this comment is what this about.

There you used the language "and require a stake, which will be released once we delete the storage". I'm using the word "deposit" instead of "stake".

[robert-zaremba]

Yes, thanks. It wasn't clear to me because the recent context and discussions were about 0 fess, gas prices and multi denom payments.

The mechanism for I have in mind is a bit different - let me describe it more in detail below.

[robert-zaremba]

[aaronc]

Hmm... I think there's some confusion. Look at my response to your other question. I'm describing something you proposed with a different wording before. This has nothing to do with fee grants.

[robert-zaremba]

Alternative proposal (I will use deposit word instead of stake).

Resource Deposits

We propose a resource staking mechanism to obtain a right to acquire and hold a resource (eg storage).

Framing

Additional fee mechanism, which will be complementary for gas payments.
In gas payment mechanism - a user is charged a certain amount of tokens (gas_used x gas_price) per transaction. This tokens are spent and not available to the user any more.

Motivation

Some messages would prefer to additionally require from a user to deposit (stake) tokens for a resource locked by the user. Once that resource is released, user will be able to get the tokens back. Notable examples:

• messages which create a storage which can be released (eg authorization delegation).
• DAO may require a user to deposit a bond when making a new proposal. Bond will be released after a voting period.

Model

x/deposit will be used managing module/user deposits. More specifically, we will keep balances for the following triple:

type Deposits  map[ (module_name, submodule_key, account) ] Balance

type Balance struct {
    total: sdk.Int
    used: sdk.Int
}

So, a deposit is a mapping of module_name, key, account triple into a balance.
Balance tracks a current state of a deposit: what's the total deposit and how much is used.

submodule_key represents an entity in a module (can be empty).

The keeper will have following methods:

// Depost will top up a user deposit by increasing total balance and locking 
// tokens (tokens will be transferred from account to the deposit module account). 
// Returns account deposit balance.
func (k Keeper)  Deposit(module, key string, account Account, amount sdk.Int) Balance

// Withdraw decreases account deposit balance and transfers tokens from the 
// deposit module back to the account.Returns account deposit balance.
func (k Keeper) Withdraw(module, key string, account Account), amount sdk.Int) Balance

// Require increases the account deposit used balance. Returns error 
// if the used amount goes above the account total balance.
func (k Keeper) Require(module, key string, account Account, amount sdk.Int) error

// Release decreases the account deposit used balance. Returns error if
// the it goes below zero.
func (k Keeper) Release(module, key string, account Account, amount sdk.Int) error

Examples:

1. A User (or a sponsor) can top up his authz deposit account using depositSrv.Deposit(authz.ModuleName, "", acc, Atoms(10)) -- here we assume that authz doesn't use a sub-module keys for deposits.
2. authzSrv.GrantAuthorization would call depositSrv.Require(authz.ModuleName, "", granter, Atom(0.01)) when a new authorization record is created.
3. authzSrv.RevokeAuthorization would call depositSrv.Release(authz.ModuleName, "", granter, Atom(0.01)) when an authorization record is removed.
4. daoSrv.MakeProposal would call depositSrv.Require(dao.ModuleName, daoName, proposer, Atom(2)) when a new voting proposal is created. 10 Atoms cover a storage cost and a bond for a proposal (to avoid creating too many proposals at once).
5. daoSrv.ExecuteProposal would call depositSrv.Release(dao.ModuleName, daoName, proposer, Atom(1.98)) when a proposal is executed, a bond is released. 0.02 Atom will stay locked because the proposal record will stay in the chain.

Using gas style deposits

It will make sense to use deposits using gas price instead of tokens. So instead of Atom(2) we would have DepositGas(300). For proper accounting we would need to make adjustments whenever a DepositGas price will change. The assumption here is that deposit gas price will change very rarely - it should reflect a hardware / resource cost changes. For example: when a storage price will change by 30% and once market (infrastructure providers) will react on that, then we can change the DepositGas price.

The Balance type would change:

type Balance struct {
    total: sdk.Int    // denominated in the native currency
    usedGas: sdk.Int  // denominated in gas
}

The invariant in depositSrv.Require will be: total >= usedGas * depositKeeper.GasPrice (which will be governed by the consensus).

The x/deposit keeper will have a UpdateGasPrice method, which will migrate all account balances by scaling the balance.used value.

[hxrts]

Notably, these proposals preclude multi-denom fees without at least some base currency for any operations that require deposits. Looking more and more necessary to require native tokens for at least some actions.