MASQ-Project
`BlockchainAgent`'s smart setup of the gas price
Note: This is an optimization card. It could be added on top of GH-638 which lay down the bare minimum of this functionality. Unlike to the advancement this card here offers, the fundamental card only get the BlockchainAgent in and give it some simple abilities to provide a gas price value which is amplified from the recommendation we get from the web. Also, it will only apply a single value to all the transactions that are supposed to make up the batch.
Implement new piece of logic that will be attributed to the BlockchainAgent trait. Imagine that we are in the middle of the process of preparing the batched transactions to be sent out very soon. We're talking about what is going in within the Handler of OutboundPaymentInstructions which is the message coming from the Accountant after passing the PaymentAdjuster which is, among other things, responsible for composing this message. The message is special in the regard that it contains a trait object which is in fact the BlockchainAgent itself.
Add a method to the abstract interface of the BlockchainAgent. It should return a whole set of gas prices, each belonging to a single transaction from the planned batch.
The main idea is that we can implement one or possibly even different configurable strategies to be applied on determining some kind of optimal gas price heights. We do care about the selection because the queried recommended average gas price fetched from the blockchain service provider:
a) must be approached with reservations (we probably always want to pay a bit more than that to ensure a smooth processing)
b) we are dealing with batched payments; thus, we need to take into account that each next transaction could be diverging from the originally fetched gas price and it may be much desirable to add them some extras compensating this projected potential gas price fluctuation
Why BlockchainAgent? It's very purposeful. This class is meant to abstract away from the differences between various blockchains. Because each blockchain has its specifics and we want to address them, we also can implement a different calculus arranging the transaction fees according to parameters of the referred network.
@utkarshg6 has more specific ideas about the algorithm. Apparently, it would derive from the transaction count in the batch. Anyways, this is just roughly:
Approach 1
The same gas price is given to all payments but it is inflated by a computed margin. (This is different from the original idea of margin attempted to be introduced in the card with the PaymentAdjuster. Because there was just a constant value considered. However, this card would allow to compute the right level of fee from the number of payments).
Approach 2
We can assume that with the first transaction in the batch, we're nearest to the currently queried on-blockchain consensus value. The more we go further from that one across the remaining transactions, we should be incrementing the gas price assigned those transaction, with the largest value at the last one. The question of coming to the increase size can be solved in some way of percentage increase (e.g. 2%) towards the previous value.
