EIP 1884: Repricing for trie-size-dependent opcodes

I also saw that paper, but it seems a bit strange. Although the paper is pretty recent, the data seems to be old. The statement about BLOCKHASH being implemented as a smart contract is not true – it was like that in a PR which was never activated. That same PR also contained a mis-pricing of blockhash: https://github.com/ethereum/aleth/issues/5313

@jochem-brouwer I agree it might be ‘unfair’. But I think it’s more correct. Also, the opcodes that are priced low are statically charged. What you are proposing would make it dynamically charged, since we’d have to inspect the topmost stack element and compare with the context in order to determine the cost. That means (I think) that it couldn’t be priced at 5, but would have to go up a bit more. I’m not dead set on this, however.

In the general sense, I don’t particularly like it when evm gas pricing assume certain caching behaviour, since caches are unreliable. If we price something based on the assumption that a cache exists, then someone will try to make an attack that exhausts that cache, and once the cache is exhausted, we’re in trouble.

Regarding assumptions made on gas costs, I agree there aswell. This may break things, but it has IMO long been considered bad practice to hard code gas limits like that. I don’t think we can maintain current gas limits for the sake of badly written contracts, that will make the evm unusable.

1 Like