EXTSLOAD cost estimation

Notes:

1. The EIP-2330 specifies the cost of EXTSLOAD as G[EXTCODE] + G[SLOAD].
2. A core dev in Eth E&D suggested that G[EXTCODEHASH] + G[SLOAD] would be a better cost.

Issues with this pricing

Assumptions:

1. EIP-2330 is implemented
2. Someone inherits an abstract contract like this in their DeFiProtocol:

abstract contract Extsload {
    function extsload(bytes32[] memory slots) external returns (bytes32[] values) {
        for(uint i; i < slots.length) {
            bytes32 slot = slots[i];
            bytes32 val;
            assembly {
                val := sload(val)
            }
        }
        return values;
    }
}

contract DeFiProtocol is Extsload {
    // ...
}

Now let's consider someone wants to read 6 slots from DeFiProtocol, they can either use EXTSLOAD opcode or the extsload method.

If they use EXTSLOAD opcode to read the 6 slots, the cost would simply be 6 * (G[EXTCODEHASH] + G[SLOAD]). While if they use the extsload function, the cost would be G[CALL] + 6 * G[SLOAD] (including a bit of memory expansion and encoding decoding stuff).

Issue with this is, the currently specified pricing in EIP is more, and this experiment shows that the actual cost through other inefficient route turns out to be less.

Fix

Before an account / address is touched, it should be considered as cold account. Once it is touched using CALL, STATICCALL, DELEGATECALL, CALLCODE or EXTSLOAD it should be considered as warm address. This set of warm addresses (accessed_addresses) is implemented in EIP-2929.

• EXTSLOAD on a cold address should cost G[EXTCODEHASH] + G[SLOAD].
• EXTSLOAD on a warm address should cost G[SLOAD].

Also in addition to this concept, it should consider the accessed and non-accessed concept after berlin (doc).