Because of this link need to get #3540 merged first.

Alternatively, you could potentially reword this so it isn't dependent on 3540 specifically. Maybe something like "having a reserved first byte will allow us to introduce EVM versioning in a future EIP."

The EIP is not dependent on 3540 specification wise, but only in the motivation section. I think this is extremely important for understanding the motivation, so would prefer to keep it this way.

If/once 3541 goes live, we expect to simplify 3540.

Having a reference to 3540 in the motivation will mean that this EIP cannot advance through the EIP process faster than EIP-3541. I strongly recommend removing the reference so this EIP doesn't get blocked by that. This EIP is definitely reasonable to stand on its own IMO, as having a mechanism for contract versioning is important no matter what future versioning EIP we go with.

I strongly recommend removing the reference so this EIP doesn't get blocked by that. This EIP is definitely reasonable to stand on its own IMO, as having a mechanism for contract versioning is important no matter what future versioning EIP we go with.

Is that the current blocker to this eip getting merged?

What is the origin of the rule that every linked EIP is a dependency of the current one?
In EIP-1 I see only the requirement that all dependencies should be explicitly listed in requires, but no restrictions on what can be linked.

@gumb0 EIP authors linking to EIPs that never make it past draft and eventually get moved to withdrawn or stagnant. Then 3 years later you have a final EIP that references completely irrelevant content. EIPs should be written for future readers, not current core developers.

I think the target audience of EIPs is the major point of contention here. Many view the EIP process as a change control process for Ethereum, rather than a standardization process. If it were a change control process, then the utility of an EIP would end when it reached Final. As a standardization process, the utility of an EIP is considered to begin when it reaches Final. We have been talking a lot lately about revamping the Ethereum specification/standardization/change control process to help address this conflict, but at the moment EIPs are standards, not change control documents.

I think it is exactly the opposite. The EIP draft is your best chance to properly explain and motivate a proposed EIP. This is because all other channels (Discord chat and ACD calls) are temporary and have very limited capacity.

• An EIP draft should be written for current core developers.
• Withdrawn or stagnant EIPs are relevant.

The purpose of the discussions-to link in an EIP is to fulfill that need. The EIP should be written as it would be when final, purely as a standard/specification. The information included in the motivation/rationale section should be things that will be relevant to people in the future.

The discusssions-to absolutely does not work for this. Nobody will ready 20+ posts there. Unless you are suggesting everyone should ask "What is the purpose of this EIP?" all over again. Moreover, the FAQ section is not allowed in an EIP. So we are gradually collecting answers for common questions and put then in Rationale.

We have clear disagreement here. How do you plan to resolve it?

IMO: the discussions-to is a place to discuss and nitpick over details in the eip. However, I do think that the EIP itself should contain a bit of history for "why do we want this eip". Even for future developers, it's highly relevant to understand the context in which an eip was created. and what preceded it.
The discussions-to can be used to discuss "hey that reference is not useful", or "can't we change param X to 1337 instead of 5". When all is said and done, however, the EIP should stand alone, and any useful parts of previous discussions may well be inside the eip (in some abbreviated form)

This clarifies that the abort happens after the init code has been executed.

This hits the naming issue we are currently struggle with. Yellow Paper defined initcode and code where the later means the deployed code. This is very confusing already in this case and only gets worse when EOF1 introduces code section.

I was carefully avoiding "deploy" name in the spec because this is not properly defined. But maybe we should introduce more precise names instead.

Why not use the REVERT (0xFD), INVALID (0xFE), or SELFDESTRUCT (0xFF) instead, since we know that any such contracts that exist would do nothing? Do we specifically want to "consumed" a new instruction for this?

This way it is "less breaking": It is generally agreed in the Ethereum community that contracts should not use unassigned opcodes, because hard forks could change the meaning of these opcodes. This means that contracts that conform to this agreement are unaffected by this EIP. If we change the EIP to use one of the opcodes you propose, then a contract that deploys code that starts with such an opcode will change it semantics: The deployment will fail after the hard fork. Note that a failure to deploy and deploying code that always reverts are two completely different things.

Also during the initial discussions 0xEF was described as a new instruction called FORMAT, which if encountered anywhere results in abort. In the end we simplified the description to be a byte check in the deployed code, and given it is an invalid opcode, it results in abort in the initcode.

The risk we imagined is if people deploy contracts purposefully with 0xFE so that they are not executable, that means a lot of contracts could be already using it. This results in a longer prefix (magic).

If I'm not mistaken @holiman did a check on existing contracts on a recent block and it seems none of them are starting with 0xEF, 0xFD, 0xFE, or 0xFF.

However that does not mean there aren't any cases where code is already valid/expected (i.e. via a precalculated create2 hash in some contract), but not yet deployed. This is one of the problems @chriseth is referring to.

