Skip to content

Improve the fee statistics function required to provide optimal fees. #437

@MichaelKim20

Description

@MichaelKim20

If the number of transactions is small, it is difficult to filter out noise.
We've already used the cutting average to remove noise, but this is not perfect either.
In the process of developing Wallet, we found that high fees entered incorrectly could keep subsequent fees high.
Therefore, we need logic that is handled in a different way.

We have come to pay attention to the number of transactions that are currently being processed or have to be processed.
If the number of transactions that have not been processed during the recent N block and remain in the transaction pool is Np,
It can be seen that the load of the network is directly proportional to the value of Np.
Therefore, transaction fees are directly proportional to the network, which is also directly proportional to Np+Nb.
Therefore, the formula is summarized as follows.

fee = 0.01 + 0.00002 * Transaction Size
if fee < 0.01 then fee= 0.01
Transaction Fee = a * log(Np+1) + fee
When a = 0.01
Np = 100 => Transaction Fee : about 0.03
Np = 1000 => Transaction Fee : about 0.04
Np = 10000 => Transaction Fee : about 0.05

Because it changes too sensitively depending on the number of transactions, it is recommended to apply it when the value of Np exceeds a certain quantity.
And Np should be measured at least in the previous six blocks.

Metadata

Metadata

Assignees

Labels

No labels
No labels

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions