An EIP can be submitted by anyone, and becomes the responsibility of the author once they’re created. The author informs other developers of their proposal, gathers support to build and launch it, and documents work throughout the process.
The majority of EIPs are Standards Track EIPs, proposals that change the Ethereum protocol itself. Broadly, anything that technically changes Ethereum is a Standards Track EIP. There are several sub-types under the Standards Track:
– Core
– Network
– Interface
– ERC
Core EIPs
Core EIPs are changes drastic enough to require a fork in the blockchain. Forks are when the blockchain splits in two because of a major decision, with one path following the old rules and the new path following the new ones.
Networking EIPs
Networking EIPs are improvements to nodes communication and transactions are transmitted on Ethereum. Transactions are encrypted when sent; when I send you funds, I’m encrypting a message that only you can decrypt. Changes to these aspects are Networking EIPs.
Interface EIPs
Interface EIPs are improvements for how applications interact with Ethereum. They standardize the API used for communication with the blockchain. An example is EIP-6, which changed an opcode on Ethereum from “Suicide” to “Self-Destruct” for mental health reasons.
ERC EIPs
Finally, ERC EIPs establish new standards on Ethereum, often for smart contracts. These standards are responsible for tokens on Ethereum (ERC-20) and non-fungible tokens (ERC-721) and many more. Without these standards, tokens wouldn’t be easily tradeable.
Additional EIP Types
Standard Track EIPs (the ones listed above) are the most common. The less frequent Meta EIP covers non-technical changes in process; how development overall is managed. Finally, instead of proposing new features, Informational EIPs elaborate on existing design details.
THE EIP Approval Process
EIP-1
EIPs can be proposed by anyone, but often require the work of multiple people depending on their impact. EIP Editors review EIPs that are submitted, and multiple developers are usually required to build a feature.
The effort to reward ratio factors greatly into which proposals are prioritized and which aren’t. They all follow an identical process that determines which EIPs get delivered first.
Before submitting an EIP, authors should first vet the idea with others in the Ethereum development community. Assuming the idea is not covered by an existing EIP, the author creates a draft and submits it to the EIP Editors.
There are different EIP Editors responsible for each sub-type of EIP; they’re responsible for making sure the proposals are technically sound. Once that’s done, they create the Draft version of the EIP.
Once an EIP Editor feels like the draft is ready to receive feedback from the community, they move it from being in Draft to in Review. At this stage, any member of the Ethereum development community can share their thoughts on how the proposal can be improved.
Once complete, the EIP enters the Last Call stage. This provides a final opportunity for feedback to be shared, usually within 14 days. If any major changes come up, the proposal moves back to Review. If no major feedback arises, then the EIP moves into the Final stage.
Once an EIP is Final, it becomes a candidate to include in Ethereum’s periodic upgrades (called forks). The process highlights the importance of individual responsibility in a decentralized environment.
No features would be delivered if not championed by at least one person to start, and each is only made complete through the process of peer-review.
May the brightest ideas win.
Thank you for reading! If you learned something interesting, sign up to my free newsletter below!
I’ll send you one email a week with a simple write-up on a blockchain topic. No ads, shills, or affiliations.
Stay kind. Stay curious. ????????️
https://ramiwrites.substack.com/
