HIP Purpose and Guidelines

  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 

Abstract

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.

Copyright

This HIP is dual-licensed under the Open Publication License and BSD 2-clause license.

HIP Workflow

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

Consensus on a HIP is arrived at by the community and the HyperChain developers.

Transferring Ownership

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.

HIP Maintainer

The current HIP Maintainer is Lee Sang Hoon who can be contacted at [email protected].

HIP Format and Structure

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.

Header

  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.

HIP Types

HIP Type	Description
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.

Impact Severity

Impact	Description
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.

Impacted Sub-system

Sub-system	Description
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.