Contract Standarization

Perhaps the most famous contract standard, the ERC-20 interface allows for users to develop their own tokens that other users/contracts are able to interact with. To understand what the ERC-20 is from a high-level and why it's almost necessary, let's first consider the following scenario:

Aside: Lack of Information

The concept of a token contract, while intuitive at first, begins to become quite complex when we consider what the implementation of such a contract consists of. As an example, consider a car. We know that a car is a vehicle that takes us from point A to point B; furthermore, we can say that cars move via wheels and we can dictate the direction of a car via a steering wheel. However, consider the following:

• How many seats does a car have?
• Do all cars come with a retractable sunroof?
• How is the car powered (i.e. via gasoline, electric, hydrogen, etc)?

The questions above do not break down the concept of a car, but rather, they complicate any product meant to complement a car. Let's now focus on tokens. Abstractly, we can state the following:

• All accounts have a balance of the token (even if its zero)
• We can transfer tokens from one account to another
• The token contract does not allow for double-spending and related forms of manipulation

Let's now write a token smart contract which achieves the following:

contract Token {
​
    mapping(address => uint) balances;
​
    function transfer(address to, uint amount) public {
        require(balances[msg.sender] >= amount);
        balances[msg.sender] -= amount;
        balances[to] += amount;
    }
}

Tying back to our car example, lets assume we have another Token contract with the following implementation:

contract Token {
​
    mapping(address => uint) balances;
​
    function transferTokens(address to, uint amount) public {
        require(balances[msg.sender] >= amount);
        balances[msg.sender] -= amount;
        balances[to] += amount;
    }
}

The code block above, logically, does the exact same thing as the original Token contract before it. However, notice that the function name in this case changed - we went from transfer to transferTokens. The above demonstrates for a user to interact with the either Token contract, they would first need to find out the name of the function associated with transferring tokens.

But why stop there? We can also name the transfer function the following:

function transferSomeTokens() public {}
function doTransfer() public {}
function sendTokens() public {}
// ...

As it might have become obvious, for any user that wants to interact with a particular Token contract, they would need to somehow find a way to get the correct function name or risk their transaction reverting. Furthermore, consider the case of a smart contract trying to call a Token contract. We would need to hardcode every single possible function name into our contract - something which is practically impossible.

This entire section leads us to the conclusion that for concepts like token contracts to work, there cannot be a lack of information regarding the behaviors (and their associated names). There needs to be consensus regarding a standard for token contracts which everyone can turn to. The ERC-20 contract, in essence, is this standard.