In this article I describe an idea for a general model for ETC development teams to have as a sample to create their team ECIP sites. Also, independent non-developer teams or entities can host such sites so that more places can serve as aggregators and repositories for the decentralized ECIP system.
This model is based on Wei Tang’s ecips.that.world site, the 24-ECIPURI specification, Zachary Belford and Shane Jonas’ StarIP Standard, the ECIP-1000 process by Wei Tang which is based on Luke Dashjr’s BIP process, and a pending archiving proposal by Tomasz Zdybał.
The General Lifecycle of an ECIP
As it can be seen above an ECIP generally goes through four stages in the decentralized ECIP process:
1. Numbering
To minimize conflict between team ECIPs, a deterministic numbering system that hashes their preambles’ metadata is created so that each ECIP can be unique.
2. URI
To facilitate search and discovery, every ECIP is designated a specific URI in the format ecips.teamdomain.tld/ecip-proposalnumber or github.com/teamname/ecips/ecip-proposalnumber. Also, known.json and specs.json files are created and hosted to facilitate their aggregation.
3. Process
Just as the old ECIP process, all teams follow the presentation, rationale, status and discussion process to propose and accept or reject changes to the ETC consensus rules.
4. Archiving
In the new decentralized ECIP process all ECIPs are stored in each teams repositories after acceptance and merging. However, to guarantee their continued existence, authenticity and availability, in case teams migrate, quit, or delete ECIPs for any reason, a general ecosystem archiving system is needed. This archiving system will be proposed in the near future.
Model Site Structure
As seen above, the model site has three sections represented by the columns:
Home
It is the home of an ETC development team ECIPs or an independent ECIP aggregator. As in all improvement proposal sites in crypto (BIP, EIP, old ECIP, etc.), the home describes the process and shows the steps to submit, discuss, approve or reject ECIPs.
Local Team’s ECIPs
This section hosts the local team’s ECIPs, has a page for each one, and indicates where the discussion for each ECIP takes place.
All Aggregated ECIPs From all Other Teams
This section aggregates and shows all ECIPs that form, together with the Yellow Paper, the basis for all consensus rules in the ETC protocol. Each aggregated ECIP title and description points to the original ECIP referenced, which may be hosted locally or in a remote team’s website. Independent of where the ECIPs are located, they all have discussion pages or sections that may be hosted on Github, for example.
To facilitate aggregation, each ETC development team’s site also contains a known.json file directory of “known” ECIP directories and a specs.json file directory with all the ECIPs and their critical data.
At then end of the lifecycle of all ECIPs that are accepted and merged (and perhaps rejected, withdrawn and deferred, as well) they need to be archived in the “archiving” step at the bottom of the diagram to assure their immutability, authenticity and long term integrity and availability. These archives can be hosted by all ETC development teams and other entities.
As it can be seen in the diagram above, all teams, and everybody else for that matter, can participate, discuss, create pull requests, issues, fork and merge any other team’s ECIPs.
To see an example, the model site structure above is based on Wei Tang’s ECIP site at That.World: https://ecips.that.world/
The model decentralized ECIP site above is hereby presented to the ETC ecosystem and is open for discussion.
This and other topics about the decentralized ECIP process can be located at:
• StarIP: https://github.com/BelfordZ/starIPs/issues
• 24-ECIPURI: https://github.com/ethoxy/specs/issues/4
• Process ECIP-1000: https://github.com/ethereumclassic/ECIPs/blob/master/ECIPs/ECIP-1000.mediawiki
• Discord #ecips channel: https://discord.gg/h8X9gB
Code Is Law
