EVM: remove contract storage slot when setting to 0

[TorstenStueber]

In EVM, some gas will be refunded to the transaction origin whenever a storage slot is set to zero.

In revive, there is already a complete apparatus for executing storage deposit refunds, however, it is not triggered when a storage slot is set to zero.

This logic would need to be implemented in the write_raw function of ContractInfo. Here we calculate a diff that records how many bytes have been added or removed and how many items have been added or removed. Whenever the new value of the slot is 0, we are currently just writing the value 0 into the child trie under the given key. Therefore no bytes or storage slots are removed and the storage deposit meter will not register a refund.

We can change this: if the current contract is an EVM contract, then every storage slot is always occupying a 256-bit word (32 bytes). That means that we can treat storage slots that are not in the child trie as zero and therefore whenever the new value for a storage slot is zero, we can just remove that respective entry from the child trie, create an appropriate diff and ensure that the caller gets a refund.

Important: this only works if the current contract is an EVM contract, so we need to check for that.

[0xRVE]

We can either fix this in polkadot-sdk/substrate/frame/revive/src/vm/evm/instructions/host.rs which is easy. Then it will only affect EVM contracts so that writing 0's to storage from an EVM contract means deleting the storage item and getting a refund.
https://github.com/paritytech/polkadot-sdk/blob/698283eaa5793d276df09c3527b83f38e30b11c0/substrate/frame/revive/src/vm/evm/instructions/host.rs#L149

Or fix it in polkadot-sdk/substrate/frame/revive/src/storage.rs which is a bit more difficult because it breaks a bunch of tests and I am not 100% sure if those breakages are trivial. If we go this route both EVM and PVM will have the same behaviour: writing 0's to storage means deleting the storage item and getting a refund.
https://github.com/paritytech/polkadot-sdk/blob/698283eaa5793d276df09c3527b83f38e30b11c0/substrate/frame/revive/src/storage.rs#L317

[TorstenStueber]

We must not enable this behavior for PVM because in PVM storage slots can have different sizes and therefore we can't just handle writing zero bytes to a storage slot by removing the slot from the trie because the information about the length gets lost.

In EVM a slot is always 32 bytes and therefore there is no such danger.

[xermicus]

Not sure if I am following correctly but there are dedicated PVM syscalls which already do this. No changes that affect the PVM backend are needed.

[TorstenStueber]

Correct, PVM does this already correctly anyway. We just currently never trigger storage deposit refunds for EVM contract slots even if the Solidity code executes a delete.