Adapt the fee for multi recipients transactions

[samuelmanzanera]

Description

The idea is to ensure a bulk transaction to be more cost efficient than multiple transactions.

Indeed, the validation is done one time versus multiple times.

The cost is then determined as logarithmic according to the number of recipients

Fixes #1041

How Has This Been Tested?

• Unit tests
• Multiple recipients sending with CLI

Checklist:

• My code follows the style guidelines of this project
• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation
• My changes generate no new warnings
• I have added tests that prove my fix is effective or that my feature works
• New and existing unit tests pass locally with my changes
• Any dependent changes have been merged and published in downstream modules

[Neylix]

I don't really agree with the log function for additionnal recipient.
Currently the entire validation process cost 1 cts. It represent the work done by welcome nodes, all validation nodes and the storage nodes of the transaction and the recipients.
This new fee calculation means that adding a recipient, which in fact adds only few calculation and one communication at the end with new pool of IO nodes, cost more than the entire validation process.

For me it looks strange to have more cost for something that takes less resources.

Addionnaly, doing this means that sending 2 differents transactions cost less fees than a single transaction with multiple recipients. But for the network, 2 transactions takes way more ressources than a single transaction.

It's like if I go to the garage and it cost me 50$ to change a wheel, but 120$ to change 2 wheels while it should be 100$ or less since there is a common setup for 1 or 2 wheels

[samuelmanzanera]

I don't really agree with the log function for additionnal recipient. Currently the entire validation process cost 1 cts. It represent the work done by welcome nodes, all validation nodes and the storage nodes of the transaction and the recipients. This new fee calculation means that adding a recipient, which in fact adds only few calculation and one communication at the end with new pool of IO nodes, cost more than the entire validation process.

For me it looks strange to have more cost for something that takes less resources.

Addionnaly, doing this means that sending 2 differents transactions cost less fees than a single transaction with multiple recipients. But for the network, 2 transactions takes way more ressources than a single transaction.

It's like if I go to the garage and it cost me 50$ to change a wheel, but 120$ to change 2 wheels while it should be 100$ or less since there is a common setup for 1 or 2 wheels

In fact, this addition with log, ensure than multi recipients would cost less than many transactions.
Hence, there is an incentive to a do bulk transfer, as it would resolve into less resource consumption for the end to end workflow.

There is a property testing trying to ensure this assertion.
This was the goal of this PR to have this kind of calculation at the end.

[Neylix]

I don't really agree with the log function for additionnal recipient. Currently the entire validation process cost 1 cts. It represent the work done by welcome nodes, all validation nodes and the storage nodes of the transaction and the recipients. This new fee calculation means that adding a recipient, which in fact adds only few calculation and one communication at the end with new pool of IO nodes, cost more than the entire validation process.
For me it looks strange to have more cost for something that takes less resources.
Addionnaly, doing this means that sending 2 differents transactions cost less fees than a single transaction with multiple recipients. But for the network, 2 transactions takes way more ressources than a single transaction.
It's like if I go to the garage and it cost me 50$ to change a wheel, but 120$ to change 2 wheels while it should be 100$ or less since there is a common setup for 1 or 2 wheels

In fact, this addition with log, ensure than multi recipients would cost less than many transactions. Hence, there is an incentive to a do bulk transfer, as it would resolve into less resource consumption for the end to end workflow.

There is a property testing trying to ensure this assertion. This was the goal of this PR to have this kind of calculation at the end.

Indeed ... It was late, didn't do the right calculation

[bchamagne]

Question: why do we change the protocol_version?

[samuelmanzanera]

Question: why do we change the protocol_version?

Because we still need to valid previous transaction's fee with previous algorithm