Rate limiter
The following arguments are settings for the rate limiter (spam prevention). The client accumulates one "operation
point" every rate_limit_recovery_time
milliseconds, up to rate_limit_max_points
. You spend one operation point for
each authenticated operation.
You can configure this with module args for the lib.ft4.core.accounts
module like this:
blockchains:
my_rell_dapp:
module: main
moduleArgs:
lib.ft4.core.accounts:
rate_limit:
max_points: 10
recovery_time: 5000
points_at_account_creation: 1
Argument | Description | Default value |
---|---|---|
max_points | is the maximum number of operation points that can accumulate (and, therefore, the maximum number of transactions you can do at once). | 10 |
recovery_time | (Milliseconds) is the cooling period before an account can receive one operation point. | 5000 |
points_at_account_creation | The points that an account has at the moment of its creation (0 is min). | 1 |
Disable rate limiting like this:
blockchains:
my_rell_dapp:
module: main
moduleArgs:
lib.ft4.core.accounts:
rate_limit:
active: 0
You can override rate limit configuration for specific accounts (including completely deactivating it) by extending the
account_rate_limit_config(account): rate_limit_config?
function in the lib.ft4.core.accounts
module. Return null
to use the standard rate limit configuration. For example:
import lib.ft4.core.accounts;
entity admin_account {
key accounts.account;
}
@extend(accounts.account_rate_limit_config) function(accounts.account) =
if (exists(admin_account @? { account }))
accounts.rate_limit_config(active = false)
else
null;
Transaction prioritization
By importing the lib.ft4.core.prioritization.default
module, you can enable transaction prioritization so that the
rate-limiting rules are applied to transactions in the transaction queue, which will have the following effects:
- Accounts with more points will get higher priority for their transactions.
- Accounts with disabled rate limiting will get the highest priority for all their transactions.
- Transactions that the rate limiter would have rejected will be rejected immediately upon submission.
- If the queue becomes full, transactions can be removed from the queue to make room for transactions with higher priority.
You can customize this behavior by importing lib.ft4.core.prioritization
instead of
lib.ft4.core.prioritization.default
and extending the function
priority_check(tx_body: gtx_transaction_body, tx_size: integer, tx_enter_timestamp: timestamp, current_timestamp: timestamp): priority_state_v1?
.
import lib.ft4.core.prioritization.*;
@extend(priority_check) function(tx_body: gtx_transaction_body, tx_size: integer, tx_enter_timestamp: timestamp, current_timestamp: timestamp): priority_state_v1 {
// custom logic here
return no_op_priority_state();
}
The exact details of how to implement this function are beyond the scope of this documentation. Use the default implementation as a starting point.