Implementation => Reference Implementation (#3078)

In reality, the `Implementation` section almost always involves someone linking out to a personal or company repository when they create an EIP from the template.  External repositories cause problems because:
1. Links move/change over time and eventually the link will be dead.
2. The implementation likely isn't CC0 as the EIP is, and naive users may follow the link not realizing it is GPL and they are screwing themselves legally.
3. People are using EIPs for advertising their project, and they look for any opportunity they can to link out to their project in the body of the EIP.
4. People often link to some monolithic repository (e.g., go-ethereum) as the "implementation" which is less than useful.

Also, the description was written back when EIPs were part of the hard fork coordination process, so that has been rewritten.

This change makes it so it is more clear that this section is optional and that external links are not the preferred solution to completing this section.
This commit is contained in:
Micah Zoltu 2020-12-05 16:18:35 +08:00 committed by GitHub
parent 889bf6b844
commit 774458ef71
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23

View File

@ -38,8 +38,8 @@ All EIPs that introduce backwards incompatibilities must include a section descr
## Test Cases
Test cases for an implementation are mandatory for EIPs that are affecting consensus changes. Other EIPs can choose to include links to test cases if applicable.
## Implementation
The implementations must be completed before any EIP is given status "Final", but it need not be completed before the EIP is accepted. While there is merit to the approach of reaching consensus on the specification and rationale before writing code, the principle of "rough consensus and running code" is still useful when it comes to resolving many discussions of API details.
## Reference Implementation
An optional section that contains a reference/example implementation that people can use to assist in understanding or implementing this specification. If the implementation is too large to reasonably be included inline, then consider adding it as one or more files in `../assets/eip-####/`.
## Security Considerations
All EIPs must contain a section that discusses the security implications/considerations relevant to the proposed change. Include information that might be important for security discussions, surfaces risks and can be used throughout the life cycle of the proposal. E.g. include security-relevant design decisions, concerns, important discussions, implementation-specific guidance and pitfalls, an outline of threats and risks and how they are being addressed. EIP submissions missing the "Security Considerations" section will be rejected. An EIP cannot proceed to status "Final" without a Security Considerations discussion deemed sufficient by the reviewers.