On The Fallacy Of Trustlessness

A mantra of decentralization is “trustlessness” – the idea that you are in complete control of your funds and assets, not relying on any third party whatsoever. “Be Your Own Bank,” “Bankless,” and other catch phrases are common in the industry. Lately, after the most recent crash, one hears about the benefits of “trustlessness” frequently as centralized crypto entities exerted their power and halted withdrawals. The idea is that, with decentralized finance (defi) and smart contracts, a permissionless infrastructure exists that cannot be censored or blocked. You don’t have to “trust” any humans; code is law. True laissez-faire.

With a little prodding and poking, this narrative of “trustlessness” falls apart quickly. It turns out that “trust” is even more crucial in decentralized systems. Decentralized systems require that users trust the software – and the people that wrote the software – with complete devotion.

Software, regardless of what purpose it serves, can be buggy and insecure. With a centralized system, when something goes wrong, there is a path to amelioration. Code is not law. But, in crypto, there is no one that can be called on when things go wrong. This is by design.

This design principal leads to hacks and scams. The “code is law” mantra opens up attack vectors at every layer of the crypto stack.

Let’s look at these vectors, starting from the lowest level (blockchain source code) to the highest (user interactions). We will see how the nature of the software makes the user vulnerable, and how the vulnerable user has no choice but to trust the software. So much for trustlessness.

Blockchain Vulnerabilities

Blockchains are software. It sounds obvious, but sometimes that fact seems to get forgotton. And if that blockchain code itself has a bug or a backdoor, users are exposed. There’s a reason that bitcoin core devs are hesitant to touch the code; anytime code gets touched, a regression is possible.

While bugs in blockchain code are less common than other layers of the stack, they do happen. For example, check out this bug in the Optimism blockchain, found by a grey hat hacker, who was paid $2 million dollars as a bug bounty. Had it gone undiscovered…

People complain about ETH 2 taking so long? One reason is that blockchain code has to be near perfect and perfection is a tough goal when building complex, novel systems like proof-of-stake blockchains.

The TLDR? You’d better have a near religious faith in those rock star blockchain devs…

Smart Contracts Vulnerabilities, Hacks and Backdoors

If you interact with Ethereum or an EVM blockchain, you are most likely interacting with smart contracts. Every ERC20 token, NFT or dex is a smart contract. And therefore you have to trust the smart contract code. So how do you trust a smart contract?

The general answers is either blind faith or audits. Any project worth its salt has its contracts audited. One might think that an audited contract is safe. Nope. Check out the Rekt leaderboard. While most of the hacks are on unaudited smart contracts, multi-million dollars hacks took place against smart contracts audited by the premiere names in the industry: Certik, Quantstamp, Peckshield, Slowmist, Deloitte. These firms charge tens of thousands of dollars to perform audits and the smart contracts still got hacked.

Even if you can read and trust the code, there are many times when the smart contract has backdoors that can be accessed by “admins”. As such, you have to trust whoever has those permissions. Whether it is via the Ownable modifier, which allows an address to changes varibles in the smart contract, or via proxy smart contracts, which enables an admin to redirect to an entirely new codebase, smart contracts with backdoors are rampant and lay waste to the “code is law” ideal. The code isn’t law if someone can change the code willy nilly.

Once again, trust is at the heart of things.

Node Operator/Miner Vulnerabilities and Hacks

In order to interact with a blockchain, one must interact with a node of that blockchain. 99.9% of people do so using a node provider. As such, you are implicitly trusting the node provider. That node provider has the opportunity to drop your transactions or, in the case of MEV, reorder your transactions to their own benefit. The node provider wields incredible power and asks for extreme trust.

Dapp/UX Vulnerabilities and Hacks

Most people don’t directly interact with smart contracts; they use some sort of user interface or application to do so. These dapps (decentralized applications) are major attack vectors in the space. The smart contract itself may be flawless but the dapp may be corrupt. There are lots of examples of this.

It takes eternal vigilance when interacting with dapps. From DNS spoofs to fishing to outright dishonesty, dapps are a major attack vector. But users are pretty much held hostage by the dapps and have to trust the dapps. Again, trust plays a major role for anyone interacting with a dapp.

Wallet Vulnerabilities and Hacks

The final layer of the stack is also a major area where trust is king: the wallet. Wallets are just software. Like blockchains, one can forget that the wallet is a piece of software as well, with vulnerabilities and attack vectors. And your wallet contains the most important thing in the entire stack: your private key. Private keys are literally the keys to the kingdom. If breached, it’s game over. Imagine a breach to something like Metamask – such a hack could be exploited for millions. Better trust the people who wrote your wallet, both their coding skills and their integrity.