-
Notifications
You must be signed in to change notification settings - Fork 377
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[META] Revisit gas price strategies #7095
Comments
@ezdac feel free to add anything I missed above! |
Some considerations for a manually implemented gas-price strategy: ConstraintsOne problem in calculating gas-prices is that of node-locality: we can only observe the current gas-prices in our mempool and don't have a global view of the network's txpool. A better gas-oracle would aggregate the txpool of several nodes, but we don't want to rely on external services too much. GoalsTransactions are supposed to be rare in Raiden and there are 2 (mostly adverse) dimensions to optimise for - economic feasibility and block-inclusion time. I would consider us having two kinds of transactions: Non-Time critical transactions:
Here timing might not be important, and a user very likely favours economic feasibility over time. Settlement transactions
Those transactions are mostly time critical and for the challenge period it is crucial to get tx's in the blockchain in order to not lose funds. Possible solution:
If initial tx sends will fail (being stuck in the txpool for longer than expected), a follow-up transaction with significatly higher gas price should be made.
For a schematic representation of the idea:
This curve initially targets the normal time based gas-price strategy, and scales up the importance and thus gas-price the closer we get to the target block. It assumes that we observe high upwards fluctuation in gas-price that make the historical, running average based strategy unfeasible for future predictions. Problems:
|
What are multiple transactions regarding one channel? Like UpdateNonClosingBalanceProof and Settle? |
Don't forget the |
|
In general, I believe solving this gas-induced finality problem is really hard (if not impossible), and there is potential that if we're not careful with this we overspend.
That would be a good idea for a first step in a multi-step process - providing a manual endpoint where the user can decide how much the tx is worth to him
What I meant is "topup" transactions, that represent the same action we want to take, but (hopefully) supersede the older, pending transaction. There is the possibility that both the pending AND the topup transaction will get included in a block, which is not good for the economic feasibility of the action. This is especially true if we are e.g. close to the cutoff block in the curve above, and the stakes in gas are high.
So the sum of gas-cost for all inflight tx for a particular action may never be higher than the action is worth |
I wonder how all the front-running bots do this - there must be quite some research and competing algorithms in this field |
This is impossible. Top up transactions share the same (Ethereum) nonce. Basically, it is the same transaction with the same nonce but a higher gas price. Once, any of these transactions gets included into a block, all other transactions become invalid as they use an already used nonce. Thus including two transactions from the same address with the same nonce into a block, makes the whole block invalid. Thus, economic feasability should not be affected by this. |
To my knowledge, these bots simply scan the transaction pool of pending transactions and base their price on the findings in txpool. typically frontrunning bots want to frontrun a specific transaction, so they only need to put their transaction in with the higher gas price (often seen with only higher by one WEI). |
Mh, I misunderstood something conceptually here severely. True, we use the same nonce here and don't increase it. |
One other thing which comes to my mind. Do we have taken into account that EIP-1559 is scheduled for mid July which will have a big impact on the whole gas pricing mechanism? If I got my head around it correctly, it will much more reliable to have a certain price at which you can be sure that your transaction gets included into the block. Only the worst case scenario will lead to the same model as we have it now (which should happen very rarely). |
Just skimmed EIP-1559, here is a quick and rough TL;DR for the parts relevant to our discussion:
# priority fee is capped because the base fee is filled first
priority_fee_per_gas = min(transaction.max_priority_fee_per_gas, transaction.max_fee_per_gas - block.base_fee_per_gas)
# signer pays both the priority fee and the base fee
effective_gas_price = priority_fee_per_gas + block.base_fee_per_gas
The overall problem we try to solve remains still the same, although it might be less likely that we have to topup transactions in order to get them included before a target block. For our gas-strategy this would potentially mean:
Probably it should be something like: where:
The price-capping around |
Decision by the team: As a first step, expose an endpoint where a user can top up manually transactions and show transactions. This is not best UX but a user always can make transactions not starve. Afterwards we can automise and optimize. Additionally, we wait for environment change with EIP-1559 |
Abstract
In the course of the scenario player runs on
goerli
we encountered a lot of problems with too low gas price estimations, when the gas prices in the network fluctuate a lot. The naive assumption is, that the web3-py provided gas price strategy forfast
should still work in those cases, but apparently it does not. On top of that, we don't have any strategy for speeding up "stuck" transfers that were already sent. We shouldMotivation
Raiden does not expose interactive gas price adjustments -- it also is not straight forward to introduce such a feature, because on chain transactions are most of the time the worst-case scenario and need to happen automatically (e.g. "publish a secret", "update the non closing balance proof"). Also, signed transactions do not have an expiry. Failure to have a transaction mined before a deadline can lead to actual token loss or at least extra cost for the gas wasted on the too-late transaction plus service cost. There is also a usability component to this: if transactions are stuck due to a too low gas price, the channels can stay in an unusable state for long periods of time.
There is also the other side: paying too high gas prices takes away some of the monetary benefits of using L2 for token transfers. Therefore optimizations of the employed gas price strategy have a strong impact on the viability of Raiden.
Other projects
While this ticket is concerned with the python implementation of the Raiden client, gas price strategies are important, too, for
Backwards Compatibility
This does not have implications for backwards compatibility.
Solution
Internal design / implementation
Current state
Transactions are "implicitly" executed via either
RaidenEventHandler
as the result of events dispatched from state transitions via the state machine.In both cases the resulting transactions are not visible / accessible from outside the executing functions and therefore can't be interacted with.
Proposed solution (July 2021)
To allow transactions to be both visible to the user as well as replaceable, cancelable etc. a
TransactionHandler
(or similar name) should be added that takes over the handling of transactions.This handler should support the following actions:
Either:
The transaction handler should be accessible via e.g. the
RaidenService
and be used in all places where we currently directly submit transactions.Pseudo interface:
TransactionHandler
.submit(tx: TransactionEstimated) -> TransactionMined
.__iter__() -> Iterator[<SomeTxIdThatIsNotBasedOnTheActualHash>]
.increase_gas_price(tx_id: <SomeTxIdThatIsNotBasedOnTheActualHash>, new_gas_price: int)
.cancel(tx_id: <SomeTxIdThatIsNotBasedOnTheActualHash>)
(Alternatively instead of using opaque ids an object could be returned that has
.increase_gas_price()
and.cancel()
methods).In the next step automated handling of gas price increases can be added on top.
The text was updated successfully, but these errors were encountered: