HIP: 1 Title: HIP Purpose and Guidelines Type: Process Impact: None Author: Lee Sang Hoon <[email protected]> Comments-URI: https://zeronelabs.org Status: Draft Created: 2018-08-15
A HyperChain Improvement Proposal (HIP) is a design document for introducing features and/or information into HyperChain. As of this publication date, this is the standard way for changes to be introduced into HyperChain. Anyone can submit a HIP and all HIPs are evaluated through the HIP Workflow.
HIPs are intended to be the primary mechanisms for proposing new features and documenting design decisions. It is the responsibility of the HIP author to document community consensus including dissenting opinions.
This HIP is dual-licensed under the Open Publication License and BSD 2-clause license.
Anyone can author a HIP and submit it to the HIP Maintainer via e-mail or GitHub pull-request. The HIP Maintainer will validate the submission matches the HIP Format, and once corrected, will be added/pulled into the HyperChain repository. The HIP is then evaluated through the HIP Workflow as follows:
- Draft - a HIP that is undergoing rapid iteration and changes.
- Proposed - a HIP that is done with its initial iteration and ready for review by a wide audience for two weeks.
- Accepted - a HIP that has been in ‘Accepted’ for at least 2 weeks, any technical changes that were requested have been addressed by the author, and finally get approved by the HyperChain core developers.
- Active - a HIP that has been released as a standard specification.
- Cancelled - a HIP that has been canceled in progress.
Once the HIP is submitted to the HIP Maintainer, the HIP Maintainer maintains the status of the HIP as the workflow progresses.
Consensus on a HIP is arrived at by the community and the HyperChain developers.
If it becomes necessary to transfer ownership of a HIP, the original author is retained as a co-author and the new author is added to the HIP. This process takes place by the new author sending an email to the HIP Maintainer, carbon-copying the original author, explaining the transfer. The original author must consent if reasonably able to do so. The HIP Maintainer can make the decision without the original author.
The current HIP Maintainer is Lee Sang Hoon who can be contacted at [email protected].
A HIP submission should be written consist of the following structure:
- Header -- Metadata description of the HIP (see below).
- Summary -- Short (~200 word) description of the technical issue being addressed.
- Motivation -- Clear explanation of why current protocol is inadequate to address the problem the HIP solves.
- Specification -- Full technical description of the proposed new feature, clear enough for implementation.
- Rationale -- Discussion why was the specification was chosen over alternate designs. Evidence supporting the specification should be provided here, as well as community concerns and consensus.
- Backwards Compatibility -- Any backwards incompatibilities should be described here, as well as work-arounds/solutions for these incompatibilities.
- Reference Implementation -- The reference implementation must be provided before HIP is Completed.
- Links -- References and links to relevant material.
HIP: <HIP number, or "?" before being assigned> Title: <HIP title; maximum 44 characters> Type <The type of HIP, see below for options> Author: <list of authors' real names and email addrs> Impact <How impactful the proposed changes are, see below for details. Format: Severity - Sub-System(s)> * Discussions-To: <email address> * Comments-Summary: <summary tone> Comments-URI: <links to wiki page for comments Status: <Workflow status, see above> Type: <Standards Track | Informational | Process> Created: <date created on, in ISO 8601 (yyyy-mm-dd) format> * Requires: <HIP number(s)> * Replaces: <HIP number> * Superseded-By: <HIP number>
- are optional fields.
|Protocol||Changes to the network protocol relating to Blocks, Operations and the SafeBox.|
|Backend||Changes to the JSON RPC-API, Daemon or implementation-level concern such as storage, etc|
|Frontend||Changes to the the wallet including GUI, UX, JSON-RPC etc|
|Informational||Design issues, general guidelines. Does not require HIP consensus, informational only|
|Process||Describes change in HIP process.|
A HIP may have multiple types.
|None||can be implemented without impacting network|
|Soft-Fork||changes can be deployed as an optional upgrade whilst retaining backwards compatibility with non-upgraded nodes.|
|Hard-Fork||changes require a scheduled network-wide upgrade whereby non-upgraded nodes will not inter-operate with upgraded nodes.|
|Protocol||changes to the HyperChain network protocol|
|API||changes to shared API server|
|RPC||changes to JSON-RPC API|
|GUI||changes to wallet GUI|
|Mobile||changes to mobile GUI or implementation|
|Other||changes to any other aspect of how HyperChain is implemented. For examples, changes to log format or how persistence-layer would fall other here.|