You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Extension of #3221, this issue is for a bug while this one is for a general optimization of the stability pool mechanism (eventually both are completed in the same PR)
Current mechanism
For each connected chains, a "gas stability pool" exists that is funded manually and with remaining fees from previous transactions
We store in the blockchain "gas stability flags" that describes how gas price must be increased with gas stability pool
At each epoch (configurable number of blocks), the pending cctxs are iterated and depending for how long it has been pending, the gas price is increased by a percentage from the flags, there is a percentage limit for max gas price. The difference of gas limit is funded from gas stability pool (then unused fees are resent unto the pool)
Some issues with the current mechanism
The increase is a fix percentage in the flags, independent of the gas price hikes, for very big hike in the price, the flags might be ineffective, if the flags are set to high percentage then it is not optimized for smaller gas price hike
Multiple outbounds are increased at the same time, outbound+100 might be increased while outbound+1 is blocked, all the pending outbound are increased, the gas price might again fall once the blocked outbound get signed, this might end up in a big waste of funds with unnecessary high gas price for most outbounds
The current mechanism is not adapted for EIP1559 since the increase for gasFeeCap and priorityFee might not be the same
Proposed solution
Update with more accurate values: remove the gas increase percent flag, instead when iterating pending outbound, the increase is determined by the current voted gas price. The difference in the fee limit is used for the gas stability pool. For EIP1559 both gasFeeCap and priorityFee are updated with the voted values
Having less look ahead and bigger focus on currently blocked outbound. Instead of iterating n+x next outbound, only the n+1 pending outbound is parsed (we can maybe tolerate a few ore but idea is to have a very small look ahead), it is parsed more frequently (smaller epoch), the gas price is updated if any of two conditions are met (been pending for a x delay OR the current voted gas price is above a threshold of the gas price currently used). If the gas price is increased while the tx has been signed and is being confirmed, this is not an issue as the effective fee paid will be used to refund to the gas stability pool.
In short the gas stability mechanism is more concentrated to the currently blocked outbound. There will be slower time to update gas price of all outbound in gas of dramatic hike in the price and large number of outbound in a short time frame but use of the gas stability pool will be made more optimized.
The text was updated successfully, but these errors were encountered:
Extension of #3221, this issue is for a bug while this one is for a general optimization of the stability pool mechanism (eventually both are completed in the same PR)
Current mechanism
Some issues with the current mechanism
Proposed solution
In short the gas stability mechanism is more concentrated to the currently blocked outbound. There will be slower time to update gas price of all outbound in gas of dramatic hike in the price and large number of outbound in a short time frame but use of the gas stability pool will be made more optimized.
The text was updated successfully, but these errors were encountered: