EIP-3521: Reduce access list cost

EIP text here: https://eips.ethereum.org/EIPS/eip-3521

Inspired by this comment: EIP-2930: Optional access lists - #31 by AusIV

1 Like

Generally lgtm, but since this EIP wants to fix it properly, I do have some nitpicks

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.

I think it would be good to clarify exactly what “as calldata” means. The address is the full 20 bytes, but should that address also be subject to 0-byte counting? Seems like it would be simpler to not do that, but instead just charge 16x20=320, So instead of paying 2400 for it, you’d pay 320.

Or in other words (which avoid the use of ‘first occurrence’), I would describe it something like this:

If tx.to is part of the 2930-declared access list (i.e. before adding the freebies), deduct 2080 from the tx cost.

Thanks for the feedback. The main reason for wording "as calldata" was to try and inherit the calldata calculation. Although I generally prefer the way you’ve worded it, introducing a constant 320 cost is just another protocol parameter to keep track of. If the cost of calldata changes, we also have to worry about changing this parameter. This is a relatively minor concession though, so it’s probably fine to move forward with the constant.

1 Like

As someone who has many zero-bytes in their addresses, I agree with the inheriting of the calldata calculation. I would also support extending it to the other unbounded-size transaction parameters, and other duplicated entries in the list.

One more thing I’d like to comment about this EIP in general.
This EIP solves one problem, making it easier to decide “should I include address X” or not. However, it should be pointed out that this problem is a bit more difficult than that, and we can’t really solve it.

Say for example that a user calls an eth_getAccesslist, and gets a list of all addresses/slots that are touched during exeution. Let’s say the user knows that the accesslist shaves of 10%, and “by default” always does this and includes the access list.

Now, from the time this estimation was done, to the time it was included in a block, things may have changed. It might be some defi bid on some order that was picked up by someone else, or some auction that was just closed.

In the “regular tx” case, the tx would fail pretty early. The contract would look up what it needs to look up, find that the order is now invalid, and exit, having touched only a few slots and made no external calls.

So in this case, a full “access list tx” with N addresses and M slots would still pay for all those accesses that never happened.

Just throwing it out there, that the decisiion of whether to include an access list in a transaction or not to is not necessarily an easy question to answer. It was required to handle broken flows, but it’s probably not a good default – it might be later, if the discrepancy between pre-declared and runtime-added costs is enlarged further.

With that said, I don’t really see this EIP as particularly important (as in, no urgency in getting it in), since it only solves one already pretty simple part of a more complex problem.


Yep, that’s also a good thing to generally keep in mind.