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
Skinniest CREATELINK #2185
Skinniest CREATELINK #2185
Conversation
There has been no activity on this pull request 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. |
I have received no feedback but am ready for a review. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I believe it will be necessary to discuss how this interacts with SELFDESTRUCT
on the linked contract, but that isn't necessary for Draft status.
eip: <to be assigned> | ||
title: CREATELINK opcode | ||
author: William Morriss (@wjmelements) | ||
discussions-to: [Github PR](https://github.com/ethereum/EIPs/pull/2185) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This can't be the pull request. You can create a new issue or a thread on https://ethereum-magicians.org/. Also, this should just be the link, not a markdown link with title.
<!--The technical specification should describe the syntax and semantics of any new feature. The specification should be detailed enough to allow competing, interoperable implementations for any of the current Ethereum platforms (go-ethereum, parity, cpp-ethereum, ethereumj, ethereumjs, and [others](https://github.com/ethereum/wiki/wiki/Clients)).--> | ||
The opcode for `CREATELINK` is `0xf7`. | ||
`CREATELINK` pops one word, the target address. | ||
As with `BALANCE`, `EXTCODESIZE`, `EXTCODECOPY`, and `EXTCODEHASH`, the upper 12 bytes are zeroed. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The first time any opcode is referenced in an EIP it needs to have (`0x##`) after it. Please add that for these opcodes.
Alternatively, just remove them since we don't really need a comparison in order to draft a specification. Instead just say:
the upper 12 bytes of the popped address are zeroed.
In case the account does not exist or does not have code, the opcode is equivalent to a revert returning 32 bytes, the `OR` of `0xf7 << 31` and the non-existent account address. | ||
For example, a call to a contract with code `0x3df7` would revert, returning data `0xf700000000000000000000000000000000000000000000000000000000000000` and the remaining gas. | ||
|
||
The new account address is calulated the same way as in `CREATE`. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In the Rationale, I recommend discussing why CREATE
instead of CREATE2
(unless it is obvious and I'm just being dense).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
CREATE2 has salt; CREATE does not.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could we add a salt parameter that is popped from the stack? I have heard many people indicate that they have a strong preference for CREATE2 addressing, with some even going as far as suggesting we drop CREATE support. It would be unfortunate to go the opposite direction and introduce a new creation opcode that uses the unliked addressing mechanism.
Co-authored-by: Micah Zoltu <micah@zoltu.net>
Co-authored-by: Micah Zoltu <micah@zoltu.net>
Co-authored-by: Micah Zoltu <micah@zoltu.net>
Co-authored-by: Micah Zoltu <micah@zoltu.net>
Co-authored-by: Micah Zoltu <micah@zoltu.net>
Co-authored-by: Micah Zoltu <micah@zoltu.net>
Co-authored-by: Micah Zoltu <micah@zoltu.net>
Co-authored-by: Micah Zoltu <micah@zoltu.net>
Co-authored-by: Micah Zoltu <micah@zoltu.net>
Co-authored-by: Micah Zoltu <micah@zoltu.net>
Co-authored-by: Micah Zoltu <micah@zoltu.net>
There has been no activity on this pull request 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. |
This pull request 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. |
As demonstrated in EIP 911, a lot of state can be saved by sharing code of identical contracts.
This EIP adds a minimalist
CREATELINK
opcode at 0xf7 that takes one parameter, the target contract address, and returns one parameter, the created account address.No constructor is called; the code matches the code at the target address.
It is self-chainable, so factory contracts can make many children back-to-back with little overhead.