Yahoo Finance A guide to Ethereum’s ERC standards
Ethereum is a blockchain-based decentralised platform designed for running smart contracts. As explained here, a smart contract is a program that runs exactly as coded by its creator. It is essentially an execution that can be set up ahead of time to trigger automatically once certain conditions are met.
The Ethereum Virtual Machine (EVM) runs on the Ethereum network and allows anybody to run a program, making the process of building blockchain applications much simpler. Developers don’t need to build a new blockchain from scratch for each application, and they’re not tied down to a particular programming language.
In essence, Ethereum is building the first decentralised world computer on a public blockchain.
Smart contracts are important because they allow for the creation of decentralised applications (dApps) that can automate processes and run with no possibility of censorship or downtime.
As most of you know, the native currency for Ethereum is called Ether (ETH), which powers the platform through transaction fees. However, one of the biggest features of Ethereum is the ability for anyone to create unique tokens that exist and operate on the Ethereum blockchain – which can have multiple utility-like purposes.
So what is an ERC standard?
ERC is an acronym that stands for Ethereum Request for Comments. ERCs are application-level standards for Ethereum and can include token standards, name registries, library/package formats, and more. Anyone can create an ERC, but it is the author’s responsibility to clearly explain their standard and foster support for it within the community.
Common ERC standards define a required set of functions for a token type, allowing applications and smart contracts to interact with them in a predictable way.
The most common ERC standard used to date is the ERC-20, a type of standard that makes the creation, use, and exchange of Ethereum-based tokens quite simple.
However, crypto-enthusiasts should be aware of the issues that may arise when different projects adopt limited functionality from each standard, making their smart contracts different from a proper ERC standard. This is a problem I discuss in the final section of this guide.
For now, let’s focus on the different types of ERC standards.
Types of ERCs
There are a number of ERC standards that serve multiple purposes. The top five in terms of adoption and usability are as follows:
ERC-20: This is the standard API used for fungible tokens, including transfer and balance tracking functionalities.
ERC-223: This standard protects users from accidental contract transfers.
ERC-721: This is the most popular non-fungible token (NFT) standard. While fungible tokens can be divided, non-fungible tokens can not. NFTs can be owned and transacted by individuals as well as consigned to third-parties. NFTs can represent ownership over digital or physical assets.
ERC-809: This standard is used to rent rival non-fungible tokens. An NFT is described as ‘rival’ if its use/ownership by one individual prevents simultaneous use/ownership by other individuals. ERC-809 allows an owner to rent access to their rival NFTs using a standard set of commands, and users can view all past and current rental agreements from a single wallet interface.
ERC-1238: This standard covers non-transferable tokens (or ‘badges’).
Pros and cons of ERCs
There’s plenty of advantages to using ERC standards. Just like libraries, they help developers to use proved code instead of building from scratch. They also enable users to deploy code faster for standard-like processes. Some examples are the creation of token contracts, crowdsales (common during the ICO boom), escrows, and tracking.
With ERCs, it’s possible to easily build wizards and oracles on top of smart contract applications in order to allow for better user interfaces.
The problem though is that some ERC contracts – especially those deployed during the ICO boom – do not fully respect the standards.
Although one might think the implications are negligible, that’s not true. For instance, if another developer team wants to use a certain token which has been validated as an ERC-20 on a smart contract application they’ve developed and the smart contract does not fully respect the ERC-20 standard, the token can easily be lost due to the lack of functionality.
Therefore, if a smart contract is treated as an ERC-20, it should possess all ERC-20 functionality, otherwise it may lead to developer errors. Another issue – and this one is a biggie – is that some smart contracts may not guarantee a certain asset is solely in the possession of a user.
CryptoKitties is a great example.
By looking at this screenshot, we can see there is a “paused” and “onlyowner” functionality, meaning your kitties could be paused or frozen by the developers. Does that mean even with smart contracts we may not really be the proper owners of our tokens?
Having said that, with digital product applications, we may expect the team to hold some power over tokens in case there’s a problem.
Conclusion
ERC standards are a great step towards the adoption of smart contract technology.
Interoperability between applications will require standards, much like the ones presented above, which aid developers when creating, deploying, and maintaining smart contracts.
On the other hand, if there are not enough checks and balances and key ERC functionality is changed without notice, that may lead to unforeseen problems as smart contracts will lose the ability to fully interact with each other.
The post A guide to Ethereum’s ERC standards appeared first on Coin Rivet.
