PIP-31: Consumptional Fee Model

[Ja7ad]

PIP-31: Consumptional Fee Model

[Ja7ad]

Unit Price
The unit_price would define the fee per byte in PAC. This parameter would be part of the node configuration, allowing each validator to set their preferred value.

The default value for unit_price is proposed to be set at 0.01 PAC?

With a unit_price of 0.01 PAC, the 148-byte transaction would cost 1.48 PAC, which translates to $0.74 (0.5 USD/PAC). For many users, this might feel high, especially for smaller transactions.

By reducing the unit_price to 0.0001 PAC:

A 148-byte transaction would cost 0.0148 PAC, or $0.0074.

This is much more reasonable for smaller, frequent transactions while still generating fees to secure the network. I think 0.0001 PAC would be a more optimal value.

@b00f @Mr-HoDL58 @akbariandev @alidevjimmy

[Ja7ad]

The default value for daily_limit is proposed to be set at 300 bytes?

Typically, transactions range between 150 to 200 bytes if they include a memo. It's possible that users could send 1 or 2 free transactions per day. For those who make smaller transactions, this provides a significant advantage and encourages more usage.

I think 300 bytes is optimal.

[Ja7ad]

Account Creation Fee
The Consumptional Fee Model could potentially allow attackers to send spam transactions. Since the fee for initial transactions may be minimal or free, an attacker could send transactions to non-existing accounts, which could then send transactions from those accounts to other new accounts, continuing the spam.

To address this, the Account Creation Fee proposes. This fee would be paid only the first time an account initiates a transaction and should be set sufficiently high to deter such attacks. Additionally, the balance of a new account must be at least equal to the account creation fee. This fee is defined as part of the consensus parameters and is not configurable. It is proposed to be set at 1? PAC.

In our last dev meeting, we decided that new accounts must pay this fee for the first 1~3 transactions before switching to the Consumptional Fee Model.

[Ja7ad]

Calculating Consumption

To calculate consumption, we can define a map that associates an address with the total size of transactions stored in the blockchain over the last 8640 blocks. When a new block is committed, we update this map by iterating over all transactions in the block and increasing the value for each address by the size of its transactions. Simultaneously, the block from 8640 blocks ago would be retrieved, and the value for each address would be decreased by the size of its transactions.

For store this details in map we don't have overhead for 8640 blocks (map[crypto.Address]uint16):

• Key size: 21 bytes (account address)
• Value size: 2 bytes (uint16)
• Overhead: Estimated at 8-16 bytes per entry for pointers, hash management, and bucket arrays

Total size = (key size + value size + overhead) * number of items = (21 + 2 + 8) * 8640 = ~259,200 bytes (or ~260KB) = (21 + 2 + 16) * 8640 = ~345,600 bytes (or ~346KB)

So, the map size is approximately 260KB to 346KB.

There are 2 issues:

1. Each time a node initializes, we need a consistent consumtional details, so we store accounts with transaction sizes in a map.
2. When a new block is committed, we need to block txs by updating this map based on the transactions (e.g., transfer, bond), increasing or decreasing entries accordingly.

[Ja7ad]

@b00f What do you think about increasing the unit_price based on block size during times of network congestion? We can currently measure block size.

• Each block has a maximum of 1000 transactions.
• The unit price can increase as the number of transactions per block grows.

For example:

• 0 ~ 250 txs = 0.0001 PAC
• 250 ~ 500 txs = 0.001 PAC
• 500 ~ 1000 txs = 0.01 PAC

Note: calculating consumptional fee is over network.

[moh-allahbakhsh]

I believe that this is an effective approach in network control as well as motivating and incentivizing users. So, I suggest using it in a multidimensional approach. In human-centric systems, we usually have the 80/20 rule, also known as the Pareto principle, It states that 80% of outcomes come from 20% of members. It might be applicable to Pactus as well, meaning that a large group of members are barely active, and a few users are always active. These members usually generate a large portion of transactions. Making transactions free or cheaper for nodes who have the fewer possible contributions is sort of punishing the people who are more active, or at least encouraging people to lesser their activities to be eligible for discount or incentive. .
With this justification, I would recommend changing formulation as follows:

• if ( 0 < n < a) then coefficient = x (e.g., 1)
• if ( a <= n < b) then coefficient = 0
• if ( n >= b) then coefficient = y (e.g., 2^n or something like that)

The intuition behind this formulation is that nodes are encouraged to have a minimum activity (between a and b) if they want to take advantage of incentives. These can motivate nodes to be more active in the network, and on the other hand prevent them from being hyperactive or spam it.

[Ja7ad]

This proposal in last dev meeting Accepted.

• Implementation issue: PIP-31: Consumptional Fee Model pactus#1540

[Ja7ad]

This proposal implemented and published on v1.6.0: https://pactus.org/2024/11/14/pactus-1.6.0-mumbai-released/