Why EOS based token contracts need immutability

EOS was born to improve things that were wrong in the early versions of blockchains like Bitcoin, Ethereum or even the likes like Bitshares or Steem which come from the same creator, Daniel Larimer. Scalability and security improvements are amongst main things that have been tackled in the EOSIO protocol and upgradable smart contracts are what attracted so many developers, however, the latest disappearing of the EOS based tokens put a question mark on this flexibility and the need for a more reliable approach to the smart contract management.

The difference between Ethereum and EOS smart contracts

Ethereum is known for its immutable smart contracts. Once someone deploys a smart contract its code cannot be changed but also the bugs cannot be fixed. A dev can stop the contract by implementing a kill switch into the code before deployment.

From one side this immutability is good from the other it’s a problem that many have struggled with. If a dev doesn’t get the code right for the first time, he has no second chance. To fix a bug, the developer must rewrite the code, fix the bug and redeploy it in another contract. If no information has been taken as to who the users of the contract are and if there’s no way to communicate with them, this kind of problem may end in losing the audience for example.

On the other side, when the users start interacting with a contract they know that it will always follow the initial behavior and there’s no way of changing it. Everything is predictable and no trust is needed.

With the introduction of the upgradability to the EOS smart contracts, we face the issue of trusting the owners and their intentions. Many developers were relieved to know that they can correct their mistakes, that upgrades can be introduced but it is also true that this poses the risk of manipulation on the end user especially when the contract handles the transfer of value.

EOS was launched with the interim constitution and the ECAF in place. They were meant as the warrant of good governance that would solve the problems with bugs or hacks for example. Open source requirement and the ECAF were meant to work as the security check over a dapp but with the substitution of the interim constitution with the EOS User Agreement, there’s nothing to protect the users from malicious behavior. The checks have been taken down leaving the handling of the vulnerability to no one. This hasn't been also resolved in any other way so far.

During the latest months, we were witnessing some tokens being undropped from users accounts. PATR of Patreos project, PEOS and EDNA are just the latest examples of tokens that appeared in user accounts just to be later removed.

How is it possible that a token can disappear from the account? Aren’t we using the blockchain to have full sovereignty over our funds? No, EOS contracts are different and it’s the contract owner who decides what to do with the tokens. Not even EOS system token contract is immutable, however, BPs messing up with it without users knowledge would expose the chain at risk of a great backlash.

What's the reality of EOS smart contracts

The owner can change the issuance or can take the tokens back for example what requires a lot of trust in his honesty. Patreos project faced difficulties with the regulations and their uncertainty what forced the team to retract and close the token contract. All PATR have gone from users wallets.

PEOS tokens were taken back from the users if no claim action was taken from their side.

EDNA is the latest project which decided to take the tokens back from those accounts who didn’t interact with the contract since the genesis drop. The users still have some time to reclaim their tokens but it is unclear how many will even notice that their tokens disappeared and that some action had to be taken to get them back.

Similar actions harm not only the users but also the reputation of the projects and their teams as well as disseminating distrust in other projects which will be built in the future. The owner deciding to change the supply of the token and issue more of them to his own account could be very likely an event that goes unnoticed. A malicious update could be deployed to steal users funds.

If the user cannot be assured that what he has in his wallet belongs to him or that it will work in an expected way then how can he trust the blockchain technology at all? Where is the accountability which is the base of this technology? Is smart contracts immutability with its trustless approach a better solution or do we need better governance to handle these issues? The immutability of blockchains makes it impossible to alter the existing smart contracts to the detriment of one of the parties but if the contracts themselves aren’t immutable then the detriment persists.

In defence of the smart contract immutability

Predictability and trustless operating are two main things in favor of an immutable smart contract. Assuming that the code is open source, the user can expect it will work in the same exact way as it’s been designed to. The impossibility of changing anything within that contract means that the owner can’t exercise a malicious action. The token supply will remain always the same and if that contract airdropped some tokens to other accounts, it won’t be able to take them back. This means that no or minimum trust is needed to interact with such a contract. By taking off this variable the project gains more trust.

In defence of upgradable smart contracts

EOS enables smart contract upgrades as a way to fix bugs. It solves the problem of deploying a different contract to upgrade the code and eliminates the need to kill the contract in case it demonstrates an unintended behavior.

Proposed solutions

EOS New York came up with the proposal “to provide a structured and scalable system that allows for dApp developers to deploy tokens under the eosio.token system contract and essentially abstract trust away from one key pair to at least 15 out of 21 Block Producers which are elected by the stake-weighted vote of token-holders. This means that a dApp token specifically would be as secure as the EOS token.” They also propose to create a bidding system in front of eosio.token, which would allow for dApps to bid on the premium token names.” If the proposal passes, any new dapp on the mainnet will need to pay for creating the token. The whole proposal will surely provide more security but considering that the top 21 are mostly Chinese and little known BPs the communication problem could become the biggest roadblock. The high price of a token name could be another one.
Another solution could be simply the use of complex multisig authority requirements preventing a single actor from deploying a malicious upgrade. Similar multisig structures are already adopted on contracts connected with Chintai or eosDAC and should become a standard for dapps who want to have the reputation of being decentralized and secure. But to be effective also the actors involved in the multisig must be trusted to not collude. Authorities given to some of the BPs, dapp owners and external members could be the best option in case of a token contract but still, the token balances could be modified by the DAC. A user would need to stay always up to date with the dapp governance and trust its governing body.
Chainrift BP and exchange said that there is one new upgrade coming with version 1.8 that would help with protecting against changing contracts without anyone noticing. "The idea here is that it would be easy for another contract to check if it’s still talking with the same contract, if not, somebody would need to re-aprove it. In this sense, even one party contracts could be way safer, because everybody would be at least able to tell that the contract changed."
Almost all tokens rely on the same eosio.token contract code what means that there’s little room for bugs. In general, the users shouldn’t trust a token contract that is not open sourced. Open source means that there’s a possibility to go and check the code or to have others who can do it for you. Considering that almost all tokens replicate the eosio.token code it seems logical to make it immutable. Auditing tools, white hackers, third party websites whitelisting dapps are other solutions that would come as a help to support immutable contracts.

Conclusion

A token contract that is managed by one owner is not a viable option for a dapp that is aiming at wide adoption. Any token that is being sold on an exchange should be open sourced, have at least a multisig with one top tier BP but immutability is a way forward. The users who receive or buy the token have the right to know that the conditions of the initial distribution won’t change at each whim of the owner. Increasing or decreasing the supply of the token leaves space for insider trading where those who have the information manipulate the market and get the most benefits at the costs of other shareholders. As time passes by we will see more smart contract auditing solutions available to each user because each user should be empowered to rely on himself as much as possible. Reliance on white hackers and peer review will be also something we’ll see more if more donations or rewards go in that direction. The sovereignty of user funds should be paramount and the blockchain was created as the pillar of accountability this is why Block Producers should pay more attention to not permit that anyone can change token balances in user accounts and especially BPs shouldn’t abuse their power to make the same.