-
Notifications
You must be signed in to change notification settings - Fork 20.1k
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
internal/ethapi: Set basefee for AccessList
based on given block, not chain tip
#30538
base: master
Are you sure you want to change the base?
Conversation
…etting NoBaseFee will disable subsequent validation
…all-like operation)
AccessList
dynamic fee calculationAccessList
based on given block, not chain tip
Yeah I think it makes sense. We shouldn't need to estimate actual gas prices or gas limit. Sure those can influence EVM execution but the user can pass in those if they care/their contract depends on it. Only one thing I noticed: not filling the nonce causes the |
So this would mean that this is broken in all |
It's not broken. The reason is that the nonce during creation is sourced from the state of the account, not what's in the transaction args. |
Yep for eth_call it's not broken but here it will be when using CallDefaults. It's because CreateAccessList uses the nonce from tx args and passes that to the tracer. We could either here use account state, or modify the tracer to use OnEnter && level == 0 to get the |
|
internal/ethapi/api.go
Outdated
args.Nonce = &nonce | ||
} | ||
blockCtx := core.NewEVMBlockContext(header, NewChainContext(ctx, b), nil) | ||
if err := args.CallDefaults(b.RPCGasCap(), blockCtx.BaseFee, b.ChainConfig().ChainID); err != nil { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
the setDefaults
has a lot of logic handling blobs that are passed in the args, and that will become broken if we just change this
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We could just call setBlobTxSidecar
in CallDefaults. But I'd say it's OK not to support them here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
But setDefaults
will set the fee defaults on the latest block.
if err := args.setFeeDefaults(ctx, b); err != nil {
return err
}
And regardless of what order we invoke it, it will use the latest header, and do
if err := args.setCancunFeeDefaults(ctx, head, b); err != nil {
return err
}
SO it will apply cancun checks according to tip
, regardless of what the given block is.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How about something like this
// setFeeDefaults fills in default fee values for unspecified tx fields.
func (args *TransactionArgs) setFeeDefaults(ctx context.Context, b Backend) error {
return setFeeDefaultsUsingThisHeader(b.CurrentHeader())
}
func (args *TransactionArgs) setFeeDefaultsUsingThisHeader(ctx context.Context, b Backend, head *types.Header) error {
// Sanity check the EIP-4844 fee parameters.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
the setDefaults has a lot of logic handling blobs that are passed in the args, and that will become broken if we just change this
The logic there is to fill in blob proofs and commitments if they were not provided. Those matter only when submitting a tx. Since for a simulation all that can be accessed via evm is blob hashes (which still can be passed in via TransactionArgs).
All in all I think I agree with @jwasinger that CallDefaults is a better validation function to use here. All the methods that involve signing and submitting a tx use setDefaults
while all the "simulation" methods use CallDefaults.
…with proper values. modify setFeeDefaults to take a historical header value (doesn't work if EIP-1559 is disabled. everything other than AccessLists, which were introduced after/same-time (?) as 1559, calls setFeeDefaults with current block header.
totally WIP, and I'm not sure this is correct. I need to further validate this tomorrow.
Should close #30145 . The problem is that for
AccessList
, we are filling transaction fields withTransactionArgs.setDefaults
which afaict is meant to validate provided fields and give proper values to missing fields based on the state at the current chain tip.eth_call
-like methods seem to populate fields usingTransactionArgs.CallDefaults
, which also seems appropriate foreth_accessList
as it iseth_call
-like under the hood: it can be executed against historical blocks.The referenced issue reflects this: if we calculate defaults for the transaction's dynamic fee fields based on the chain tip, but re-execute against a historical block, then we can encounter a situation where the calculated default for the gas tip is below the base fee of the historical block.