EIP-2677: Cap initcode (draft) #2677
Conversation
Co-authored-by: Sina Mahmoodi <1591639+s1na@users.noreply.github.com>
|
@holiman merged in master and added a discussion URL so this can be merged. |
There was a problem hiding this comment.
Good enough to merge as a draft, but I wouldn't be willing to merge this to Last Call as it is (even ignoring the incomplete sections). I recommend reviewing the feedback provided and making adjustments before submitting to last call.
Also consider adjusting the tense of the writing here. I very much prefer to write EIPs as technical documents that target a reader base of future specification readers, rather than current/past readers. This means instead of saying "there has been a size limit of ..." you might say "prior to this EIP there was a size limit of ..." (as a simple example).
EIPs are assertions, not proposals. This means the EIP shouldn't say stuff like "we propose you do X", it should instead say "do X". whether someone follows the EIP or not is a totally separate conversation that should not be part of the EIP itself, and once someone has decided to follow the EIP everything in it should be an assertion unless it is intentionally left ambiguous (e.g., SHOULD or MAY).
|
|
||
| ## Simple Summary | ||
|
|
||
| Enforce a maximum size limit (`max_initcode_size`) of `49152` (`0xc000`) for `initcode`. |
There was a problem hiding this comment.
| Enforce a maximum size limit (`max_initcode_size`) of `49152` (`0xc000`) for `initcode`. | |
| Set a maximum size limit of 49152 for `initcode`. |
| Since [EIP-170](https://eips.ethereum.org/EIPS/eip-170) was implemented, there has been a size limit of `24576` (`0x6000`) on contract code. We propose to also limit the size of executable code to `2x` the above limit, i.e. `49152` (`0xc000`). | ||
|
|
||
| This also leads to two nice properties: | ||
|
|
||
| - instruction offset in code fits 16-bit value, | ||
| - code size fits 16-bit value. |
There was a problem hiding this comment.
Consider moving all of this to the motivation section. Abstract should be a human-friendly and terse version of the specification, while the motivation section is where you state why this is a good idea, how these changes make things better, etc.
| ## Specification | ||
|
|
||
| There are three situations where this is applicable: | ||
|
|
||
| * `CREATE`, | ||
| * `CREATE2`, | ||
| * creation using a transaction with empty receiver. | ||
|
|
||
| In all these (and future) cases, the EVM should fail with Out Of Gas error if the code has a length more than `max_initcode_size`. |
There was a problem hiding this comment.
A user should be able to implement an EIP from the specification section alone. Currently, this specification section is not self contained as it appears to be referring to information in other sections (e.g., the this reference in the first sentence).
Also it should make assertions, not suggestions, especially for consensus code. "should fail" will result in total consensus failure if some clients fail and some clients don't fail. My guess is that you meant MUST fail here.
Also, the specification section should not be discussing hypothetical future cases here. It may be worth mentioning in the security considerations or backward compatibility section, but discussion about the behavior of future hypothetical cases are not really relevant for the specification section of a technical document.
* EIP draft initcode cap * Update EIPS/eip-draft_cap_initcode.md Co-authored-by: Sina Mahmoodi <1591639+s1na@users.noreply.github.com> * EIP-2677: linter fixes, minor changes, update with EIP number * Small typographic changes * Add discussion URL * Fix EIP header Co-authored-by: Sina Mahmoodi <1591639+s1na@users.noreply.github.com> Co-authored-by: Alex Beregszaszi <alex@rtfs.hu>
* EIP draft initcode cap * Update EIPS/eip-draft_cap_initcode.md Co-authored-by: Sina Mahmoodi <1591639+s1na@users.noreply.github.com> * EIP-2677: linter fixes, minor changes, update with EIP number * Small typographic changes * Add discussion URL * Fix EIP header Co-authored-by: Sina Mahmoodi <1591639+s1na@users.noreply.github.com> Co-authored-by: Alex Beregszaszi <alex@rtfs.hu>
Propose a cap on initcode.