DEV Community: CryptoShuriken

A Gentle Introduction to ERC Standards: ERC20 vs ERC721 vs ERC1155

CryptoShuriken — Thu, 03 Nov 2022 13:43:51 +0000

Hi, fren! gm. ☀️

In this blog post, we're going to cover some of the most common ERC token standards that are used for the creation of fungible, non-fungible, and semi-fungible tokens.

So, without further ado, let's get started!

First of all, WTH is ERC? 🤔

ERC stands for Ethereum Request for Comments, and it is a proposal document that developers write which is then reviewed by the Ethereum community using a process called 'Ethereum Improvement Proposal' or EIP.

What is ERC-20?

ERC-20 is the 20th proposal, which was proposed in 2015 by Fabian Vogelsteller and was integrated into the Ethereum blockchain in 2017. It is the most commonly used token standard in the Ethereum ecosystem.

The tokens created using the ERC-20 standard have three properties:

🔹 They are Fungible: meaning all tokens can be used interchangeably and each token holds the same value. Think of a Dollar bill 💵

🔹 They are transferrable: the tokens can be sent from one address to another.

🔹 They have a fixed supply.

The Need for ERC-20

So back in the day when everyone was trying to come up with their own fungible tokens, there were no set rules or guidelines for developing tokens. So, everyone had to reinvent the wheel to create their own tokens.

As a result, all the tokens were different from each other. This was extremely painful for developers to work with other tokens, and for exchanges and wallets to list and handle different tokens on their platforms.

The ERC-20 introduced a standard (or a set of rules) that allowed developers to create their own 'Fungible' tokens on the Ethereum blockchain. It laid out a set of guidelines that all Ethereum-based tokens must adhere to.

Today, wallets like Metamask and exchanges like Binance use the ERC-20 standard to list various standardized tokens onto their platforms and handle the exchange of value between them.

The Technical Aspects

ERC-20 provides a standard interface for fungible tokens.

So, what is an Interface? An interface defines rules that a program must follow.

In this case, it contains a set of functions and events that a smart contract must implement. While an interface doesn't specify how the functions or events should be implemented, it specifies what functions or events should be implemented.

The ERC-20 standard defines three optional and six mandatory functions that a smart contract should implement to create a fungible token.

The three optional ones are:

🔹 name(): returns the name of the token - e.g. ShurikenToken.

function name() public view returns (string)

🔹 symbol(): returns the symbol of the token - e.g. CST.

function symbol() public view returns (string)

🔹 decimals(): returns the number of decimals places the token uses. More on decimals here.

function decimals() public view returns (uint8)

The six mandatory functions are:

🔹 totalSupply(): determines the total supply of tokens. Once this limit is reached, the smart contract will refuse to mint new tokens.

function totalSupply() public view returns (uint256)

🔹 balanceOf(): takes in _owner address parameter and returns the number of tokens a given address holds.

function balanceOf(address _owner) public view returns (uint256 balance)

🔹 transfer(): transfers a certain number of tokens from the total supply to a user address.

function transfer(address _to, uint256 _value) public returns (bool success)

🔹 transferFrom(): allows users to transfer tokens from one address to another.

function transferFrom(address _from, address _to, uint256 _value) public returns (bool success)

🔹 approve(): verifies whether a smart contract is allowed to allocate a certain amount of tokens to a user considering the total supply, making sure that there are no extra or missing tokens.

function approve(address _spender, uint256 _value) public returns (bool success)

🔹 allowance(): how much an address is allowed to spend. Essentially it checks whether a user has enough balance to make transactions to another user.

function allowance(address _owner, address _spender) public view returns (uint256 remaining)

Apart from these functions, the smart contract should also emit two events:

🔹 Transfer: this event is emitted when some amount of tokens are transferred from one wallet to another. It gives the address of both the sender and recipient as well as the number of tokens transferred.

event Transfer(address indexed from, address indexed to, uint256 value);

🔹 Approval: this event is emitted when the approve() function is successfully executed.

event Approval(address indexed _owner, address indexed _spender, uint256 _value)

