Ethereum Classic: Putting Together the New Decentralized ECIP Process

In a previous article I wrote about decentralizing the Ethereum Classic Improvement Proposal process (ECIP) using the StarIP Standard by Zach Belford and Shane Jonas, ETC core developers at ETC Labs Core, which proposes a deterministic numbering system so ECIPs can be located in different team repositories while minimizing conflicts. Then, Wei Tang, Rust developer at Parity Technologies and ETC contributor, built the 24-ECIPURI system which solves the search and discovery problem of having ECIPs in different places.

Both of the above systems build upon the existing, but centralized, ECIP process which works using Github’s software versioning system. In this article I will describe how the three components mentioned above (the StarIP, 24-ECIPURI and old centralized ECIP process on Github) can be put together to serve as ETC’s new decentralized ECIP process. This compilation work was done with Zach Belford, Yaz Khoury, Tomaz Karizand Anthony Lusardi, amongst other contributors of the ETC ecosystem.

Putting together the old centralized ECIP system on Github, the StarIP Standard and the 24-ECIPURI search and discovery system.

A. Deterministic Numbering Using the StarIP Standard

The process uses the ECIP “preamble” format, but uses the metadata in it to hash it and then present it in a simple yet deterministic numbering form to minimize conflicts across ETC developer teams’ proposals. The steps are:

1. Defining the Preamble Metadata Format

The preamble metadata is the first step developers do to write an ECIP and borrows the format from the existing ECIP process. Below is an example:

Preamble Metadata

Title: Byzantium on block 696969
Author: Santa Clause <a@b.c>
Discussions-To: a@b.c
Status: Draft
Type: Standards Track
Created: 2020–05–25
Replaces: kRau7PZs
Superseded-By: ZxftDmL3

2. Hashing and Numbering

The above preamble metadata is hashed using SHA-3-512 to create a hex hash, which is encoded into BASE58, the address format used by Bitcoin. Then, the last 8 characters are used as the ECIP version number, of which the last 4 are used as a human friendly proposal number:

Preamble Hash

dca43940494f871c98774d0589902f9feabaa25231fd42309046cfc95ac7463744232b580d3007116f3ed9e65472ec444e6ac145f8803c33e518874518276ed7

Preamble Hash in BASE58

5QriUGKsjSwa73E7KKQYjysBfwqCzNY21f6iUSxQwqN8yvKAEtcT9nzvWKHdHdt6zsJmrWXhJJGCZESa6z9ekMre

Version Hash

6z9ekMre

Proposal Number

kMre

3. Preamble With Proposal Number and Version Number

This is the preamble format including the numbering system:

The sample preamble above, although it contains the new ECIP and version numbers, is still not finalized as it needs to contain the URIs as explained in the section below.

B. Search and Discovery Using the 24-ECIPURI Specification

The above system accomplishes the goal of standardizing ECIP preambles and numbering them deterministically. The 24-ECIPURI system makes it easier to search, discover and follow ECIPs. The steps are:

1. URI Standardization

If a developer team decides to use their own location for managing their ECIPs the standard URI is:

ecips.teamdomain.tld/ecip-proposalnumber

Using the example of the preamble in section A, the URI would be:

ecips.santaclaus.com/ecip-kmre

If a developer team were to decide to use Github then the URI would be:

github.com/teamname/ecips/ecip-proposalnumber

Using the example of the preamble in section A, the URI would be:

github.com/santaclaus/ecips/ecip-kmre

As Wei Tang mentions in his proposal, the domain part of the specification URI acts as the specification’s registry.

2. Finalized ECIP Preamble With URIs

Using the example in section A, adding the URI format above and a discussion section, this is the resulting finalized ECIP preamble format:

ECIP: kMre
Title: Byzantium on block 696969
Author: Santa Clause <a@b.c>
Discussions-To: a@b.c
Status: Draft
Type: Standards Track
Created: 2020–05–25
Version: 6z9ekMre
Replaces: kRau7PZs
Superseded-By: ZxftDmL3
URI: ecips.santaclaus.com/ecip-kmre
Discussion URL: github.com/santaclaus/ecips/ecip-kmre/issues/1

The “Discussion URL” will usually be the comments sections and system used on Github which supports branching, pull requests, comments, issues and merging.

3. Authoritative Specifications and Aggregation

24-ECIPURI includes two standard components, the “well-known” locations directory and the “authoritative specification” in the form of a specs.json document that can be hosted in an independent directory, Github or IPFS.

This is an example of an actual specs.json document:

Specs.json document example from 24-ECIPURI.

Below is an example of an ECIP independent aggregation site at ecips.that.world by Wei Tang:

ECIP aggregation page at That.World by Wei Tang.

C. Preserving the Old ECIP Process on Github or Future Software Versioning Platforms

As it may be seen in sections A and B above, both StarIP and 24-ECIPURI use the Github platform for software versioning. In the same manner, all ECIPs from all teams should go through the original process described in the old ECIP process on Github or whichever versioning platform may be used in the future. This includes the contributing policies and ECIP status terms as showed in the old standard process diagram:

Conclusion

With the StarIP deterministic numbering standard, ETC developer teams can now start proposals in their own Github repositories, following the same standard ECIP process as before, while other developers and ecosystem participants can still view, contribute, discuss and fork their proposals into their own repositories.

When ETC developer teams finish conducting open and public discussions about ECIPs, they can signal their readiness and acceptance of proposals by merging them into their local ETC clients.

Although the new decentralized ECIP process presented in this article may have some extra steps for teams when starting ECIPs to ensure discovery while minimizing numbering conflicts, the positive tradeoff is that Ethereum Classic, as an ecosystem, is replacing a centralized process with few admins, with a decentralized improvement proposal process that is much more open, therefore, more aligned with blockchain principles in general and ETC’s ethos in particular.

It is important to note that although the system is decentralized, it still requires that ETC developer teams follow minimal standards when proposing consensus changes using the ECIP process.

Those standards are:

• A preamble metadata format with required information

• A common hashing and numbering mechanism

• Including the numbering in the preamble

• Certain URI standards when using independent or Github servers

• Common known.json and specs.json file formats with common known directories

• A final preamble format including the ECIP URL and discussion URL

• Using the old ECIP contributing policies and status terms

The new decentralized ECIP process above is hereby presented to the ETC ecosystem and is open for discussion, which can be located at:

• StarIP: https://github.com/BelfordZ/starIPs/issues

• 24-ECIPURI: https://github.com/ethoxy/specs/issues/4

• Discord #ecips channel: https://discord.gg/h8X9gB