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
They were added incrementally as attempts to debug an ongoing intermittent problem related to insufficient gas. This is confusing and in some ways not correct.
web3py (everyone, really) uses these parameters for a transaction:
If we override gas we are saying "this is the max gas (in units of gas) that I will pay for the transaction." It defaults to an estimate based on the tx details. This is problematic because the user does not know how much gas any given transaction should cost. It's possible to calculate this, but that calculation is tedious and requires a good amount of expert knowledge, including knowing where to look for the fn in the smart contracts.
Additionally, the way we implement the other two parameters (base fee & priority fee max) was incorrect and partially fixed in #1496.
Partial solution
We want to specify this limit in units of base, so the user can say "I don't want to pay more than X base for this transaction". if we assign that value to a new config, e.g. transaction_gas_fee_limit, and also include a similar base denominated parameter for priority fee, then we can back out the tx parameters as such:
# user specifies the most they will pay on the txn gas and the priority fee ("tip") for any txconfig.transaction_fee_limit: FixedPoint# provided by the user, in units of baseconfig.priority_fee_limit: FixedPoint# provided by the user, in units of base# get these values from the web3 estimates for the given txgas=web3.eth.estimate_gas(tx) # the estimated gas cost for this transactiongas_price=web3.eth.generate_gas_price(tx) # the current price (in base) of one gas, aka baseFeePerGastotal_gas_fee=gas*gas_price# total amount that the tx will cost, in base [gas * base/gas = base]# set these values from user preferencesmax_priority_fee_per_gas=config.priority_fee_limit/gas# the user's max priority fee per gas in units of basetransaction_fee_limit_per_gas=config.transaction_fee_limit/gas# the user's max transaction fee per gas in units of base# add a check to ensure they're allowing for enough gas feeasserttransaction_fee_limit_per_gas>=2*gasmax_fee_per_gas=max_priority_fee_per_gas+transaction_fee_limit_per_gas# the maximum fee the user will spend per gas on this txTRANSACTION_DEFAULTS= {
"value": 0,
"data": b"",
"gas": gas,
"gasPrice": gas_price,
"maxFeePerGas": max_fee_per_gas,
"maxPriorityFeePerGas": max_priority_fee_per_gas,
"chainId": lambdaw3, tx: w3.eth.chain_id,
}
The text was updated successfully, but these errors were encountered:
After discussing with @slundqui and @wakamex we decided that we do not want to be so opinionated about what units the user wants to use to specify these constraints. Instead, we think it is best to explicitly expose all of these parameters:
We haven't settled on what level of the hierarchy we want for these arguments. They maybe shouldn't be the same. We may want to give the user access to defaults (via chain or pool config) but then also have the ability to override the default on any relevant function call as a function argument.
Problem
We currently expose three different variables for limiting gas:
They were added incrementally as attempts to debug an ongoing intermittent problem related to insufficient gas. This is confusing and in some ways not correct.
web3py (everyone, really) uses these parameters for a transaction:
If we override
gas
we are saying "this is the max gas (in units of gas) that I will pay for the transaction." It defaults to an estimate based on the tx details. This is problematic because the user does not know how much gas any given transaction should cost. It's possible to calculate this, but that calculation is tedious and requires a good amount of expert knowledge, including knowing where to look for the fn in the smart contracts.Additionally, the way we implement the other two parameters (base fee & priority fee max) was incorrect and partially fixed in #1496.
Partial solution
We want to specify this limit in units of base, so the user can say "I don't want to pay more than
X
base for this transaction". if we assign that value to a new config, e.g.transaction_gas_fee_limit
, and also include a similar base denominated parameter for priority fee, then we can back out the tx parameters as such:The text was updated successfully, but these errors were encountered: