EIP-2330: EXTSLOAD and ABI for lower gas cost and off-chain apps

Hi there topic is to discuss EIP-2330.
EIP: https://eips.ethereum.org/EIPS/eip-2330
Connected Solidity issue: https://github.com/ethereum/solidity/issues/7593
Aleth Implementation: https://github.com/ethereum/aleth/pull/5805

Ping @davesque & @simon-jentzsch with both of you I had a short chat in Osaka and I nearly forgot the details. But we discussed the idea for an EXTSLOAD instruction and corresponding Solidity ABI for the first time. Would be great if you guys could have a look at the first draft here provide and provide suggestions or comments for improvement.


To align with related opcodes, maybe a rename to extsload? (Like extbalance)

I don’t think the same gas price as sload makes sense, because sload assumes you have already paid the cost of loading the account from the state trie (via a call). It probably ought to be something like the sum of the gas cost of extbalance (load the account from the trie) and sload (load the slot from the storage trie).

1 Like

Yeah, both makes sense. I really like the the name EXTLOAD or EXTSLOAD for this as well. I’m going to add this to the pull request. In fact I think EXTLOAD would be the cleanest. Any thought on keeping or dropping the S?

S refers to storage and this is about external (account’s) storage load, so EXTSLOAD would be more fitting.


Thanks, I’ve updated both now in the EIP, higher gas cost (1500) and renamed to EXTSLOAD.

Proposal A new EVM instruction EXTSLOAD (0x5c) that works like SLOAD (0x54) with the gas cost of EXTCODE(700) + SLOAD(800) = 1500 and an additional parameter representing the contract that is to be read from.

Maybe you mean EXTCODEHASH instead of EXTCODE?

1 Like

I was referring to the Fee Schedule from the yellow paper:

There it is G_extcode_ = 700 and G_sload_ = 200 – just that EIP-1884 will update G_sload_ to 800 so I referenced that value.

1 Like

Love to see there is interest in this opcode! Please see this thread for an earlier discussion about it.

1 Like

This constant misunderstanding is probably the biggest reason for why we definitely should introduce this new opcode. Any developer who currently codes Solidity assuming non-exposed storage variables are in any way private is creating attack surfaces today. The “private” is an artificial attribute that does not actually exist in any meaningful way and just leads to confusion as some people in fact believe that the data would be protected in some way – while it is not. It’s open today, readable by anyone who cares to. If there is an “attack” transaction that can only be created by knowing the internal storage state of a contract then it can be created today already. EXTSLOAD would wipe out this misunderstanding making it clear to every developer that their contract storage data is always in the open. This would clarify documentation and language around this whole topic.

@anettrolikova is there a way to merge this and this thread?

Btw. I’ve added an Aleth implementation for this opcode https://github.com/ethereum/aleth/pull/5805

@dominic not sure what you mean by “merge threads” but I’m worried that’s not possible to merge thread on discourse :confused: