Alert Source Discuss
🚧 Stagnant Meta

SIP-233: Formal process of hard forks

Authors Alex Beregszaszi (@axic)
Created 2017-03-23
Discussion Link https://sila-magicians.org/t/sip-233-formal-process-of-hard-forks/1387

Abstract

To describe the formal process of preparing and activating hard forks.

Motivation

Today discussions about hard forks happen at various forums and sometimes in ad-hoc ways.

Specification

A Meta SIP should be created and merged as a Draft as soon as a new hard fork is planned.

This SIP should contain:

  • the desired codename of the hard fork,
  • activation block number once decided
  • a timeline section
  • an SIPs to include section
  • the Requires header should point to the previous hard fork meta SIP.

The draft shall be updated with summaries of the decisions around the hard fork.

Timeline

Once a timeline with key dates is agreed upon for other crucial dates. The basic outline of a hardfork timeline should include:

  • Hard deadline to accept proposals for this hard fork
  • Soft deadline for major client implementations
  • Projected date for testnet network upgrade
  • Projected date for sila-mainnet upgrade (the activation block number / projected date for this block)

SIP Inclusion Process

Anyone that wishes to propose a Core SIP for the hard fork should make a PR against the Meta SIP representing the hard fork. The SIP must be published as at least Draft. It enters the Proposed SIPs section, along with at least one person who is a point of contact for wanting to include the SIP.

SIPs can move states by discussion done on the “All Core Devs Meetings”:

  • If accepted for a hard fork, the SIP should be moved to the Accepted SIPs section. If the SIP has major client implementations and no security issues by the timeline date, it is scheduled for inclusion.
  • If rejected from a hard fork, the SIP should be moved to the Rejected SIPs section.
  • Once the SIPs in the Accepted SIPs section have successfully launched on a testnet roll out, they are moved to the Included SIPs section.

The Meta SIP representing the hard fork should move in to the Accepted state once the changes are frozen (i.e. all referenced SIPs are in the Accepted state) and in to the Final state once the hard fork has been activated.

Template

A template for the Istanbul Hardfork Meta 1679 is included below (source file on GitHub):


---
sip: 1679
title: "Hardfork Meta: Istanbul"
author: Alex Beregszaszi (@axic), Afri Schoedon (@5chdn)
type: Meta
status: Draft
created: 2019-01-04
requires: 1716
---

## Abstract

This meta-SIP specifies the changes included in the Sila hardfork named Istanbul.

## Specification

- Codename: Istanbul
- Activation: TBD

### Included SIPs

- TBD

### Accepted SIPs

- TBD

### Rejected SIPs

- TBD

### Proposed SIPs

- TBD

## Timeline

* 2019-05-17 (Fri) hard deadline to accept proposals for "Istanbul"
* 2019-07-19 (Fri) soft deadline for major client implementations
* 2019-08-14 (Wed) projected date for testnet network upgrade (Ropsten, Görli, or ad-hoc testnet)
* 2019-10-16 (Wed) projected date for sila-mainnet upgrade ("Istanbul")

## References

- TBD (e.g. link to Core Dev notes or other references)

## Copyright

Copyright and related rights waived via [CC0](/LICENSE).


Rationale

A meta SIP for coordinating the hard fork should help in visibility and traceability of the scope of changes as well as provide a simple name and/or number for referring to the proposed fork.

Copyright and related rights waived via CC0.

Citation

Please cite this document as:

Alex Beregszaszi (@axic), "SIP-233: Formal process of hard forks [STAGNANT]," Sila Improvement Proposals, no. 233, March 2017. Available: https://sips.sila.org/SIPS/sip-233.