New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

New Opcode: SSTORE_COUNT #119

Open
pirapira opened this Issue Jun 20, 2016 · 5 comments

Comments

Projects
None yet
7 participants
@pirapira
Copy link
Member

pirapira commented Jun 20, 2016

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

This comment has been minimized.

Copy link
Collaborator

vbuterin commented Jun 20, 2016

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 comment has been minimized.

Copy link
Member Author

pirapira commented Jun 21, 2016

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

This comment has been minimized.

Copy link
Contributor

chriseth commented Jul 5, 2016

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

This comment has been minimized.

Copy link
Collaborator

vbuterin commented Aug 27, 2016

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

This comment has been minimized.

Copy link
Member

axic commented Sep 14, 2016

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).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment