Core EIPs in an Executable Spec World

[timbeiko]

@SamWilsn

Single document, as in CL and EL in the same repository; or as in your original proposal where the EIP links out to the CL and EL repositories?

My preference is to have the EIP link out to both specs repo.

@SamWilsn

So you’d be opposed to splitting Core EIPs into their own process, and keeping Network/Interface/ERC/Meta/Informational EIPs in the current one?

Core EIPs already have their own process What I like about the current system is that:

1. You can go to either the EIPs repo or eips.ethereum.org and see a list of all proposals, both Core and others.
2. The EIP is the canonical document you must read to then dive deeper. Arguably, that’s not really true anymore and fails for complex EIPs (as seen with 1559, withdrawals, 4844, etc.). It is something I think would be good to aim for, though.

That said, I could see us splitting out ERCs into their own separate repo and hosting them at erc.ethereum.org. The community recognition seems sufficient, and both groups are distinct enough. Core/Networking still seem tightly coupled. Interface/Meta now seems somewhat stale due to the API+specs repo.

@SamWilsn

I want to avoid changing “EIP” as a name. It really is a good identifier system. This might be a bit off topic, but if we were to split Core out, I’d probably say that:

• All EIPs with N < 10000 are “legacy” and need to be special-cased.
• All EIPs with N >= 10000 && (N % M) == 0 are Core EIPs against CL.
• All EIPs with N >= 10000 && (N % M) == 1 are Core EIPs against EL.
  .
  .
  .

That way all the tooling knows based on just the EIP number where to send readers to get the spec, and EIPs that are related are grouped together by number.

That’s interesting!