ℹ️ If you're unfamiliar with Events in Solidity, here's a fantastic blog post by Patrick Collins on the Chainlink blog.

The ERC-20 token standard provides a basic structure for the creation of fungible tokens in a uniform manner and takes out the complexities that used to be introduced with the "reinventing the wheel" approach in the earlier days.

Now that the significance of ERC-20 is clear, let's move on to another common token standard that powered the world of something we know as NFTs.

What is ERC-721?

While the ERC-20 token standard caters to the creation of fungible tokens, ERC-721 is the token standard for creating non-fungible tokens (NFTs). It was proposed by William Entriken, Dieter Shirley, Jacob Evans, and Nastassia Sachs from the CryptoKitties team in 2018.

ERC-721 defines a minimum interface a smart contract must implement to allow unique tokens to be managed, owned, and traded.

Unlike the ERC-20 standard, where there is no concept of "uniqueness", all tokens that are created using the ERC-721 standard are "non-fungible" or unique, and each NFT is linked to its respective owner and possesses its metadata and a unique tokenId.

Image Credit: ERC721.org

The use cases for the ERC-721 can be both digital & physical ownership. We can own digital assets like digital art, music NFTs, digital land like Decentraland, as well as physical assets like tokenized house deeds & real art.

The ERC-721 Functions and Events

The ERC-721 standard has the following functions that a smart contract should implement:

🔹 ownerOf(): takes in a _tokenId and returns the address of the owner of the NFT with that particular _tokenId.

function ownerOf(uint256 _tokenId) external view returns (address);

🔹 transferFrom(): transfers the ownership of an NFT from one address ( _from) to another ( _to).

function transferFrom(address _from, address _to, uint256 _tokenId) external payable;

🔹 safeTransferFrom(): transfer the ownership of an NFT from one address to another. It also checks if an address receiving the NFT is an ERC-721 receiver (i.e. whether it is capable of receiving the token or not) making sure that the tokens aren't lost permanently.

function safeTransferFrom(address _from, address _to, uint256 _tokenId) external payable;

🔹 approve(): approves another entity the permission to transfer an NFT on behalf of the owner. This allows NFT platforms like OpenSea to transfer ownership of NFTs you listed for sale when someone buys it.

function approve(address _approved, uint256 _tokenId) external payable;

🔹 setApprovalForAll(): enables or disables approval for a third party to manage all NFTs of a caller (i.e. msg.sender).

function setApprovalForAll(address _operator, bool _approved) external;

🔹 getApproved(): takes in a _tokenID and gets the approved address for a single NFT with that particular ID.

function getApproved(uint256 _tokenId) external view returns (address);

🔹 isApprovedForAll(): queries if an address is an authorized operator for another address and returns true or false given the approval status of the operator.

function isApprovedForAll(address _owner, address _operator) external view returns (bool);

ERC-20 compatible functions:

🔹 name() and symbol(): used to define the name & symbol of a token. These optional functions help in providing compatibility with the ERC-20 standard and make it easier for existing wallets to display information about the token.

function name() external view returns (string _name);
function symbol() external view returns (string _symbol);

🔹 totalSupply(): determines the total supply of tokens. In the case of ERC-721, the total supply doesn't necessarily have to be a constant.

function totalSupply() external view returns (uint256);

🔹 balanceOf(): returns the count of all the NFTs a given address owns.

function balanceOf(address _owner) external view returns (uint256);

Apart from these functions, the smart contract should also emit the following events:

🔹 Transfer: this event is emitted when the ownership of an NFT is transferred, or a new NFT is created.

event Transfer(address indexed _from, address indexed _to, uint256 indexed _tokenId);

🔹 Approval: this event is emitted when the approved address for an NFT is changed (whenever approve() function is executed).

event Approval(address indexed _owner, address indexed _approved, uint256 indexed _tokenId);

🔹 ApprovalForAll: this event is emitted when an operator is enabled or disabled for an owner. This operator can manage all NFTs of an owner.

event ApprovalForAll(address indexed _owner, address indexed _operator, bool _approved);

So, while the ERC-721 token standard allows us to create unique "non-fungible" tokens, it does have its shortcomings.

