Are Ethereum Tokens Decentralized?
tl;dr:
In an ideal world, maybe.
Contracts essentially act as middlemen gate-keepers, reducing the value of decentralization. Tokens as smart contracts add layers of complexity that are far more likely to fail and that requires contracts to have “administrative” backdoors.
One of the foundations (or, rather, promises) of cryptocurrencies that provided them with the initial traction, was the ability to forego the custodian relationship in a post-cash society and the ability to transact without a middleman. In a sense, a way to walk away from the status quo monetary system.
So, what are these freedoms built upon?
Firstly, it is the inability of any individual party from making transactions with money that doesn’t belong to them.
In Bitcoin (and, subsequently, in some of the Bitcoin-based token systems, like colored coins) this is accomplished by ensuring that every transactor should be able to “unlock” the previous transaction’s output satisfying previous transactor’s requirements. Most often, that means they have to demonstrate the possession of the corresponding private key by signing the new transaction.
Since the guarantees demonstrated by such transactions are universally understood and respected by the participants of the blockchain, we can be reasonably sure no one can move our money unless they’ve got our keys.
Ethereum, having a much more flexible design, introduced the concept of a smart contract, or a program that can be invoked by a transaction. These are the foundation blocks for DApps (decentralized applications). One of the most common uses for these contracts have been so called “token contracts”. They define the issuance, transfer and computation of balances for every individual token. It’s a nice design, as it allows to experiment with the “laws of monetary physics”.
However, with this design, the actual possession of the token goes away from the holder to the smart contract, making that smart contract the custodian. It will transact on your behalf but will never “give” the tokens to you. You can’t own such a token without the contract that runs it.
Technically speaking, when invoked, the contract can do whatever it pleases. There is no cryptographic “connection” between ownership and transactions. It is up to the contract to enforce ownership or permissions of any other kind.
Sure, the code of the contract is always available and therefore, auditable. However, given the flexibility of the platform and the complexity that stems from it, review omissions are bound to happen. It would have been easier if there was just one contract to inspect, but if the current situation is of any indication, we’ll be holding a lot of different tokens.
Secondly, it is the inability of any individual party to prevent you from making a transaction.
As I mentioned before, Ethereum’s design, while fairly succinct, is still quite flexible and it offloads the implementation of tokens to smart contracts.
This comes at a price. First and foremost, by re-implementing the ledger functionality (even out of rigorously-tested building blocks) we are bound to have more bugs.
If you look into the leading token standard (ERC20) it only defines the interface to be exposed by token contracts, but does a pretty lousy job describing the actual properties that would help testing and ensuring the contract will do what it is supposed to do.
This is understandable if you remember the idea of being able to experiment with how the token “flows” upon transfer in your tokens — such as imposing restrictions, limits, etc. But there’s definitely a need for other standards that would describe how typical tokens MUST behave, depending on their model. Especially for the simplest ones.
An example of such additional standard would be describing the behavior of the transfer function in relation to affecting the balanceOf function’s return value (how do transfers affect balance, in a mathematically strict way?). This property is omitted, perhaps because it is trivial on the surface, but it means that we can only assume what these functions are supposed to do. And this leads to, well, bugs.
Why is this important? While in theory, the contracts are immutable and independent from their owners, in reality they are nothing but. If you follow the best recommendations for developing smart contracts, you will inevitably find that it is highly likely that you’d want to have a circuit breaker of a sort (to pause the contract if “things went wrong”) and an upgrade path (as a redirection of some kind, or a service registry).
Undoubtedly, this is a good measure to ensure the well-being of the token. It’s a good and noble intention… but it gets me to the next point:
The owner of the contract (or whoever has the owner’s private keys!) would be able to stop or change the contract.
Unlike Bitcoins forks that are much more noticeable (they affect a massive amount of people) and would require, at the very least, upgrading to a new version of the client software, such Ethereum tokens are much easier to change, both technologically and politically.
What can be done to prevent undesirable interruptions? One may suggest that the institute of the token ownership should be moved away from the individual owner to a voting system. Perhaps. It’s definitely better than somebody unilaterally controlling the token, but it raises new, quorum-related questions: what if we do need to respond to malfunctioning contract ASAP, how long will it take to build a quorum? Which changes require which levels of quorum (50%+1? 2/3? Unanimous?)
So, while the building blocks of Ethereum are capable of assisting in creating decentralized contracts, there is no way to define a perfectly correct contract that accounts for all future possibilities. This means that somebody has to keep driving the contract, therefore reducing the decentralization to such as areas as provable auditing. However, this is not to say there is no future there. Rather, it is important to understand these limitations (as opposed to blindly riding the hype wave) so that they can be eventually addressed.
