What is ERC-20?

If you're familiar with ERCs then feel free to skip ahead.  I'm starting from the very beginning to ensure we all get to the same place by the end of this.  I started with Ethereum development and suspect others may have as well, so in addition to approaching this from a beginner's point of view, will also draw comparisons to what is similar or different to Ethereum standards.

Before we talk specifically about ERC-20, let's dissect that a bit further and talk about ERCs in general.  ERC stands for Ethereum Request for Comment (ERC).  It's an official protocol for proposing improvements to the Ethereum network.  We can explore the ERC origin a bit further by diving into Requests for Comment (RFCs).

A RFC takes the form of a memorandum and describes methods, behaviours, research, innovations or other components related to the subject in question.  It gets submitted for peer review in order to convey new concepts, proposals, information, or sometimes - for no good reason at all. RFCs are common-place components used by principal technical development and standards organizations.

ERCs at their core are just RFCs and a category of standard track Ethereum Improvement Proposal (EIPs).  The very first EIP-1 lays this out in much more detail, but to summarize - EIPs describe standards for the Ethereum platform including core protocol specifications and follow one of three tracks:

1. Standard track EIPs  - describe any change that affects most or all Ethereum implementations.  They consist of three parts: design document, implemenation, and if warranted - an update to the formal specification.
2. Meta EIPs - describe a process surrounding Ethereum or proposes a change to an existing process.  They propose an implementation (but not to Ethereum's codebase) and require community consensus.  They are not just recommendations and users typically have to implement them - they are not optional.
3. Informational EIP - describe Ethereum design issues or provide general guidelines or information to the Ethereum community.  They do not propose a new feature.  They do not necessarily represent consensus of the Ethereum community so users/implementers are free to ignore them if so desired.

Basically, if you want to know how the Ethereum network is currently setup - read through the finalized EIPs.  If you want to know how it might change - check out the draft EIPs.  Each EIP has a status ranging from draft to final (core or non-core) and it moves from status to status via the EIP Work Flow.  Again, take a look at EIP-1 if you want to get into the details of how this all works.

Standard track EIPs are broken down into four categories:

• Core
• Networking
• Interface
• ERC

So, after all that - we now know that ERCs are application-level standards and conventions, including contract standards such as token standards (including ERC-20), name registries, URI schemes, library/package formats, and wallet formats , networking, interface, ERC, meta, and informational.

EIP-20 is Ethereum's finalized ERC-20 Token Standard authored by Fabian Vogelsteller and Vitalik Buterin.  It allows for the implementation of a standard application programming interface (API) for tokens within smart contracts.

Before we get into tokens and explore why one might want to create and use them, let's extrapolate the EIP process over and understand how NEAR Protocol handles proposals and ongoing development.

NEAR's improvement proposals act in same manner/have same function as EIPs but obviously apply to NEAR Protocol specifications and standards.  They are called NEAR Enhancement Proposals (NEPs).  Submission of RFCs and discussion occur on Github through pull requests and subsequent discussions, but end result is that accepted changes and enhancements get reflected in the current set of the NEAR Protocol Specification.  For example, pull request 21 is the origin of the fungible token standard and once it was approved - it made its way into the specification.

NEP specifications are currently divided into the following categories: Block Chain Layer, Chain, Data Structures, Economics, Genesis Config, Runtime, and Standards.

The Fungible Token Standard is NEAR's equivalent (ish) to Ehereum's ERC-20 Token Standard.  Like ERC-20, it provides a standard interface for fungible tokens that allows for ownership and transfer - specifically targeting third-party marketplace integration.  It is not a simple replication as NEAR faces some challenges that require additions to the standard.

Challenges NEAR faces

NEAR uses an asynchronous runtime (means things can run concurrently instead of one after the other) and it is sharded.  While this improves things like scalability and transaction speed, it causes some unique challenges as it's possible that the same contract can reside on two different shards and the storage for those contracts can be split across different shards.

In a practical sense - this means that one could query the balance of tokens in a contract and then initiate some kind of spending or transfer based on that balance.  However, by the time that balance info is received, the contract could have actioned some other transfer altering the real current balance.  That's obviously problematic - a contract can't rely on the state of another contract and expect that state not to change.

One way around this is to temporarily partially lock the state with a callback to unlock it.  However, that can be prone to dead locks and requires careful engineering.  NEAR currently aims to avoid implementing locks in this standard by transferring ownership to an escrow account in order to complete most of the actions in the standard. There is a current NEP (safes) that could modify this requirement for an escrow account.

By way of contrast, Ethereum doesn't currently have these issues although that might change with Eth 2.0 when sharding is introduced.  There is no escrow account or other added implementation needed to deal with ERC-20 actions on the Ethereum blockchain because there currently is no state splitting, thus the contract can rely on the state of another contract directly.

As of this writing the standard is on V0.2.0.  That in itself tells us that once standards are in place, they can still be subject to revision, update, or changes if deemed necessary and consensus is achieved.  As a developer then, it's important to monitor the standards for changes to ensure any projects built with them continue to function properly.  Given they are standards, it would be much more likely for a change to incorporate an agreed on new feature than change un underlying foundational aspect - otherwise the standard is at risk of hurting the ecosystems built on them.

Key Takeaways

• Like Ethereum, NEAR uses a system to submit, discuss, and consider NEAR Enhancement Proposals (NEPs) that is derived from RFCs
• Among the protocol specifications outlined in the NEPs are standards specifications
• NEAR's fungible token standard builds on functionality provided in Ethereum's ERC-20 standard to consider specific challenges related to sharding of both state and storage
• The most up to date approved version will always be in the NEAR Protocol Specification

Next Up

Shortly, we'll cover the implementation of the Fungible Token Standard and compare it to the ERC-20 token, but first, let's ask the question why we need a fungible token standard in the first place.