One key issue is that since all the tokens are unique, each token has to be sent in its own individual transaction. You can't just transfer 10 NFTs in a single transaction like you would normally do with ERC-20 tokens. As a result, it makes the entire process costly.

And what if I don't want all my tokens to be unique? 🤔

Think of an FPS game. Let's say the game has different types of unique skins for different weapons: Swords, Guns, throwables, etc, and an in-game currency called NinjaCoins. Let's say a user owns 1 gun, 10 swords, and 10,000 NinjaCoins.

Now, if we work with the ERC-721 standard, we have to write a different smart contract for each unique item or NFT, plus we have to write another smart contract for our NinjaCoins (that will be an ERC-20 token since it's fungible).

What if there was a single token standard that could facilitate the creation of both fungible and non-fungible tokens in a single deployed smart contract?

Enter ERC-1155! 😎

What is ERC-1155?

The ERC-1155 token standard was introduced by Witek Radomski & the Enjin team in 2018.

The ERC-1155 token standard combines the abilities of both ERC-20 and ERC-721 and tackles their shortcomings by providing a standard interface for smart contracts to manage multiple token types.

Some key features of the ERC-1155 token standard are:

🛠 Ability to create fungible, non-fungible, and semi-fungible tokens with a single smart contract.
🔀 Ability to do batch transfers: sending multiple tokens in a single-transactions.
⛽️ Gas efficient.
📦 Requires less storage space.

One key difference between the ERC-20, ERC-721, and ERC-1155 is:

🔹 The ERC-20 maps different addresses to the number of tokens they hold,

🔹 The ERC-721 maps unique token IDs to owners, and

🔹 The ERC-1155 has a nested mapping of IDs to owners to amount of tokens they own.

Image Credit: OpenSea blog

The ERC-1155 Functions and Events

The ERC-1155 token standard has the following functions that a smart contract should implement:

🔹 safeTransferFrom(): transfers _value amount of an _id from one address ( _from) to another ( _to).

function safeTransferFrom(address _from, address _to, uint256 _id, uint256 _value, bytes calldata _data) external;

🔹 safeBatchTransferFrom(): allows the batch transfer of tokens. This function works pretty similarly to the transferFrom() function in the ERC-20 standard. The only difference being we pass the _values and _ids as an array.

// ERC-20
function transferFrom(address from, address to, uint256 value) external returns (bool);

// ERC-1155
function safeBatchTransferFrom(
    address _from,
    address _to,
    uint256[] calldata _ids,
    uint256[] calldata _values,
    bytes calldata _data
) external;

For example, let's say we want to transfer 10 swords, 5 guns, and 100 NinjaCoins to an address. Let's say the IDs for swords, guns, and NinjaCoins are 2, 3, and 4 respectively.

So, _ids = [2, 3, 4] and _values = [10, 5, 100]

So, the resulting transfer with the safeBatchTransferFrom() function would be:

Transfer 10 tokens with id 2 from _from to _to.
Transfer 5 tokens with id 3 from _from to _to.
Transfer 100 tokens with id 4 from _from to _to.

🔹 balanceOf(): takes in an _owner and _id and gets the balance of an account's tokens of that respective token id.

function balanceOf(address _owner, uint256 _id) external view returns (uint256);

🔹 balanceOfBatch(): takes in an array of _owners addresses and _ids, and gets the balance of 'each' owner/id pair.

function balanceOfBatch(address[] calldata _owners, uint256[] calldata _ids) external view returns (uint256[] memory);

For example, given _ids = [2, 3, 4] and _owners = [0xd1dc..., 0x7c2d..., 0x1bdc...], the return value will be:

[
    balanceOf(0xd1dc...),
    balanceOf(0x7c2d...),
    balanceOf(0x1bdc...)
]

🔹 setApprovalForAll(): enables or disables approval for a third party ("operator") to manage all of the caller's tokens.

function setApprovalForAll(address _operator, bool _approved) external;

It returns true if the operator is approved, else false.

💡 The approvals in ERC-1155 are slightly different than ERC-20. Instead of approving specific amounts, you set an operator to approved or not approved via setApprovalForAll().

🔹 isApprovedForAll(): queries the current approval status of an operator for a given owner and returns true or false given the approval status of the operator. Similar to the isApprovedForAll() function in the ERC-721 standard.

function isApprovedForAll(address _owner, address _operator) external view returns (bool);

Apart from these functions, the smart contract should also emit the following events:

🔹 TransferSingle & TransferBatch: either of these events must be emitted when tokens are transferred (i.e. when safeTransferFrom() or safeBatchTransferFrom() functions are executed).

event TransferSingle(address indexed _operator, address indexed _from, address indexed _to, uint256 _id, uint256 _value);
event TransferBatch(address indexed _operator, address indexed _from, address indexed _to, uint256[] _ids, uint256[] _values);

🔹 ApprovalForAll: this event is emitted when approval for a second party or operator address to manage all tokens for an owner address is enabled or disabled (i.e. when setApprovalForAll() function is executed).

event ApprovalForAll(address indexed _owner, address indexed _operator, bool _approved);

🔹 URI: must be emitted when the URI for a token ID is updated.

event URI(string _value, uint256 indexed _id);

Conclusion

That's it for now, fren!

We've covered a lot about the three most common ERC token standards in this blog post.

We learned how the ERC-20 standard provides a basic structure for the creation of fungible tokens in a uniform manner, and how ERC-721 tackled the shortcomings & inefficiencies of the ERC-20 standard by providing a standard interface for creating & managing non-fungible tokens.

And then how the ERC-1155 standard sort of combined the abilities of both ERC-20 and ERC-721 by tackling their shortcomings such as storage redundancy and gas inefficiency, providing a "best of both worlds" experience.

But it does not mean that the ERC-1155 standard does not need improvement. The ever-evolving nature of the Ethereum ecosystem demands improvements in token standards as new advancements are made.

Prefer a TL;DR Thread?

I've got you covered! 🙌🏻

Here's a TL;DR version of this blog post. While you're at it, please consider following me @cryptoshuriken for more such content.

Image: A thread on ERC Token Standards - CryptoShuriken

Recommended Resources

EIP-20 Token Standard - Ethereum Improvement Proposals
ERC-20 Tokens, Explained - CoinTelegraph
EIP-721 Token Standard - Ethereum Improvement Proposals
EIP-1155 Token Standard - Ethereum Improvement Proposals
The Non-Fungible Token Bible - OpenSea Blog
Ethereum Developer Docs
OpenZeppelin Docs

If you enjoyed reading this article, please consider subscribing here so that you get a notification in your mail whenever I post new stuff. Subscribing is free, and it gives me a ton of motivation to keep going.

#WAGMI ✌🏻

Subscribe now! 📩

Getting into Web3 with #100DaysOfWeb3

CryptoShuriken — Sun, 11 Sep 2022 13:49:49 +0000

Hey, fren. gm! ☀️

Are you someone who is sitting on the edge of the Web3 rabbit hole, going through roadmap videos one after another, but just can not get started?

I remember myself being in the same spot, wasting weeks picking resources & doing nothing.

The never-ending loop of Analysis Paralysis | Credit: Uttam Singh

Well, good news! You don't have to pick a perfect roadmap. You just have to take the leap of faith & start.

How to get into Web3?

Before getting into Web3, you have to figure out two things:

1️⃣ Your "why". Why do you want to get into Web3?
Figure out what is your intrinsic motivation behind it. Is it to make money, is it the overall Web3 vibe you're attracted to, is it about flexibility, is it about building the decentralized future, or is it all of it?

For me, it's more about the vibe and following my intellectual curiosity.

I remember learning about Dogecoin when Elon started tweeting about it last year, passively investing small amounts I made from my SMMA work.

This year I thought if I'm gonna invest any more of my money, I might as well learn the technology behind cryptocurrencies & blockchain.

While researching good projects, I have always loved this infectious energy of the Web3 nerds. It got me excited.

2️⃣ Your Edge. What are you good at?
Luckily, Web3 isn't all about programming. It may seem at first, but it's much more than that.

So if you're not a programmer, don't sweat. There are plenty of things you can do.

One thing I've learned in the past year or so is to bet on your strengths. Do what you do best, and do it better than anyone else.

You can be a content creator, technical writer, researcher, community manager, designer, or marketer and still make it into Web3.

Similarly, you don't have to be a 16-year-old prodigy. The best thing about the Web3 space is how open and encouraging it is for people coming from different domains.

Don't be afraid to choose the road less traveled. Web3 needs diverse talent. Pick what you're innately good at and execute.

I realized I don't have to be a smart contract developer to be a part of the Web3 space. I'm really good at following my intellectual curiosity, learning new things, and simplifying them for others.

I don't have to be a coding genius who develops the next ground-breaking blockchain protocol. Sure, I'd like to be, but not immediately. For now, I'm happy to learn new things and teach others through my blog.

How to start?

From today (September 11), there are exactly 112 days remaining in 2022. And I want you to make every single one of them count.

For the next 100 days, take the #100DaysOfWeb3 challenge.

Ready to start? Let's go!

For the next 100 days, here's what I want you to do:

1- Pick a resource, just one! It could be freeCodeCamp's Solidity course, LearnWeb3 DAO, or Alchemy's RoadToWeb3.

If you try to catch two rabbits, you'll not catch either one. So, don't pick too many resources to start with. Just pick one and start.

✨ Here are 5 cool resources you can choose from. ✨

2- Go through it inside out, from start to finish.

3- Make a habit of devouring content. Go through external links provided in the course, be it blog posts, youtube tutorials, or keynote presentations. Just pick a topic and consume a lot of content about it.

4- Teach what you've learned - The Feynman Technique. Start a blog on Medium or Hashnode, or start a newsletter. Publish articles on new topics you learn. The best way to learn anything is to teach it to others. If you can't explain it to others, you don't understand it yourself.

5- Learn in public. You don't need 100 followers to learn in public. You can start with 0 and build your audience as you go.

6- It's tough to learn, so give it back to the community. Help & motivate others who are on the same journey as you.

Ready to start? 🛣

It's a long journey ahead. Want to make it easier?

Don't go all alone - find a partner. When you're starting, sometimes it gets lonely especially when you think you're not making enough progress.

Join a community, find people who are on the same journey as you, make an accountability buddy, and be accountable for each other's progress.

I'm 20 days into the challenge, but I want to start over. Starting tomorrow, I'm officially restarting my #100DaysOfWeb3 challenge from scratch.

Tweet at me @cryptoshuriken (yeah, now!) and I'll keep you accountable for the next 100 days.

Recommended Resources:

How to get a job in Web3 - Superteam Podcast
Why You Shouldn’t Become A Web3 Developer & What To Do Instead - Michael Macaulay

Hey, fren, that's it for now! Thank you for reading till the end.

Let me know why you want to work in Web3 in the comments below.

Also, please consider subscribing here so that you get a notification in your mail whenever I post new stuff. Subscribing is free, and it gives me a ton of motivation to keep going.

#WAGMI ✌🏻

Originally published on my blog.

A Gentle Introduction to Blockchain Oracles & Chainlink

CryptoShuriken — Thu, 08 Sep 2022 16:42:07 +0000

Hey, fren! gm.

Previously, in week 0, I had a gentle introduction to Solidity, the preferred programming language of the Ethereum ecosystem. In the second week, I continued with the same trajectory and learned some new concepts, such as:

🔹Arrays & Structs
🔹Loops and Libraries
🔹Receive & Fallback
🔹Const and Immutable

I also created a simple smart contract called Fund Me and while doing so, I came to know about an interesting problem called the Oracle problem.

So, what is the Oracle problem?

As we already know, a blockchain is just a public network that stores transactions in groups of blocks. In simpler times, we had blockchains like Bitcoin with a distributed public ledger that allowed people to send value from one wallet to another in a completely decentralized way.

Today, there are some advanced blockchains like Ethereum that allows us to create complex “Dapps” with the use of smart contracts that are simply digital contracts that get executed when certain conditions are met.

So, let’s say we want to write a smart contract to pay John whenever he places a bet on Manchester United and Manchester United ends up winning the match.

Should be pretty simple, right? All we gotta do is get the final match score and let the smart contract do its thing.

But there is a problem.

How would our smart contract know that Manchester United won the match?

As it turns out, smart contracts are actually not that smart. They are simply a piece of code that lives inside the blockchain, and blockchains are deterministic systems by design with no access to real-world information on their own.

Since blockchains do not have access to any real-world data or events, they don’t know what’s the price of ETH is, who won the football world cup, or what’s the weather like today.

As a result, our smart contracts cannot interact with “off-chain” data, which is something outside their blockchain environment.

So, we cannot ask our smart contract to perform calls to external APIs to check info like match scores, they are just a piece of code that lives on the blockchain and execute what they're told to do by the code.

That's the Oracle problem!

With the help of Oracles, we can get access to that off-chain information, and write our smart contracts in such a way that they can rely on outside information fed by an Oracle, and make decisions based on that information.

On a high level, Oracles are external services that feed real-world, off-chain information into the blockchain so that our smart contract can get access to that information and execute its logical conditions based on that data.

So the main job of an Oracle is to provide a secure feed of external data to the blockchain and provide a validation mechanism.

Think of them as a trusted third party that provides a reliable feed of information to the smart contracts.

Back to the betting example.

Let's say we want to access the score of today's Manchester United game. We know there are different sources and public APIs to gather that information.

So, we can ask an Oracle to do the following for us:

gather info from different trusted sources, like API-Football,
compare the result of each source,
through its validation mechanism, figure out the correct score,
supply it to the blockchain.

🤔 So in a nutshell, an Oracle acts as a middleman between the real world and blockchain and makes sure that the smart contracts have the correct data they need to make accurate decisions.

But there is a problem with this model. We can't trust a single centralized Oracle with the information to feed our smart contract.

What if the information provided by a single Oracle is outdated, or worse, manipulated?

Image Credit: Chainlink

The effectiveness of our smart contract depends on the quality of off-chain data it's being fed by the Oracles. So, we need to make sure that these Oracles should be resistant to manipulation and provide accurate & updated information.

Decentralized Oracle Network

To ensure data accuracy without relying on a single source of truth, a Decentralized Oracle Network combines multiple independent oracle node operators and multiple reliable data sources to establish end-to-end decentralization.

Chainlink is a modular decentralized oracle network that can be utilized to deliver accurate data and perform external computation.

In the Chainlink network, each independent node retrieves data from an off-chain source and brings it on-chain which is then aggregated & deterministically validated by the network.

Image Credit: Chainlink

3 key solutions Chainlink provides out of the box:

1 - Chainlink Data Feeds: provide a quick & easy way to connect smart contracts with real-world data such as the latest asset prices, weather information, etc.

2 - Chainlink Verifiable Random Functions: Since blockchains are deterministic systems, they can't have randomness.

So, Chainlink VRFs provide a way to get provably random numbers, enabling smart contracts to guarantee fairness & randomness without compromising security or usability in applications that demand randomness like lotteries, randomized NFTs, gaming, etc.

3 - Chainlink Keepers: provides decentralized event-driven execution of smart contract functions after specific times or when certain events are triggered.

Chainlink Keepers will listen to different events, and once a trigger returns true, Chainlink nodes will perform whatever action we want them to perform.

📌 For example, let’s say I want to write a smart contract to withdraw funds from a fundraiser smart contract to a wallet every time the balance of my wallet goes below 1 ETH.

To read more about Chainlink & Decentralized Oracle Networks, feel free to go through Chainlink Docs.

So, that was a gentle introduction to Blockchain Oracles. There are still plenty of things to wrap your head around about Oracles though.

That's it for now, fren!

Thanks for reading till the end. If you found this post helpful or if I made a mistake somewhere, please let me know by commenting below. I'm a newbie so all the corrections are greatly appreciated.

Also, please consider subscribing here so that you get a notification in your mail whenever I post new stuff. Subscribing is free, and it gives me a ton of motivation to keep going.

#WAGMI ✌🏻

Originally published on my blog