Fairyproof provides a go-to guide to understand Ethereum standards and their security.

The Ethereum blockchain is built on a series of rules called Ethereum Standards. It may seem daunting to understand what these standards are. That is why we are here to give you a simple explanation on everything you need to know about Ethereum standards and what you would need to do if you would like to dive deeper into being a part of building the world of Ethereum.

Ethereum Standards Explained

In a nutshell, Ethereum standards are different documents of code that defines the design and principles of the Ethereum blockchain. They are also known as Ethereum Improvement Proposals (EIPs): Proposals of different aspects in the Ethereum blockchain covering various technical specifications and the rationale behind said proposals. EIPs mainly define Ethereum Core functions, represented as “EIP” with a set of assigned numbers: “EIP-XXXX”.

Whenever an EIP is submitted for review, the proposal will be assigned a new, usually three-digit or four-digit number (Like EIP-3712, EIP-100, etc.).

Different EIPs serve different purposes. According to Ethereum’s official EIP Purpose and Guidelines playbook, EIP-1, EIPs come in three different main categories:

1) Standard Track EIP: Refers to changes that affects most or all Ethereum implementations (Like network protocol, or block or transaction validity rules). These EIPs consist of three parts — A design document, an implementation, and, when needed, an update to the formal specification.

a. Core: Improvements requiring a consensus fork (Like EIP-5), and changes that are not necessarily consensus critical but may be relevant to “core dev” discussions (Like the miner/node strategy changes 2, 3 and 4 of EIP-86).

b. Networking: Improvements involving devp2p (EIP-8) and Light Ethereum Subprotocol, and improvements to network protocol specifications of whisper and swarm.

c. Interface: Improvements around client API/RPC specifications and standards, and certain language-level standards like method names (EIP-6) and contract ABIs.

d. ERC: Application-level standards and conventions such as token standards (Like EIP-20), name registries (Like EIP-137), URI Schemes (EIP-681), and more. ERCs are usually represented by an “ERC” indication with a set of assigned numbers: “ERC-XXXX”

2) Meta EIP: Also considered a Process EIP, Meta EIPs describe a process surrounding Ethereum or proposes a change to (or an event in) a process. Process EIPs are like Standards Track EIPs but apply to areas outside the Ethereum protocol itself. They may propose an implementation, but not to Ethereum’s code base. Examples include procedures, guidelines, changes to the decision-making process, and changes to the tools or environment used in Ethereum development.

3) Informational EIP: Describes an Ethereum design issue or provides general guidelines or information to the Ethereum community. They do not propose new features and do not necessarily represent Ethereum community consensus or a recommendation, so users are free to ignore or follow informational EIPs.

All submitted proposals are open-sourced. This means that you can find everything you need to know from the full list of EIPs here should you require more in-depth knowledge on specific proposals.

Drafting EIPs or ERCs: The Process

Stage 1 (IDEA): Drafting an EIP is not as hard as you think. Just like any other product or project, it starts with an idea — an idea to solve a specific problem present in the Ethereum ecosystem. These ideas can be based on developing Ethereum applications more effectively or efficiently, or to fix an existing issue. This is the stage where you pre-draft your proposal: It always helps to hold casual discussions with those familiar with the Ethereum ecosystem if you are an individual, or discuss internally when you are in a project group, to help you elaborate the idea and give you a clear mind-map of the objectives of the proposal. Doing so will also provide you a solid skeleton in writing your first draft based on EIP’s format and requirements.

Spend meaningful time in this stage to best establish the credibility of your proposal here. In this stage of ideation, the draft is not tracked within the EIP Repository.

The best playbook on creating successful EIPs is through EIP-1. They even provide a template for you to guide you through your drafting.

Stage 2 (DRAFT): This is the stage where your EIP and its development gets formally tracked. The moment you have drafted your proposal (Ensure you follow the template), you will have to clone the repository, add your EIP to the clone, and submit your draft through a Pull Request.

Stage 3 (REVIEW): The moment your draft is formally submitted, it will be assigned a number, and proceeds to the “Peer Review” phase where different groups and individuals from the community will review your draft and propose changes. Drafters can usually find comments for changes or security considerations through this website. You will then have to make those changes to proceed. The draft can enter any of the following three sub-stages during this time:

Stage 3.1 (LAST CALL): This is the final review window for an EIP, where the review window will be assigned a deadline, usually after 14 days. Should there be the need for more normative changes, the draft reverts to the main “Review” stage.

Stage 3.2 (LIVING): A special status for EIPs that are designed to be continually updated and not reach a state of finality.

Stage 3.3 (STAGNANT): Any EIP in “DRAFT”, “REVIEW” or “LAST CALL”, if inactive for a period of 6 months or more is moved to “STAGNANT”. The EIP can be revived by moving it back to “DRAFT” or its earlier status. If not resurrected, an AIP may stay forever in this status.

Stage 4 (FINAL): Once the final review has passed its two-week mark in its last call and finalized, the EIP is then to represented as “final”. It exists in a state of finality and should only be updated to correct errata and non-normative clarifications. This is where your EIP will be integrated as standards or be included in a broader network of upgrades, depending on the nature of your EIP.

It is also worth noting that your EIP can reach a possible Stage 5 (WITHDRAWN) should you deem the proposal no longer effective or relevant and wish to remove it. The EIP is this state can no longer be resurrected using the same EIP number. If you would like to revive the proposal, it is considered a new proposal where you will have to go through the whole process again.

Fairyproof-Drafted EIPs and ERCs

You might wonder how Fairyproof is so familiar with the world of Ethereum standards and how they are drafted. That is because we are proud drafters of a number of them:

The Rules of Drafting EIPs or ERCs: A Security Perspective

“The Ethereum protocol is permissionless — Anyone with the correct technical knowledge can draft new Ethereum standards. An excellent rule of thumb for new and budding individuals or teams looking to draft a standard is to read good, classical EIPs and learn from them. The key to drafting good Ethereum standards is clarity: Identify the problem you are looking to fix and how your idea sets out to solve said problem. It also helps that you keep your idea organized, prepare a sample code, and list various security considerations and backward compatibility issues for the review team to consider. Above all else, read the EIP format and follow it carefully and strictly.”

- Tan YuefeiCEO, Fairyproof

Different EIPs are drafted to solve different problems. Naturally, different security concerns would be introduced based on different EIPs. Not all EIPs would suffer from the same security concern.

However, implementers tend to commit common mistakes when implementing EIP based applications. These mistakes include access control to functions, vulnerabilities in business logic, security issues with Solidity instructions, not following the template, or simply that the proposal fundamentally fails to solve a specific problem as it introduces more and more security concerns. Common mistakes are numerous, which is why it is advised to look into reading good, classical EIPs as a guideline to strengthen the credibility of the one you are drafting while always referring to EIP-1.

Conclusion

Rome was not built in a day — And so is Ethereum. Before you set out to draft a new EIP, just remember:

For New Individuals or Project Teams: Make sure you dive deep into the Ethereum ecosystem, study its pain-points, and think about solutions in a more general, big-picture way. Look at solving problems from an architectural perspective and be bold in creating EIPs and ERCs based on the solutions you have thought out.

For Veterans: Keep working, don’t settle. Ethereum has a long way to go.

The amazing fact that you do not require permission to draft Ethereum standards makes Ethereum a wonderful project to join, collaborate, and contribute.

Now, go and be a part of Ethereum’s development and success!

Join our Telegram group to stay up-to-date on hacks and other security situations in the crypto space.

To stay updated on notable security incidents in the world of Web3.0, subscribe to our newsletter.

Looking to strengthen the security of your project? Contact us at https://fairyproof.com