I think using 0xFE could be considered if we really want to save the 0xEF opcode for something else, but would refrain from 0xFD or 0xFF.

The check is still running. Right now, the numbers are, with 4646239 contracts checked: 0 start with 0xef, 1 starts with fe, 1 with fd, and 4 with ff.
Still some time to go before I've gone through the entire state

I'll update the rationale with some condensed form we discussed in this thread, but will wait for @holiman's final numbers to be included it in.

Final update btw, ef was unused: https://gist.github.com/holiman/466cf6598e4a967620b9833b5ce49a23

Added explanation based on @chriseth's comment and explained the findings by @holiman.

The "Simple Summary" is not part of EIP-1. It has been removed over a year ago, see #2186.

Hmm, the template still references it and doesn't mention that it is optional. We should probably resolve that. I will bring it up with the other editors.

https://raw.githubusercontent.com/ethereum/EIPs/master/eip-template.md

This has been brought up months ago either on the channel and/or some other PR, and the agreement was to just fix the template, but apparently nobody did it 😉

I believe you are right that it has come up before, as I vaguely remember such a conversation. If you can find a link to the conversation that came to consensus (recently) that would be great so we can avoid going through it again. If not, feel free to join in the conversation at https://discord.com/channels/595666850260713488/746566142700814426/841291994273939468

I'm willing to go to Draft without the Simple Summary, but this EIP should really be moving into Review almost immediately after draft since you want it included in London and I believe the current "policy" (desired operating procedure) is that things shouldn't even be considered/eligible for inclusion until they are in Review. The simple solution if you are in a hurry (which I think you are) would be to just add the Simple Summary since we have been making everyone include a Simple Summary for a while until we can resolve the inconsistency between EIP-1 and the Template.

Note: The reason I'm such a stickler on these things is because we are hugely understaffed on the EIP editors front, and having simple hard and fast rules that everyone has to follow is way less time consuming than having fuzzy rules that we make exceptions for and have to defend those exceptions to authors of other EIPs. The "rules" I have been following are that "EIPs should be formatted like the template outlines" in this case.

Here is my contribution to resolving the problem: #3564

Of course if you think the consensus of editors from >1.5 years ago is not valid or if you think the sentiment has changed, then it can't be easily merged.

I'm open to changes, but would like to get feedback from @chfast @gumb0 @AlexeyAkhunov @holiman @chriseth which one they prefer. However I would not make this a blocker for merging, as we can update it afterwards, i.e. in the one marking it review?

My personal view is that perhaps the current one is better.

I also prefer a more explicit title.

No external links. Please inline the tests here (it is common to include input and output or input and expectations in a language neutral format), or add them as an asset in ../assets/eip-3541/*.

I find this no external links policy for drafts really not that useful. I will just remove this content for now, that's the least resistance I can do and is the result of these policies 😉

FWIW, I'm actively trying to get people's feedback on the direction we want to take EIPs (change control process vs standardization process) so we (me vs everyone) can stop clashing on this stuff. The problem is that it is really hard to get anyone to engage on process changes, so it keeps defaulting back to "what Micah thinks is best because they are the only one actually engaging in the conversation outside of expressing annoyance in PR reviews". This may not be what is actually best for the process (though I currently believe it is), but it is hard to find "best" when there is only one person actively engaging in long-term discussion.

I think it is fair to say I did my part in engaging for years in the process 😉

I do not fully understand what you mean when you say "change control" vs "standardization" in the context of EIPs, but drafts are very much a work-in-progress state where having authoritative external links is very useful. For example tests or code may be not final, but is essential to making use of an EIP efficiently, and hence during the draft state external links can accomplish that goal. I agree that the final state must have stricter rules, but it seems to be like putting a giant burden on people when asking them to keep the readyness/completeness of a draft at the equal level needed for a final EIP.

Why have drafts (and the draft status) in that case at all? Why not just have review/final statuses?

The answer to that (so far) was: the point of drafts was to collect efforts into this single directory (the EIP repository) as opposed to people trying to find various outlets to make and share their drafts.

Lets move this discussion to Discord, or if you prefer we can create a thread on Ethereum-Magicians, or we can discuss at the next EIPIP meeting.

I have been bringing this issue up for a while now and trying to get people to engage outside of PRs but so far I haven't had any luck. Usually what happens is the person capitulates to the current process but complains about the process in the PR, and then once the PR is merged they stop caring enough to engage further and the issue gets dropped.

Discord has way too much noise -- it is more than a full time job keeping up with it. Besides that, as we pointed out earlier on this PR, it is not possible to search and link to any discussion on Discord, hence it is a bad place to make these conversations at. (Gitter is at least publicly linkable.)