Relay chain transaction fees and transaction limits for each block
Resource Usage Limits
Set transaction fees
Adjust transaction fees based on time
treasury
Recap:
In the previous Web3 Research Series｜Polkadot Token Economics (Part 1), we elaborated on
1. The organizational structure and main functions of the token DOT
secondary title
text
Relay chain transaction fees and transaction limits for each block
Some of the properties we want to implement on relay chain transactions are as follows:
1. Each relay chain block should be given a certain amount of resources so that requests on the block are processed efficiently, even on less powerful nodes, to avoid delays in generating block responses.
2. The growth rate of relay chain states is limited. 2'. It would be better if the absolute size of the relay chain state was bounded.
3. Each block pair has a certain number of operations with guaranteed availability and high-priority transactions (such as misconduct reports.)
4. Blocks are usually far from being filled, so can efficiently handle spikes in activity and have a short containment time.
5. Fees change slowly enough that fees for a particular transaction tx can be accurately predicted within minutes
6. For any transaction, the level of transaction fees must be strictly greater than the reward that the producer of the block receives for running it. Otherwise, block producers are incentivized to fill blocks with fake transactions.
7. For any transaction, a sufficiently high operating reward is the consensus of the block producer, and its reward is enough to encourage the inclusion of the transaction into the block, but not enough to motivate the block producer to create a fork and steal the transaction of the previous block .
In practice, this means that the perceived marginal reward for including an extra transaction is higher than the corresponding marginal cost of processing it, however, the total reward for producing a full block is not much greater than the reward for producing an empty block (even when tips are counted).
Currently, we focus on satisfying attributes 1 to 6 (excluding 2'), and retain attributes 2' and 7 for further updates. We also need to do more analysis on attribute 2.
We can regulate the amount of transactions processed in relay chain blocks in two ways: imposing limits and adjusting transaction fee levels. We ensure that properties 1 to 3 above are met by imposing strict limits on resource usage, while properties 4 to 6 are achieved by adjusting fees. These two techniques are described in the following two subsections.
Resource Usage Limits
We identified four resources that may be consumed when processing transactions:
1. Length: the data size of tx in the relay chain block (in bytes),
2. Time: import time (i/o and cpu),
3. Memory: Amount of memory to run when necessary
4. State: Increased state storage.
Note that, unlike the other three resources that are only consumed once, state storage has a permanent cost on the network. So, for state storage, we can lease or use other mechanisms to better match fees to the actual cost of transactions and ensure that the state size is not bounded. This requires further consideration. We could also consider another mechanism that doesn't impose a hard limit on state growth, but instead controls it via a fee; however, we (the WEB3 Foundation) prefer to add a robust limit regime to avoid state becoming incapable of Extremes of control arise.
Tunable parameters: Currently, we recommend the following limits on resource usage when processing blocks. These parameters will be passed. For now, we recommend the following limits on resource usage when processing chunks. These parameters will be further tuned through governance based on real data or more complex mechanisms.
1. Length: 5MB,
2. Time: 2s
3. Memory: 10GB
4. Status: 1MB growth
In principle, a transaction consumes a certain amount of the following three resources, depending on its length, type, input parameters and current state. However, for simplicity, we decided to consider only the worst-case state and the byte length of its input parameters for each transaction type. Therefore, we categorize transactions by length, type, and parameter length, and run tests (based on worst-case scenarios) to check their typical resource usage.
Currently, we are working on a model where blocks process each transaction sequentially. So, to ensure the memory limit of the blocks above, it is enough to ensure that every transaction respects the memory limit. We make sure it all happens. However, in the future we may consider parallelism.
To further simplify the model, we will define the transaction weight as a parameter to capture the transaction's occupancy time and state increase. Specifically, we define transaction weights as the maximum value of their typical epoch and state usage, each weight measured as a fraction of the corresponding block limit. Then, given a collection of transactions, we will sum their lengths on the one hand, and their weights on the other hand, and only allow them to be in the same block if both constraints are respected. This is a hard constraint on resource usage that must be respected in every chunk.
We have added further restrictions on resource usage. We distinguish between "normal" transactions and "actionable" transactions, which are high-priority transactions reported by fishermans. Normal transactions are allowed to be collected and packaged within the same block only if the sum of their lengths and sum of weights are both lower than 75% of the corresponding limit. This is to ensure that each block has guaranteed space for actionable transactions (with at least 25% of resources left).
Typical resource usage details established for the transaction in question. The length is easily determined by inspection. For time and memory usage, we prepared the worst state for the relay chain (the time and memory requirements to import this transaction type should be the largest state). For a given transaction type, we use the state that takes the longest import time to generate 10,000 transactions, and measure the mean and standard deviation of resource usage in the Wasm environment. If the standard deviation is greater than 10% of the mean, we increase the sample space to more than 10k. Finally, improve the state by checking against a large sample of worst-case transactions.
Set transaction fees
According to the above model, we set transaction fees based on three parameters: transaction type, transaction time length and weight (parameters already defined above). This fee difference is used to reflect the difference in resource costs incurred by each transaction, and based on this, certain transaction market behaviors are determined and encouraged or discouraged.
As mentioned earlier, a portion of transaction fees need to go to block producers to encourage inclusivity, but not all, so block producers are discouraged from filling blocks with bogus transactions. For simplicity, we initially proposed to give 20% of each transaction fee to the block producer and the remaining 80% to the treasury. We note that it is possible to set a smaller value for burning, but we choose not to do so to better control the inflation rate. In the future, we can adjust this percentage, and it can be specific to transaction types, to encourage block producers to include specific transaction types without adjusting fees.
in
inis a transaction-independent parameter that changes over time depending on network traffic; we explain this parameter in the next section. parameter
Only depends on the transaction type; in particular for business transactions, we will currently
Set to zero.
Intuitively,covers the processing costs of block producers, while
，
Covers the opportunity cost of processing a transaction within a block versus another transaction within a block.
Adjust transaction fees based on time
On blockchains, transaction demand is often very irregular. On the one hand, trading has peaks of activity during hours of the day or days of the month. On the other hand, there is a long-term trend. With these factors in mind, we need a mechanism that automatically updates transaction fees over time. According to the law of supply and demand, raising fees should reduce demand and vice versa.
To deal with spikes in activity, we need to balance rapidly increasing transaction fees or potentially extending transaction inclusion times, both of which are detrimental effects. We propose two mechanisms. The first adjusts prices very quickly, at the same pace as the peaks and troughs of activity. The second is to adjust slowly according to the long-term trend and use tips to give users the possibility to control the waiting time during peak hours. We recommend using the slow adjustment mechanism with hints, but provide details on the integrity of both mechanisms.
Quickly adjust prices
In this mechanism, transaction fees vary widely over time, but are fixed (no tips) per block for all users.
Recall that we put a hard limit on the sum of the lengths and weights of all transactions allowed on a block. We also set a second hard limit, this time the sum of length and weight of "normal" transactions (non-operational transactions), equal to 75% of the first limit.
Definition: We define the saturation level of a block (relative to normal transactions) as a decimal number s between 0 and 1, which describes how far the limit of normal transactions is from saturation. Specifically, the saturation of block B is at
Within the normal length range, the block length limit for normal transactions is 75% of the total length limit, and the normal weight limit is 75% of the total weight limit.
Adjustable parameters: Let s* denote the target block saturation. This is the long-term average (relative to normal transactions) of our expected block saturation levels. We initially suggested s* = 0.25 so that blocks are on average 25% full and the system can handle burst spikes up to 4x the average number of normal transactions. Adjustments can be made based on observed transaction volume versus average transaction volume during peak periods, and there is usually a trade-off between higher average fees and longer transaction inclusion times during peak periods.
Recall that transaction fees are calculated as
non-transactional. Let s be the saturation of the current block. If s > s∗, we increase flow slightly,and if s
Adjustable Parameters: Let v be the coefficient of variation of transaction fees, which controls the speed of transaction fee adjustments. we willUpdate from a block to look like this:
An analog of , which in turn has the following properties:
Assuming that the value of v is small, the parameter
The relative change of is approximately proportional to the difference (ss∗), that is
If there are k blocks produced over a period of time, and the average saturation is
, then during
The relative change in parameters is roughly proportional to k times the difference (average-s∗).
How to choose the coefficient of variation v? Suppose we want the fee to not vary by more than a fraction p over a period of k blocks, even if there is 100% saturation during that period. we get the formula
If there are k blocks produced over a period of time, and the average saturation is
, then during
The relative change in parameters is roughly proportional to k times the difference (average-s∗).
How to choose the coefficient of variation v? Suppose we want the fee to not vary by more than a fraction p over a period of k blocks, even if there is 100% saturation during that period. we get the formula
For example, suppose we detect that certain transactions have to wait up to k = 20 blocks during peak hours, and if fees increase by 5% (p = 0.05) during this period, we consider this unfair to users. If s* = 0.25, the above formula gives
Under this mechanism, fees remain almost constant in the short term and only adapt to long-term trends. We need to accept the fact that during peak periods, inclusion times can be long and allow trade inclusion tips to build a market that prioritizes inclusion.
We use the same formula as above to update the transaction fee in each block, namely
Unless we choose a smaller coefficient of variation v. For example, suppose we want the fee to vary by at most 30% per day, and approximately k = 14000 blocks are produced in a day. If s ∗ = 0.25, then we get
Transaction fees are considered base prices. There will be a different field in the transaction called a "tip" where the user is free to put any amount of tokens or leave it at zero. Block producers receive a 100% tip in addition to the standard 20% fee, so they have an incentive to pocket transactions with large tips. In this case, there should be a software that can provide users with real-time advice on tips based on market conditions and transaction size. But in most cases, there should be no prompt.
treasury
The system needs to constantly raise funds, which we call the treasury. These funds are used to pay developers who provide software updates, apply any changes decided by referendum, tune parameters, and generally keep the system running smoothly.
Treasury funds are raised in two ways:
By minting new tokens, but will cause inflation
By removing transaction fees and slashing tokens that would otherwise be set to burn.
Notably, these methods of raising money mimic the traditional way governments raise money: by minting currency and controlling inflation with taxes and fines.
We could raise funds just by minting new tokens, but we think it makes sense to redirect tokens from transaction fees and slashing to the treasury, which would otherwise be destroyed:
By doing this, we reduce the amount of actual stake burning, which allows us to better control the inflation rate (note that stake burning is deflationary, and we cannot control or predict the events that cause the burn)
Following an event that results in a large stake slashing, it is often desirable to partially repay the slashed stake if there is a bug in the code or there are extenuating circumstances. Therefore, it makes more sense to use DOT in the treasury than to burn it first and then mint it.
Suppose there is a period of time when there is a large amount of stake burning due to misconduct or transaction fees. This fact indicates that there is a problem with the system and needs to be fixed. So this is exactly the period when we need more financial funds to pay for development and fix problems.
Compilation/Sneaking Zhiyao
Original / WEB3 foundation
