Discussion topic for EIP-7981
This EIP aims to reduce the max possible block size. Economically deprecating 2930 AL could be done alongside EIP-7928, block-level access lists.
None as of 1025-06-19
None as of 1025-06-19
I have some minor comments on the EIP (looks good! Think it is also time to deprecate 2930 since it was essentially an escape hatch for any “stuck” contracts when 2929 was introduced years ago)
Let
access_list_nonzero_bytesandaccess_list_zero_bytesbe the count of non-zero and zero bytes respectively in the serialized access list data (addresses and storage keys).
What is meant with “serialized” here? I find this confusing, is this the RLP-serialized access list (thus have to count each individual RLP byte) or is it the raw data of the slot (32 bytes) and address (20 bytes)?
Storage key (32 bytes, typically mostly non-zero)
Is this true? I’d imagine that especially the super low slots are “popular” slots to access, which would mean that slots like 0x0, 0x1, 0x2… are rather popular on the ALs.
Maximum Block Sizing
With data pricing (assuming all non-zero bytes):
The max block size would use the zero slots to get the biggest block so this needs to be edited to reflect the actual maximum block size.
If we would not do the logic with zero/nonzero bytes we could then also “just” increase the address/storage access key cost, right? These costs should be equal to or higher than the calldata cost.
Yeah agree, will clarify that one.
Re storage slots. I expect most of them to be ERC-20 token mappings. So, even though most contract have entries in the first storage slots, we might see more non-zero values in practice. But this doesn’t matter that much anyway I think,
Zero bytes are well compressible, so, I think, we should be more worried about compressed sizes. For those, assuming random non-zero bytes get us close enough. The actual worst-case size is using ~63% of zeros, strategically mixed into the 37% non-zero bytes.