New Opcode: SSTORE_COUNT

[pirapira]

Opcode 0x3d will be assigned a mnemonic SSTORE_COUNT. This instruction pushes the number of SSTORE executions by the currently executing account so far during the current transaction. The instruction takes no arguments.

The SSTORE counter is shared by all recursive invocations of an account. The counter is reset for each transaction. The gas cost of SSTORE_COUNT should be G_step as other 0x30s instructions.

USAGE

A contract can call this instruction twice to check if its storage has possibly changed. For instance, a contract can use this instruction before and after a call, to see if its storage has not been altered in a recursive-call to itself. The contract can use SSTORE_COUNT optionally together with BALANCE to make sure that its state is the same as before.

The SSTORE counter is separate for each account, preventing side-channel information leakage.

SCHEDULE

This is relatively easy to implement, so we can aim at: METROPOLIS_FORK_NUM.

ALTERNATIVE

An instruction returning storageRoot can serve the same purpose but is computationally more expensive.

[vbuterin]

What would this provide that a simple mutex lock (ie. prefacing the entire code with if self.mutex: ~invalid() and then wrapping mutexed calls like so seq(self.mutex = 1, foo.bar(baz), self.mutex = 0)?

[pirapira]

This instruction allows an execution to protect itself from untrusted executions of the same account. Mutex requires cooperation between multiple executions of the same account (in case of re-entrance). With this instruction, only the original execution needs to follow a protocol to ensure its integrity.

Setting&resetting a mutex also consumes 4 times more gas than the usage presented.

[chriseth]

Having access to the storage root of an account can also enable other use-cases. It is more general than the SSTORE_COUNT because it also allows the case that storage content is re-set.

On the other hand, if we give the EVM access to the storage root, any change in the storage trie structure would be a breaking change for the EVM.

[vbuterin]

On the other hand, if we give the EVM access to the storage root, any change in the storage trie structure would be a breaking change for the EVM.

It would also make caching much more difficult.

[axic]

I think this could also be used by view / pure functions in Solidity when they call an outside library method which is not inlined (internal).

[github-actions]

There has been no activity on this issue for two months. It will be closed in a week if no further activity occurs. If you would like to move this EIP forward, please respond to any outstanding feedback or add a comment indicating that you have addressed all required feedback and are ready for a review.

[github-actions]

This issue was closed due to inactivity. If you are still pursuing it, feel free to reopen it and respond to any feedback or request a review in a comment.