Skip to content

Latest commit

 

History

History
69 lines (40 loc) · 5.23 KB

sip-0001.md

File metadata and controls

69 lines (40 loc) · 5.23 KB

SIP-0001 : SIP Purpose and Guidelines

Number:  SIP-0001
Title:   SIP Purpose and Guidelines
Type:    Informational
Status:  Living
Authors: Alex Lan <[email protected]>
Created: 2023-09-14

What is an SIP?

SIP stands for Stratos Improvement Proposal. An SIP is a design document providing information to the Stratos community, or describing a new feature for Stratos Chain or Resource Network or its processes or environment. The SIP should provide a concise technical specification of the feature and a rationale for the feature. The SIP author is responsible for building consensus within the community and documenting dissenting opinions.

SIP Rationale

We intend SIPs to be the primary mechanisms for proposing new features, for collecting community technical input on an issue, and for documenting the design decisions that have gone into Stratos. Because the SIPs are maintained as text files in a versioned repository, their revision history is the historical record of the feature proposal.

For Stratos implementers, SIPs are a convenient way to track the progress of their implementation. Ideally each implementation maintainer would list the SIPs that they have implemented. This will give end users a convenient way to know the current status of a given implementation or library.

SIP Types

There are three kinds of SIP:

  • A Standards Track SIP describes any change that affects most or all Stratos implementations, such as a change to the network protocol, a change in block or transaction validity rules, or any change or addition that affects the interoperability of applications using Stratos. Furthermore, Standards Track EIPs can be broken down into the following categories:

    • Core: improvements requiring core consensus upgrade, including change the consensus of chain validator, traffic considerations, proof-of-traffic consensus etc.
    • Networking: includes improvements around p2p communication between nodes and the relay mechanism between different Stratos Networks.
    • Interface: includes improvements around language-level standards like method names and rpc names.
    • SRC: application-level standards and conventions, including contract standards such as token standards, storage light-node extension etc.

  • An Informational SIP describes a Stratos design issue, or provides general guidelines or information to the Stratos community, but does not propose a new feature. Informational SIPs do not necessarily represent a Stratos community consensus or recommendation, so users and implementors are free to ignore Informational SIPs or follow their advice.

  • A Process SIP describes a process surrounding Stratos, or proposes a change to (or an event in) a process. Process SIPs are like Standards Track SIPs but apply to areas other than the Stratos protocol itself. They may propose an implementation, but not to Stratos' codebase; they often require community consensus; unlike Informational SIPs, they are more than recommendations, and users are typically not free to ignore them. Examples include procedures, guidelines, changes to the decision-making process, and changes to the tools or environment used in Stratos development. Any meta-SIP is also considered a Process SIP.

SIP Process

The following is the standardization process for all SIPs in all tracks:

SIP-process.jpg

Idea - An idea that is pre-draft. This is not tracked within the SIP Repository.

Draft - The first formally tracked stage of an SIP in development, SIP number is assigned at the stage. An SIP is merged by an SIP Editor into the SIP repository when properly formatted.

Review - An SIP Author marks an SIP as ready for and requesting Peer Review.

Last Call - This is the final review window for an SIP before moving to Final. An SIP editor will assign Last Call status and set a review end date (last-call-deadline), typically 14 days later.

If this period results in necessary normative changes it will revert the SIP to Review.

Final - This SIP represents the final standard. A Final SIP exists in a state of finality and should only be updated to correct errata and add non-normative clarifications.

A PR moving an SIP from Last Call to Final SHOULD contain no changes other than the status update. Any content or editorial proposed change SHOULD be separate from this status-updating PR and committed prior to it.

Stagnant - Any SIP in Draft or Review or Last Call if inactive for a period of 6 months or greater is moved to Stagnant. An SIP may be resurrected from this state by Authors or SIP Editors through moving it back to Draft or it's earlier status. If not resurrected, a proposal may stay forever in this status.

SIP Authors are notified of any algorithmic change to the status of their SIP

Withdrawn - The SIP Author(s) have withdrawn the proposed SIP. This state has finality and can no longer be resurrected using this SIP number. If the idea is pursued at later date it is considered a new proposal.

Living - A special status for SIPs that are designed to be continually updated and not reach a state of finality. This includes most notably SIP-1.

SIP Formats and Templates

SIPs should be written in markdown format. There is a template to follow.