CasperLabs Improvement Proposal

Abstract

CasperLabs has opted to include an editing process similar to that of Ethereum and Bitcoin’s Improvement Proposal Model. In the following pages I will outline what this process will look like on CasperLabs’s platform.

CasperLabs IP can be categorized into three different types 

Standard IP

Standard Improvement Proposals affect the core code of the network and typically include any changes affecting most or all of CasperLabs’s implementation. Any changes involving transaction validity, interoperability, or network protocol qualifies as a Standard IP. Proposals of this type must include a design document and a reference implementation.

A Standard IP 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 devp2 and Subprotocol as well as network protocols involving whisper and swarm.
• Interface: involves improvements around client API/RPC specification standards.
• ERC: involves application-level standards and conventions, including contract standards such as token standards, name registries, and wallet formats.

Meta IP

A Meta IP involves changing a process on the CasperLabs network. These are similar to Standard IP’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.

Informational IP

An Informational IP 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.

CasperLabs IP Requirements

• Preamble: This includes the Title, IP 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 IP proposing a change to the network must be able to persuasively describe why the current process is inadequate to solve the problem your IP 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 IP will affect different stakeholder groups on the chain, and what their stance may be towards the proposed update.
• Backwards Compatibility: All CasperLabs IP’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 IP’s that intend to change consensus.
• Implementation: Must include the test code and documentation appropriate for the CasperLabs protocol. This must be completed before the IP moves into the last status.
• Copyright: All CasperLabs IP’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 IP 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 IP 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 IP 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 IP is accepted, the IP Editor will assign a number and merge the pull request.

Proposed

Once the Draft has been merged, the author may file follow-up pull requests to further changes until he or she believes the IP 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 IP 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 IP has been implemented, the IP will move to ‘Last Call’.

Rejected: The IP will be rejected if significant material changes are still expected to be made.

If accepted, the IP Editor will set a review date and the IP will proceed to ‘Last Call’.

Last Call

During Last Call, the IP will be displayed on CasperLabs's Governance Website. By this point, the IP is expected to have been debated in the community and developed significant community consensus.

Accepted (Core IP): If there are no technical or material issues and the IP has engaged in significant community discussion. At this point, the IP proceeds to ‘Accepted’.

Accepted (Meta & Informational IP): If there are no technical or material issues and the IP has engaged in significant community discussion. At this point, the IP proceeds to ‘Final’.

Rejected: An IP that has significant technical issues and is not materially sound will revert back to ‘Proposed’. If the IP 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.

Accepted (Core IP)

Core IP’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 IP must be implemented by at least five CLX Client Developers. When implementation is complete and adopted by the community, the status will move to ‘Final’.

Final

An IP in ‘Final’ represents the final, active implementation.

Superseded

An IP is considered Superseded if it was previously ‘Final’ but is no longer considered state-of-the-art. In these cases, a new IP builds off the old IP, and when it is implemented, the former IP is considered superseded, with reference in the ‘Final’ IP.

IP Editor Information

Selection

IP Editors will be nominated by the community and appointed by the Core Team. The community will have the opportunity to nominate candidates as IP 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) IP Editors. IP 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 IP Editor may hold that position is eight (8) years.

If an IP 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.

IP Editors as Authors

If an IP Editor intends to draft an IP as an Author, they may not review their own IP. A separate IP Editor must agree to review and edit all IP’s an Editor authors.