Future of ERC20 Tokens
While it is true that ERC20 tokens have been important for the growth of the crypto ecosystem, the fact remains that they may have overstayed their welcome. People are already experimenting with newer standards like ERC223, ERC 777 etc. but, as of right now, ERC20 isn’t going anywhere.
Dexaran points out the following reasons as to why ERC20 is still the preferred standard of choice: Because of the criminal irresponsibility of token developers for their deeds. Because the Ethereum Foundation is still promoting the ERC20 token standard even when it is known to contain bugs. The same situation as it was with TheDAO previously. They need to say “Stop this now” but they will not. Because the main reason for token development is fund grabbing, rather than product creation.Because using a different standard will lead to higher network effects. This is not what we really need given that the Ethereum network already has scalability issues.
Change is always slow and it looks like we will definitely need to wait a little bit more before we can move onto other standards. However, let’s not make the mistake of “criminalizing” the ERC20 standard. It certainly deserves all the respect for the profound impact it has had on the crypto-space. For ERC20 tokens, Anton Bukov of BitClave has recently proposed lazy migrations: The Easy Way to Upgrade Smart Contracts. The idea allows you to define a linear chain of ERC20 contract upgrades as follows: Write your ERC20 tokens so that they can be frozen. After a token contract has been frozen, it will allow no additional transactions to take place against it. After freezing, its state will never change. When you deploy the latest version of your token, you should point it at the previous (now frozen) version of the token contract. The new contract can tell if a wallet has migrated its balances using its migratedBalances map. Whenever a transfer is initiated, the token contract checks whether the sender’s balances have already been migrated from the prior contract and, if not, it applies the migration lazily at that time. Once a migration has been applied, the migratedBalances for the address it was applied to is set to true so that no such migration will be applied a second time against the current contract.
Although Bukov elaborated on this workflow only for the transfer function, a similar mechanism can also be applied to allowances, with the appropriate checks being performed in the approval and transferFrom methods, and it does yield a scheme which allows migrations without terrible gas overhead in the average case. I have three critiques of Bukov’s scheme: The freezing of old contracts limits composability. Bukov inherits from the OpenZeppelin Pausable contract in his ERC20 implementation but does not specify the when not paused modifier on his ERC20 methods. Even so, his exposition is very clear that balances have to be frozen on the old contract. This means that, if someone using the scheme deployed an initial version C0 of a contract implementing the suggested interface, then upgraded it to C1 (thus freezing C0), and finally upgraded it to C2 (thus freezing C1), then it would be impossible for someone holding C0-tokens to migrate their tokens to C2 because the migration would require them to update their balance on C1 as an intermediate step. Likely the right solution is for transfers and approvals to be frozen but for the migration, methods to not be frozen (in fact, they can take the when Paused modifier from the Pausable contract).
The worst-case gas overhead for any particular contract “view” operation is linear in the number of upgrades that have been performed. For example, if you performed 10 upgrades and someone wanted to query the balance of an account which had not migrated since the initial contract deployment, their balance call would result in 10 external contract calls, meaning a gas overhead in excess of 10 times the gas cost of the cheapest balance call on each of the deployments. This could be alleviated by triggering migrations even on such a call to the current contract. At any rate, such chaining of upgrades would require the implementer to address my earlier point of critique.
The act of freezing the old token deployment is a violent one. Unless the token authority can clearly communicate the upgrade to the community of token users well in advance of the actual freeze, we can well assume that such an upgrade would be disruptive to a non-trivial proportion of the token’s user base. The first two points are technical and yield to technical solutions. The third piece must be treated differently. It concerns the implicit contract that exists between a token issuing authority and the users of that token. The utility of the token in question in its capacity as a currency would be damaged by such a disruption in its functionality as such. This could have a significant effect on the economic dynamics of markets in which the token is commonly used.
Interestingly, this is a scenario that we have a very recent analog for in the world of fiat currencies — the 2016 demonetization of high denomination Indian banknotes. It is hard to tell, given how recently the demonetization took place, what its effects on Indian GDP have been. Especially since there is a lot of propaganda surrounding the matter in every direction. The statistics on the growth of quarterly GDP compared to the same quarter a year prior, as reported by the OECD, do not outright falsify the hypothesis that demonetization did have a significant impact on the Indian economy. If the GDP growth rate was affected by demonetization, whether or not it was justified can only be judged within the context of Indian government policies and is not really of concern to us. What really matters in this discussion is that the Indian government did violate the implicit contract that it had with its citizens by invalidating certain denominations of currency that it had put into circulation and that the violation of this contract may have had a significant impact on the Indian economy.
For an organization issuing ERC20 tokens, to the extent that they buy this analogy between freezing an older version of an ERC20 contract and forcefully taking currency out of circulation, the downside inherent to the possibility of the previous statement (applied to an economy in which the token is being used as a currency) should be ample reason to shy away from an upgrade process that involves freezing of contracts. Such organizations may instead favor an upgrade process that more closely reflects more conventional methods of currency circulation.