whysoserious
commented
7 years ago Hi Cody, I am Jan from Grothendieck team. I am working on a very similar thing as you: New-ECIP-Proposal. It's going to change very soon as this is work in progress. However TL;DR section should give you a big picture of what we are working on. Hopefully we'll be able to merge both docs into one document very soon.
For now I have only one issue to comment.
In my opinion a draft of an ECIP and comments should be stored off-chain. Blockchain should be used only for voting and managing status of ECIPs. I see no benefit of paying gas for adding a comment. Thus, initial list of fields of an ECIP proposal would look as follows:
- Title:
- Author: <list of authors' real names and optionally, email address>
- Description: < short description of the ECIP >
- URL to the full proposal description:
- Hash of the full proposal description:
curl -s URL-TO-THE-FULL-PROPSAL-DESC | md5 Comment array: < string array for on contract comment tracking>- more fields to follow - eg. start/end block when voting is allowed, status
realcodywburns
laddhoffman
A smart contract based system for ECIP management
Abstract
ECIP stands for Ethereum Improvement Proposal. An ECIP is a design document providing information to the Ethereum classic community, or describing a new feature for Ethereum or its processes or environment. The ECIP should provide a concise technical specification of the feature and a rationale for the feature. The ECIP author is responsible for building consensus within the community and documenting dissenting opinions. This system is currently managed using a github repository which does not allow for voting. By using a smart contract based system for tracking and managing ECIPs it is hope a broader participation from the community can be achieved.
Motivation
To overarching motivation for this proposal is to provide a medium for all future ECIP's a succinct environment allowing for financial transparency, a more inclusive decision making process, a disintermediation of proposals from the proposers and better funding channels to avoid centralization
Background
ECIP Types
There are three kinds of ECIP:
A Standard Track ECIP describes any change that affects most or all Ethereum implementations, such as a change to the [https://github.com/ethereum/yellowpaper Yellow Paper], the network protocol, a change in block or transaction validity rules, or any change or addition that affects the interoperability of applications using Ethereum. Furthermore Standard ECIPs can be broken down into the following categories. Consensus - Those ECIP's which effect the system of block creation Networking - Currently Networking discussion tracks in the [https://github.com/ethereum/devp2p devp2p repository].
An Informational ECIP describes a Ethereum Classic design issue, or provides general guidelines or information to the ETC community, but does not propose a new feature. Informational ECIPs do not necessarily represent Ethereum community consensus or a recommendation, so users and implementers are free to ignore Informational ECIPs or follow their advice.
A Meta ECIP describes a process surrounding Ethereum or proposes a change to (or an event in) a process. Process ECIPs are like Standards Track ECIPs but apply to areas other than the Ethereum protocol itself. They may propose an implementation, but not to Ethereum's codebase; they often require community consensus; unlike Informational ECIPs, they are more than recommendations, and users are typically not free to ignore them. Examples include procedures, guidelines, changes to the decision-making process, and changes to the tools or environment used in Ethereum development. Any meta-ECIP is also considered a Process ECIP.
Definitions
Registry: A publicly accessible smart contract that allows individual ECIPs the ability to register. It should be robust enough to provide:
ECIP contract: Smart contract that contains meta-data relating to the ECIP. At a minimum it should:
Front-end system: Any system external to the ECIP contracts which is able to submit web3(or similar) calls to the ETC EVM to retrieve information from contracts and present the data in a user friendly interface ECIP collaborators – trusted community members assigned as administrators to the registry.
Legacy ECIP Process:
Proposed ECIP Work Flow
The ECIP process begins with a new idea for Ethereum Classic. It is highly recommended that a single ECIP contain a single key proposal or new idea. Small enhancements or patches that don't affect consensus often don't need an ECIP and can be injected into the ETC development workflow with a patch submission to the corresponding ETC issue tracker. The more focused the ECIP, the more successful it tends to be. The ECIP editor reserves the right to reject ECIP proposals if they appear too unfocused or too broad. If in doubt, split your ECIP into several well-focused ones.
Each ECIP must have an Owner -- someone who writes the ECIP using the style and format described below, submits the smart contract to allow for discussion, and attempts to build community consensus around the idea. The ECIP champion (a.k.a. Owner) should first attempt to ascertain whether the idea is ECIP-able.
Vetting an idea publicly before going as far as writing an ECIP is meant to save the potential author time. Asking the ETC community first if an idea is original helps prevent too much time being spent on something that is guaranteed to be rejected based on prior discussions (searching the Internet does not always do the trick). It also helps to make sure the idea is applicable to the entire community and not just the author. Just because an idea sounds good to the author does not mean it will work for most people in most areas where ETC is used.
Once the owner has asked the ETC community as to whether an idea has any chance of acceptance, a draft ECIP should be registered on the ETC chain using a standard ECIP contract and the ECIP registry. This gives the author a chance to flesh out the draft ECIP to make properly formatted, of high quality, and to address initial concerns about the proposal.
Once submitted to the registry contract the ECIP will be reviewed by the ECIP collaborators for fitness, grammar, and purpose the ECIP registry will assign the ECIP a number, label it as Standards Track, Informational, or Process, give it status "Draft", and add it to the git repository. The ECIP editor will not unreasonably deny an ECIP. Reasons for denying ECIP status include duplication of effort, being technically unsound, not providing proper motivation or addressing backwards compatibility, or not in keeping with the ETC philosophy.
The ECIP author may update the Draft as necessary in their smart contract. The ECIP itself should not be stored on chain.
Standards Track ECIPs consist of three parts, a design document, implementation and finally if warranted an update to the [https://github.com/ethereum/yellowpaper formal specification]. The ECIP should be reviewed and accepted before an implementation is begun, unless an implementation will aid people in studying the ECIP. Standards Track ECIPs must be implemented in at least two viable Ethereum clients before it can be considered Final.
ECIP authors are responsible for collecting community feedback on an ECIP before submitting it for review. However, wherever possible, long open-ended discussions should be avoided. Strategies to keep the discussions efficient include: having the ECIP author accept private comments in the early design phases, setting up a wiki page or git repository, etc. ECIP authors should use their discretion here. Whenever possible, set an end date or block number for final comment.
For an ECIP to be accepted it must meet certain minimum criteria. It must be a clear and complete description of the proposed enhancement. The enhancement must represent a net improvement. The proposed implementation, if applicable, must be solid and must not complicate the protocol unduly.
Once a ECIP has been accepted, the implementations must be completed. When the implementation is complete in at least two viable clients and accepted by the community, the status will be changed to "Final". An update to the [https://github.com/ethereum/yellowpaper formal specification] should accompany the "Final" status change.
An ECIP can also be assigned status "Deferred". The ECIP author or editor can assign the ECIP this status when no progress is being made on the ECIP. Once a ECIP is deferred, the ECIP editor can re-assign it to draft status.
A ECIP can also be "Rejected". Perhaps after all is said and done it was not a good idea. It is still important to have a record of this fact.
ECIPs can also be superseded by a different ECIP, rendering the original obsolete. This is intended for Informational ECIPs, where version 2 of an API can replace version 1. Some Informational and Process ECIPs may also have a status of "Active" if they are never meant to be completed. E.g. ECIP 1 (this ECIP).
What belongs in an ECIP contract?
Each ECIP should have the following parts:
Title:
Author: <list of authors' real names and optionally, email address>
Description: < short description of the ECIP >
External Url:
Comment array: < string array for on contract comment tracking>
Transferring ECIP Ownership
It occasionally becomes necessary to transfer ownership of ECIPs to a new champion. In general, we'd like to retain the original author as a co-author of the transferred ECIP, but that's really up to the original author. A good reason to transfer ownership is because the original author no longer has the time or interest in updating it or following through with the ECIP process, or has fallen off the face of the 'net (i.e. is unreachable or not responding to email). A bad reason to transfer ownership is because you don't agree with the direction of the ECIP. We try to build consensus around a ECIP, but if that's not possible, you can always submit a competing ECIP.
If you are interested in assuming ownership of a ECIP, send a message asking to take over, addressed to both the original author and the ECIP editor. If the original author doesn't respond to email in a timely manner, the ECIP editor will make a unilateral decision (it's not like such decisions can't be reversed :).
ECIP Editors
The current ECIP editors are:
ECIP Editor Responsibilities & Workflow
For each new ECIP that comes in, an editor does the following:
If the ECIP isn't ready, the editor will send it back to the author for revision, with specific instructions.
Once the ECIP is ready for the repository, the ECIP editor will:
Assign a ECIP number (almost always just the next available number)
Assign the appropriate fields in the registry for type, tract, and status
Send email back to the ECIP author with next step.
Many ECIPs are written and maintained by developers with write access to the ETC codebase. The ECIP editors monitor ECIP changes, and correct any structure, grammar, spelling, or markup mistakes they see.
The editors don't pass judgment on ECIPs. They merely do the administrative & editorial part. Except for times like this, there's relatively low volume.
Voting
…
Implementation
A reference ECIP smart contract can be found at [[ 0xd9605C12abc5Bfb83bbab80d286821D110dA2dD3 ]] JSON-ABI: [{"constant":false,"inputs":[{"name":"_title","type":"string"},{"name":"_author","type":"string"},{"name":"_description","type":"string"},{"name":"_extUrl","type":"string"},{"name":"_type","type":"string"}],"name":"startecip","outputs":[],"payable":true,"type":"function"},{"constant":true,"inputs":[],"name":"created","outputs":[{"name":"","type":"uint256"}],"payable":false,"type":"function"},{"constant":true,"inputs":[],"name":"extUrl","outputs":[{"name":"","type":"string"}],"payable":false,"type":"function"},{"constant":false,"inputs":[],"name":"kill","outputs":[],"payable":false,"type":"function"},{"constant":true,"inputs":[],"name":"title","outputs":[{"name":"","type":"string"}],"payable":false,"type":"function"},{"constant":false,"inputs":[],"name":"bailout","outputs":[],"payable":false,"type":"function"},{"constant":true,"inputs":[],"name":"description","outputs":[{"name":"","type":"string"}],"payable":false,"type":"function"},{"constant":false,"inputs":[{"name":"_comment","type":"string"}],"name":"comment","outputs":[],"payable":false,"type":"function"},{"constant":true,"inputs":[],"name":"author","outputs":[{"name":"","type":"string"}],"payable":false,"type":"function"},{"anonymous":false,"inputs":[{"indexed":false,"name":"comment","type":"string"}],"name":"newComment","type":"event"}]
The ECIP master registry contract is located at [[ ]]
History
This document was derived heavily from [https://github.com/bitcoin/bips Bitcoin's BIP-0001] written by Amir Taaki which in turn was derived from [https://www.python.org/dev/peps/ Python's PEP-0001]. In many places text was simply copied and modified. Although the PEP-0001 text was written by Barry Warsaw, Jeremy Hylton, and David Goodger, they are not responsible for its use in the Ethereum Classic Improvement Process, and should not be bothered with technical questions specific to ETC or the ECIP. Please direct all comments to the ECIP editors.