Skip to content
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

EIP-1712: Disallow Deployment of Unused Opcodes #4

Open
sorpaas opened this issue Jan 19, 2019 · 3 comments

Comments

@sorpaas
Copy link
Owner

commented Jan 19, 2019

No description provided.

@veox

This comment has been minimized.

Copy link

commented Jan 27, 2019

This will not work.

Most importantly, because if there are provisions to skip any data, then stuffing the data with a payload becomes a workaround.

As-is, there's no way to guard against, say, 0x615baf (PUSH2 JUMPDEST <UNASSIGNED_0xAF>).

A much weaker point is that if, as in this proposal, there's no provision to stop on encountering a STOP, then a majority of new deployments of Solidity contracts will fail, as solc tacks a hash value of the source code to the end of compiled bytecode.

While we can mostly argue that deploying unused opcode is not of much use so no sane developers would do that,

Deploying code with "unused opcodes" can be immensely useful for a generalised fork oracle.

(I'm not claiming sanity; I'm pointing out a valid use case for the pattern.)

@sorpaas

This comment has been minimized.

Copy link
Owner Author

commented Jan 27, 2019

As-is, there's no way to guard against, say, 0x615baf (PUSH2 JUMPDEST <UNASSIGNED_0xAF>).

That's not true. In the case you provided, 0xAF is data, and it will never have a chance to become code in current execution frame. Our JUMPDEST map check ensures that that 0x15, which happens to have the same value as a JUMPDEST opcode, will never become a valid jump destination.

Then a majority of new deployments of Solidity contracts will fail, as solc tacks a hash value of the source code to the end of compiled bytecode.

The Solidity argument is valid. However, a trivial fix to Solidity can be deployed, where we just prefix a PUSH32 to the hash value. I think this should have been the practice because it preserves our code/data guarantee, like we did for JUMPDEST. This avoids mistakes, if that ever happens to our compiler.

Deploying code with "unused opcodes" can be immensely useful for a generalised fork oracle.

This EIP does not prevent implementation of a generalised fork oracle. Once this is in force, a fork oracle can test by using CREATE with new opcodes, and detect whether the CREATE succeeds or fails, to know whether a hard fork happened.

@veox

This comment has been minimized.

Copy link

commented Jan 27, 2019

Ah, interesting!

I assume same checks as for CREATE will have to be performed for CREATE2... An issue with that is the check will have to be done by parties initially communicating off-chain, since when CREATE2 is used on-chain (e.g. in a "counterfactual exit"), it's already too late.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
2 participants
You can’t perform that action at this time.