ECIP 1077: The Meta Fork ECIP: Establishing _Fork_ type ECIPs and their specifications and processes

Abstract

Establishing Fork type ECIPs, and their standards and processes.

TL;DR

Make ECIPs with Type Fork a thing, where Fork ECIPs should follow this process:

• A “shell” Fork ECIP is opened, fitting the template provided named ecip-X-FORK.md (available in the repository root directory). This ECIP does not initially include Activation Block Number or Features specifications.
• While in WIP or Draft status, one or more change sets are proposed against this document (eg. via Github Pull Requests) modifying BOTH Activation Block Number and Features specifications.
• … Stuff happens; there are comments, emails, meetings, bribes, blogs, bragging, trolling, haranguing, arguing, debating, pondering, editing, compromising, constructive critique, etc…
• One change set is merged to modify the Fork ECIP, yielding a COMPLETE and UNIQUE hard fork specification document, and status is moved to Last Call. By virtue of the process specification provided, a Fork ECIP achieving Last Call may not see Draft nor WIP status again (because doing so would require a merging a change set holding INCOMPLETE specification variables).

Definition

Fork ECIPs are defined as ECIPs specifying PROTOCOL ACTIVATION of any one or more Standards-Core track IP(s) at a specified activation block number.

Standards

Fork ECIPs should contain only placeholder information for ECIP-sets and block activation numbers while in WIP or Draft status.

Modification to any of Last Call, Accepted, or Final statuses should be accompanied by the introduction (merge) of a single change set containing COMPLETE and UNIQUE definitions of the placeholder values.

Change sets (eg Pull Requests) editing placeholder ECIP-set and block number information should do so with neither value in isolation; change sets modifying only ECIP-set values, or only block number values, are disallowed.

Motivation

Fork ECIPs represent a single idea: The next hardfork the blockchain is expected to undergo. This is a pragmatic and common approach to managing blockchain protocol maintenance and upgrades. Thus, it makes sense to use accessible and conceptually-unifying procedures for this challenge.

• Accessibility: Github provides an accessible user interface for viewing a Pull Request (proposed change set) against a single document.

• Legible and Communicable Reasoning: Requiring UNIQUE and COMPLETE change sets against against a Fork type ECIP demand presentation and consideration of proposed specifications as a whole.

• Sufficient specification: It is the job of Fork ECIPs to eventually provide precise and operable implementation specifications. Incomplete proposals (changesets) are inoperable; they are not ready for review, discussion, nor implementation. Any Fork ECIP lacking a COMPLETE feature set or block number is considered incomplete.

• Efficiency: Unique proposals save time and energy.

Historical motivations

Related to and derivative of:

• https://github.com/ethereumclassic/ECIPs/issues/217
• https://github.com/ethereumclassic/ECIPs/issues/215
• https://github.com/ethereumclassic/ECIPs/issues/175
• https://github.com/ethereumclassic/ECIPs/issues/131
• https://github.com/ethereumclassic/ECIPs/issues/177
• https://github.com/ethereumclassic/ECIPs/issues/135
• https://github.com/ethereumclassic/ECIPs/pull/218
• https://github.com/ethereumclassic/ECIPs/pull/212
• https://github.com/ethereumclassic/ECIPs/pull/207
• https://github.com/ethereumclassic/ECIPs/pull/214
• https://github.com/ethereumclassic/ECIPs/pull/199
• https://github.com/ethereumclassic/ECIPs/pull/196

Specification

A Fork ECIP is defined as an ECIP specifying any (n >= 1) Standards-Core track IP or IP-set and a block activation number for this set. A Fork ECIP should be conceptually complete and unique (note that Next hardfork suffices for the existing preference for ECIP uniqueness, since it is intended that there only be one at a time – hopefully!).

Complete is defined as being fully and totally definitive; not lacking anything.

Unique means not the same as another thing; in this case, not precisely duplicating any existing ECIP.

This proposal specifies that all Fork ECIPs in Draft state or earlier should contain NO information about ECIP-sets or block activation numbers (all TBD). Proposed specifications to fill these placeholders should be made in the form of distinct and separate propsed change sets (eg Github Pull Requests) to the Fork ECIP document. The changesets are required to be UNIQUE and COMPLETE.

There might be an ecip-X-FORK.md file that would look something like this:

---
lang: en
ecip: <ECIP number>
title: <ECIP title>
author: <list of authors' real names and optionally, email addrs>
discussions-to: <email address>
status: <WIP | Draft>
type: Fork
created: <date created on, in ISO 8601 (yyyy-mm-dd) format>
replaces: <ECIP number>
superseded-by: <ECIP number>
resolution: <url>
---

### Abstract

Specifying a next hardfork for the following networks:

- <Network Name or Identifier>
- <Network Name or Identifier>

### Motivation

### Specification

- __Block Activation Number(s)__: 
  + <Network Name or Identifier>: `TBD`
  + <Network Name or Identifier>: `TBD`

- __Feature specification(s)__:
  + TBD

### Rationale

### Implementation

### Copyright/Licensing

Rationale

The sole purpose of a Fork ECIP is to join a block number (activation block) with a set of n >= 1 Standards-Core type IPs containing protocol-facing changes. The document says “These features will activate at this moment.”

1. “Shell” format Fork ECIPs represent a clear, albeit abstract, idea: One or many blockchains’ next hard fork (eg. chains Ethereum Classic, Morden, Kotti).

2. Demanding fully-formed Fork ECIP Changeset proposal forces authors, editors, and reviewers to evaluate and document ECIP-set behavior and enables concrete discussion of feature sets as complete wholes. A Fork ECIP Changeset may represent a plurality of features, and so in order to be an operable specification it should not represent an ambiguous set. Sets of ECIPs can have interoperative dependencies and outcomes; this causes a conceptual permutation and combination challenge when attempting to design a set of ECIPs for simultaneous inclusion. The intention of this specification is make these logical steps as explicit and document and accessible as possible, in order that good decisions can be made with a process of open and constructive collaboration, enabled by named and concrete options.

3. Fork ECIP Changesets without block numbers lack operability. Activation numbers are specifications and should not be treated as a second class or at-convenience citizens. Implementation timelines are importantly related variables to their adjacent ECIP-sets (large set ostensibly require long timelines, hotfix sets require short ones.) We cannot reason about them in isolation.

4. Concrete things are easier to build language and reasoning around. Nuances of interoperations are documented and included in concrete proposals, leaving less theoretical abstract reasoning to manage, which is relevant in the context of group and individual decision making. “Competing” Fork ECIP Changeset alternatives become explicit and standardized, yielding conceptual and communicable clarity in review processes and decision-making processes.

Alternatives considered

Use distinct UNIQUE and COMPLETE ECIPs to describe fork specification options.

However, allowing fully-formed alternative and “competing” ECIPs is logistically and practically difficult to use. Currently, our most prominently used collaboration tool, Github, does not provide an accessible UI for comparing arbitrary documents or review separate arbitrary documents as a conceptual set.

Implementation

A Fork ECIP should achieve Last Call as a change set has been successfully merged. Conversely, a Fork ECIP with non-empty specifications may not see Draft or WIP status; it may only otherwise be Final, Withdrawn, or Rejected.

This proposed procedure makes only marginal conceptual changes to existing practices, demanding only that what was taken as implication, subtext, or context before now be made explicit. Rather than reviewing actual-or-theoretical proposed changesets to an ECIP (which sadly, have historically usually been theoretical), this forces proposed Fork ECIP specification outcomes to assume fully qualified and standardized formats before becoming eligible for consideration.

Copyright/Licensing

MIT.