Extend gas optimization for eth_createAccessList#8261
Extend gas optimization for eth_createAccessList#8261yperbasis merged 2 commits intoerigontech:develfrom
Conversation
There was a problem hiding this comment.
I agree that it makes sense to extend the gas optimization to the sender and, since Shanghai, to the block producer. For precompiles it's a moot point because they don't have any storage. Created contracts, however, are not pre-warmed-up and so it's cheaper to warm them up explicitly with an access list. EIP-2929 & EIP-3651 list all pre-warmed-up accounts.
|
It makes sense that this change would not have an effect for the precompiles then.
I interpreted this as |
Yes, you're right. |
|
|
||
| // Retrieve the precompiles since they don't need to be added to the access list | ||
| precompiles := vm.ActivePrecompiles(chainConfig.Rules(blockNumber, header.Time)) | ||
| excl := make(map[libcommon.Address]struct{}) |
There was a problem hiding this comment.
From & to should also be added to excl
There was a problem hiding this comment.
Is there a specific reason this should be handled both during tracing and after tracing? As I understand it, the resulting access list would be the same.
The way it is handled now excl also has very clear semantics of "this address should under no circumstances appear in the access list", which would make it easy to use with user-provided addresses as well. Whereas using excl for to and from would require differentiating between addAddress and addSlot again.
There was a problem hiding this comment.
I was worrying about preserving backwards compatibility in the non-optimized case, but perhaps it's not that important. Now I'm thinking about making optimizeGas the default unless set to false explicitly.
2 participants
This builds upon #3453 and #3524, which previously implemented gas optimizations for the access lists generated by Erigon's implementation of the
eth_createAccessListRPC call.Erigon currently optimizes inclusion of the recipient address based on how many storage keys are accessed, but does not perform the same optimization for sender address and precompiled contract addresses. These changes make the same optimization available for all of these cases.
Additionally, this handles the cases of block producer address and created smart contract addresses. If these cases were omitted on purpose since they heavily rely on state, it may still make sense to offer them to users but disable them by default.