-
Notifications
You must be signed in to change notification settings - Fork 1
Enhancement Proposals
This page proposes a process that will improve the existing CEP process after Mainnet Launch
Casper Enhancement Proposals can be categorized into three different types
Standard Enhancement Proposals affect the core code of the network and typically include any changes affecting most or all of Casper’s implementation. Any changes involving transaction validity, interoperability, or network protocol qualifies as a Standard EP. Proposals of this type must include a design document and a reference implementation.
A Standard EP will fall into one of four categories:
- Core: involves improvements requiring a consensus fork as well as changes that involve governing board decisions.
- Networking: includes improvements around p2p and Subprotocol as well as network protocols involving whisper and swarm.
- Interface: involves improvements around client API/RPC specification standards.
- Standards: involves application-level standards and conventions, including contract standards such as token standards, name registries, and wallet formats.
A Meta EP involves changing a process on the CasperLabs network. These are similar to Standard EP’s with the exception that they involve any changes outside protocol. They propose an implementation, but not to the code itself. Changes in these types of decision making processes typically require more consensus from the community.
An Informational EP outlines a design problem or provides guidelines to the CasperLabs community. It does not propose a new feature and does not require community consensus. It is at the liberty of the user to decide whether or not to implement this new change.
-
Preamble: This includes the Title, EP Author, and Number.
-
Summary: The summary provides a brief summary of the proposal and its purpose.
-
Specification: This describes the syntax of the new feature. It should be detailed enough to allow competing, interoperable implementations for any current Casper platforms.
-
Motivation: Any EP proposing a change to the network must be able to persuasively describe why the current process is inadequate to solve the problem your EP will effectively fix.
-
Rationale: This should detail why certain design decisions were made. It could outline alternative designs, describing why they weren’t chosen, and compatibility in multiple languages. It must also show community consensus and discuss important objections and concerns.
-
Stakeholders: This section should detail how the EP will affect different stakeholder groups on the chain, and what their stance may be towards the proposed update.
-
Backwards Compatibility: All CasperLabs EP’s that suffer from backwards incompatibility must describe these incompatibilities and their severity. The author must explain how they intend to solve these incompatibilities.
-
Test Case: These are mandatory for EP’s that intend to change consensus.
-
Implementation: Must include the test code and documentation appropriate for the Casper protocol. This must be completed before the EP moves into the last status.
-
Copyright: All CasperLabs EP’s must be in the public domain, and must be explicitly licensed under those terms. Design and Implementation Under CasperLabs is as Follows
-
Draft: An EP is considered a Draft when the author drafts a pull request. The author has the ability to defer or withdraw their IP if no progress is being made. If no progress is made on an IP draft over the span of three years, it will be rejected.
-
Accepted: A Draft EP is accepted if it’s concise, states the problem, their solution, the backwards compatibility, and is not a duplicate of other IP’s. The community must have intentions to move the IP to ‘Final’ Status.
-
Rejected: A Draft EP may be rejected if there is a duplication effort, disregard of formatting rules, it’s too unfocused or too broad, technically unsound, lacks proper motivation, or is not addressing backwards compatibility.
If the Draft EP is accepted, the EP Editor will assign a number and merge the pull request.
Once the Draft has been merged, the author may file follow-up pull requests to further changes until he or she believes the EP is materially sound. At this point, the author must be engaging in the community to address significant questions or concerns. The author must believe the EP is ready for real world implementation and it must be implemented to move to ‘Last Call’.
-
Accepted: If there are no more material changes to be made, and the EP has been implemented, the EP will move to ‘Last Call’.
-
Rejected: The EP will be rejected if significant material changes are still expected to be made.
If accepted, the EP Editor will set a review date and the EP will proceed to ‘Last Call’.
During Last Call, the EP will be displayed on CasperLabs's Governance Website. By this point, the EP is expected to have been debated in the community and developed significant community consensus.
-
Accepted (Core EP): If there are no technical or material issues and the eP has engaged in significant community discussion. At this point, the IP proceeds to ‘Accepted’.
-
Accepted (Meta & Informational EP): If there are no technical or material issues and the EP has engaged in significant community discussion. At this point, the EP proceeds to ‘Final’.
-
Rejected: An EP that has significant technical issues and is not materially sound will revert back to ‘Proposed’. If the EP has not met significant community consensus, it will revert to ‘Proposed’ and remain there for at least one month, focusing on gaining significant community consensus.
Significant Community Consensus is defined as constant, open discussion on popular forums of discussion for the CasperLabs community (ie. Mailing List, Reddit, Github, etc…) for at least one month. No person should have any unaddressed, substantiated objections to the IP. Addressed or obstructive objections may be ignored or overruled by general agreement if they have been sufficiently addressed, but clear reasoning must be given in such circumstances.
Core EP’s move to the CLX Client Developers. At this point, Client Developers must decide whether to implement the change to the protocol. Consensus is believe to be met if a significant amount of Developers decide to update the software.
-
Accepted: The EP must be implemented by Casper Client Developers. When implementation is complete and adopted by the community, the status will move to ‘Final’. (Other clients
-
Final An EP in ‘Final’ represents the final, active implementation.
-
Superseded An EP is considered Superseded if it was previously ‘Final’ but is no longer considered state-of-the-art. In these cases, a new EP builds off the old EP, and when it is implemented, the former EP is considered superseded, with reference in the ‘Final’ EP.
EP Editors will be nominated by the community and appointed by the Core Team. The community will have the opportunity to nominate candidates as EP Editors, and those with significant community consensus will be chosen by the Core Team for review. After review of multiple candidates, the Core Team will vote. The vote must be unanimous and each member of the board has the ability to exercise a single veto per election.
At any given time, there will be a maximum of ten (10) EP Editors. EP Editors hold terms of two years, with the ability to be re-appointed by the Governance Board four times. This means that the maximum amount of time an EP Editor may hold that position is eight (8) years.
If an EP Editor steps down, candidates with significant community consensus from the previous election will be re-reviewed and a single candidate will be chosen to fill the open position.
If an EP Editor intends to draft an EP as an Author, they may not review their own EP. A separate IP Editor must agree to review and edit all EP’s an Editor authors.