Update EIP-1: Clarify when to use requires

[SamWilsn]

As discussed in EIPIP Meeting #64, here's a PR with my proposal for updating the requires text.

[eth-bot]

Hi! I'm a bot, and I wanted to automerge your PR, but couldn't because of the following issue(s):

---

(fail) eip-1.md

classification
updateEIP

• Changes to EIP 1 require at least 5 unique approvals from editors; there's currently 3 approvals; the remaining editors are @axic, @gcolvin

[SamWilsn]

Personally, I wouldn't explicitly mention a section at all, but I do see the benefit of a hard-and-fast rule.

I think I prefer @Pandapip1's edit over @xinbenlv's because the crux of the decision isn't where the reference occurs, but why you're referencing it.

For example, if an EIP uses CREATE2, you can pretty easily write the entire EIP without explicitly mentioning EIP-1014 in the specification section—the opcode is well-known enough. That shouldn't mean you don't have to put requires: 1014 in the preamble.

[xinbenlv]

Personally, I wouldn't explicitly mention a section at all, but I do see the benefit of a hard-and-fast rule.

I think I prefer @Pandapip1's edit over @xinbenlv's because the crux of the decision isn't where the reference occurs, but why you're referencing it.

For example, if an EIP uses CREATE2, you can pretty easily write the entire EIP without explicitly mentioning EIP-1014 in the specification section—the opcode is well-known enough. That shouldn't mean you don't have to put requires: 1014 in the preamble.

I agree 100% of what you say: what we really care is the dependency between EIPs.

but I have to admit it's a bit hard to judge, sometimes also subjective. For example, EIP-155 introduces ChainID, which https://eips.ethereum.org/EIPS/eip-2718 depends on. But 2718 didn't list 155 as required.

Also ChainId is needed for many hard-fork meta EIPs, but they don't necessarily consider 155 as a dependency, because we take chainId for granted nowadays. This principle of "dependency" makes it harder to judge. Therefore that's why I slightly tweak the wording so that if author feel it's necessary for spec to reference that EIP, they will put it in requires, otherwise no mandate.

[Pandapip1]

but I have to admit it's a bit hard to judge, sometimes also subjective. For example, EIP-155 introduces ChainID, which https://eips.ethereum.org/EIPS/eip-2718 depends on. But 2718 didn't list 155 as required.

I don't see chainid mentioned in the specification?

[xinbenlv]

but I have to admit it's a bit hard to judge, sometimes also subjective. For example, EIP-155 introduces ChainID, which https://eips.ethereum.org/EIPS/eip-2718 depends on. But 2718 didn't list 155 as required.

I don't see chainid mentioned in the specification?

@Pandapip1

https://eips.ethereum.org/EIPS/eip-2718 Specification > Receipts

LegacyTransaction is rlp([nonce, gasPrice, gasLimit, to, value, data, v, r, s])

In which v has the chainId.
See, it just proves my point sometimes dependencies are so unobvious.

[gcolvin]

For Core stuff it's really difficult to track things back to their original EIP once they are into the protocol. And once they are into the Yellow Paper I think they can pretty much be taken for granted. The Requires section seems essential mostly for the other, related EIPs that are also still in-process. For ERCs that's not quite so hard a problem - the ERC really is the controlling technical document, and they don't tend to keep building on top of each other as much as Core EIPs do.

[xinbenlv]

This wording seems to me in good state to merge, are we waiting for anything else before merge it? @SamWilsn