56
Each of these contracts is subtly or not so subtly different from all the other ones, which means that if you really are paranoid you need to have some programming knowledge in order to be able to audit each of those contracts, and secondly, you need have the time to look at them all, and most people don't have both the knowledge and the time to really be thorough about the contracts that they're interacting with, and so a lot of this stuff is done on trust, and given the sums of money that can be involved in token transfers, this is not a good state of affairs. Now the specifics of the engineering problem are that the ERC20 fungible token standard has the token name and the token symbol hard coded into to the contract: it's deployed as part of the contract, and as a result if three people all deploy their own token contract, even if they are line for line identical, they won't be at that one line where the token identity is established.
Why don't we actually deploy a standard contract and then have a minting function that provides the specific token name and token ID?
That would mean that the contract as it sits on the blockchain would be identical from deployer to deployer and it would mean that you'd only need to check one of those contracts and you'd know that all the other ones are the same. Now this is a perennial problem in computing - the one of standards and implementation, and the problem that Ethereum has is that it's still young. It reminds me a bit of programming in the eighties.
Now, the idea of getting a teenager to write a database to keep track of chemicals in a lab, as was the case back then, seems ludicrous. There are plenty of free open source databases out there, you don't roll your own. But we're still in that early stage with Ethereum where it's all kind of starting to take shape, and actually if you go and look at the ERC1155 standard, you'll see that your problem is addressed there. Probably not in the way that you would like it if you're an on-chain maximalist but the ERC1155 standard doesn't specify the name of the token in the actual contract as deployed. It's a standard contract and then you provide URIs for metadata that actually described these things. The downside of that is that now the token name is no longer on the chain, it's on a file that's sitting on the IPFS, or on a web server somewhere, and that has its problems with it. Plus they removed the token symbol for some reason, and token symbols have problems - there's a lot of collisions in space, but people have come to expect that a token will have a three or four or five letter symbol associated with it.
So I'm not entirely sure why they made that decision because they're going against the established method of doing things, but back to those ERC20 tokens and ERC721 tokens have a similar problem. Indeed the contracts will all hash to different values because of those few differences, even if ultimately they're all the same, and then there is a bigger problem which is that developers all like to put their own little bits of functionality in there. Sometimes those bits of functionality are valuable - they might be for example having some kind of royalty attached with transferring a token, sometimes there are nefarious and underhand - you can deploy a a non fungible token contract that allows the owner of the contract steal token from people at a later date, and that of course is not a good thing.
I think it's a standard problem in computing that you have when you're at this stage. As time goes on things will get more standardized. We already have template contracts being provided by for example OpenZeppelin that people can work from. Eventually at these things will become more commoditized and it won't be a matter of each developer developing their own thing from scratch, there will be some standard contracts and hopefully, eventually, the industry will develop in such a direction that if you don't use those standard contracts then people won't want to interact with them and that will make people gravitate towards these non-custom solutions.
Interested in learning more about Bitcoin, Blockchain, and Cryptocurrencies?
Subscribe to my Publish0x blog
The links throughout this article are provided for informational purposes only. I am not an affiliate of these companies, I make no recommendation regarding the companies or their services, and I have not received any compensation for linking to their content.
Follow me on instagram
Follow me on twitter
Thank you for reading!
