Fungible token standard (ERC-20 for Filecoin)

[anorth]

I am about to push a PR proposing a fungible token standard for Filecoin, and opening this topic as a venue for discussion of the content of that FIP.

Some topics for discussion:

• How closely should we aim to stick to ERC-20 for Filecoin-native tokens? Is there value in adopting this simple standard? Would we be better off jumping directly to something more comprehensive like ERC-777?
• What type (and binary representation) shall we use for token amounts? Using uint256 is natural in EVM, such that it was probably never a discussion. But the FVM's uint64 word size may be too small. I have specified uint64 initially, but don't think we should keep it that way.
• Should we deviate from ERC-20 to make the approve method safe from message ordering attacks, perhaps by implementing a compare-and-swap mechanic as described in this document?

See #279 for meta-discussion about how we should define contract standards generally.

cc @raulk @Stebalien @laudiacay @nicola @Kubuxu

[anorth]

I have closed my draft FIP that ported ERC-20 to Filecoin. After sitting with the idea for a while and learning more about similar standards both in Ethereum and other ecosystems, I no longer think that following ERC-20 closely is a good idea. We have an opportunity to take the lessons from years of experience subsequent to the adoption of the early Ethereum standards and apply them to a relatively clean slate.

I think we have a lot to learn from "standards" that came much later, even if they haven't seen much adoption. In many cases, that lack is due to the huge network effects of open-source and open-protocol ecosystems. For fungible tokens in particular, we might draw also from the work of ERC725 universal profiles, which could establish much safer and more functional interaction patterns.