Ethereum Services are Centralized
EDIT: I would have fleshed this out more had I known it would be so widely circulated, but to address some common criticisms:
- “Smart contracts are immutable. Their owners can’t change them.”
This is technically true, but practically false: https://docs.openzeppelin.com/learn/upgrading-smart-contracts - “Mutable smart contracts are only used by pet projects. Every major production service is either immutable or uses a decentralized update mechanism.”
This doesn’t seem to be true either. Axie and Rarible are two prominent NFT projects, both of which support centralized upgrades. After browsing a few top dapps from dappradar.com, this pattern appears to be the rule, not the exception.
The promise of crypto networks is that, for the first time ever, users can know that an internet service will behave exactly as advertised. New transactions are committed only when a majority of independent nodes all agree on the effect (decentralization), and the code these nodes are running is available for anyone to inspect (trust).
This system, however, requires nodes to have some say in how the service operates. Bitcoin miners, for instance, are run by independent parties, each of whom is invested in keeping the service running, so will only agree to new protocol changes if they’re in the interest of the community.
But this fails to hold true for general purpose chains acting as a VM, including the front-runner Ethereum. Ethereum nodes can in theory filter modifications to the smart contracts they execute, but in practice, node operators have no reason to inspect or reject these upgrades, because they have relatively little stake in the success of individual contracts or their ecosystems. If an owner of a smart contract publishes a new change, nodes will mindlessly run it. Ethereum is blockchain AWS.
Decentralization doesn’t just mean “lots of computers run by lots of people”. It means decentralization of power. The Ethereum network itself could be considered decentralized, sure, but many services running on top have a clear single points of control—the owner, who is often given central privilege to update the contract, often to fix bugs and add features. Users can verify their crypto bank is storing their money safely today, but that’s cold comfort when the bank can set fire to the vault tomorrow.
This is a moot point for immutable services, which by definition cannot be changed, but most services are not, and indeed cannot be immutable. Like any piece of software, upgrades must be made, and bugs must be patched. Theoretically, protocols can reach a point of maturity when they’re frozen in time, but practically, this doesn’t happen.
The real risk isn’t a “rug-pull” where the owners bag everyone’s money and run. The real risk is that services will drift from their original promises, in order to “better serve the needs of the community.” The real risk is that blockchain services begin to operate just like centralized companies and we’re right back to where we started.
Advocates say that the organizations operating smart contracts can be trusted to a large extent because they operate in the open, are kept in check by the ecosystem, and even often have voting protocols in place to govern changes. These are all great ideas. They also don’t require the blockchain. Any organization deploying services to a traditional cloud could operate in such a way.
This problem doesn’t strike me as a mere technicality. It’s existential. If trust on the blockchain boils down to trust in a mere social system, what has been gained?