Reduce access list cost
EIP-3521 proposes a reduction in the gas cost of access lists, which were introduced in EIP-2930 to mitigate the impact of gas cost increases on storage-accessing opcodes. The current gas cost of access lists is considered too high, making them less attractive for developers to use. The proposed reduction would make access lists more economically viable for applications that heavily rely on storage access. The reduction would be achieved by changing the way access lists are encoded and stored, which would result in a smaller size and lower gas cost. The proposed changes would not affect the functionality of access lists or their ability to mitigate contract breakage due to gas cost increases. The EIP also addresses potential security considerations, such as access list generation and transaction size bloating, and proposes solutions to mitigate these issues. Overall, EIP-3521 aims to improve the usability and effectiveness of access lists in mitigating the impact of gas cost increases on storage-accessing opcodes.
Video
Original
Simple Summary
Reduce the cost of declaring tx.to storage keys in access lists.
Motivation
Currently, a transaction must read at least 25 distinct storage slots in tx.to
before it's more expensive to forego an access list.
ACCESS_LIST_ADDRESS_COST + (ACCESS_LIST_STORAGE_KEY_COST + WARM_STORAGE_READ_COST) * x = COLD_SLOAD_COST * x
x = 24
EIP-2930 requires the address under which the storage keys reside be declared
explicitly, since it must be added to the EIP-2929 accessed_addresses list.
However, tx.to is a special case that is added by default, so paying
ACCESS_LIST_ADDRESS_COST for tx.to is essentially paying twice for the same
address. Avoiding overpayment here will reduce the differential to just 5 unique
reads before using an access list is cheaper -- making them a more attractive
option.
Specification
Treat the first occurrence of tx.to in an access list as calldata for gas
accounting purposes. Do not charge ACCESS_LIST_ADDRESS_COST for it. Storage
keys underneath the address are unaffected.
If tx.to == nil, tx.to is defined be the derived contract address created by
the transaction.
Rationale
Why charge at all?
EIP-2930 is specifically written to make access lists simple to reason about and
validate. It may be possible to modify the structure of the access list to avoid
including tx.to explicitly, but this would renege on the spirit of EIP-2930.
Why charge as calldata?
The cost of calldata was thoroughly analyzed in EIP-2028 to determine
a fair value that is not susceptible to denial-of-service attacks. We consider
this the lower bound on how much transaction data should cost. Since there is
no computation burden imposed for adding tx.to to the accessed_addresses
map (it's added by default by EIP-2929), there is no reason to charge more than
the absolute minimum for the data.
Test Cases
{
"0xffffffffffffffffffffffffffffffffffffffff": []
}
cost = 320
{
"0x00ffffffffffffffffffffffffffffffffffffff": []
}
cost = 308
{
"0xffffffffffffffffffffffffffffffffffffffff": []
"0xffffffffffffffffffffffffffffffffffffffff": []
}
cost = 2720
{
"0xffffffffffffffffffffffffffffffffffffffff": [
"0x00"
]
"0xffffffffffffffffffffffffffffffffffffffff": []
}
cost = 4620
{
"0xffffffffffffffffffffffffffffffffffffffff": [
"0x00"
]
"0xffffffffffffffffffffffffffffffffffffffff": [
"0x00"
]
}
cost = 6520
Backwards Compatibility
No issues.
Security Considerations
None.
Copyright
Copyright and related rights waived via CC0.
Adopted by projects
Not miss a beat of EIPs' update?
Subscribe EIPs Fun to receive the latest updates of EIPs Good for Buidlers to follow up.
View all