Trust them, don't trust it

A note on trust and SPoFs

Blockchain networks are sometimes called trustless to express that no single individual/organization must be trusted, since other participating inds/orgs will verify each other’s work. That’s the idea of decentralization, or distributing trust.

Trusting means “having reasonable confidence that an actor will keep their promise to behave according to prescribed rules and not violate whatever moral covenant is implicitly in place.” I write moral covenant rather than contract or law because those don’t necessarily apply; we’re in a decentralized, transnational, often effectively lawless environment. The question then becomes: what prevents actors from betraying trust? It often boils down to financial or reputational incentives, where the latter typically correlates closely with the former.

A notion closely associated to trust is that of a single point of failure. We’ll see how they relate:

Some counter the trustlessness claim by arguing that there’s always something these inds/orgs have in common: the very protocol they’re working with, often the same implementation thereof. (Example: Bitcoin nodes predominantly run Bitcoin Core; counterexample: Ethereum’s beacon chain has meaningful client diversity.) You must then assume that the protocol fulfills its functional duties and achieves its security goals. But saying you “trust” the protocol represents a semantically different type of trust: the protocol cannot of its own volition betray you or act in its selfish interest, for it has no agency. Thus, here “trust” is only metaphorical, approximative, and at best indirect.

Consequently, a trustless system can have single points of failure.

You can argue that you’re implicitly trusting the protocol’s developers, which isn’t an unfair objection. But since the protocol is generally public, its implementation open-source, and at least some users self-compile binaries from source, it’s considerably harder for developers to unilaterally and directly harm you for profit (as opposed to a stablecoin operator, bridge operator, oracle service, or memecoin issuer you’ve invested in). I therefore posit that this reduced level of trust is generally acceptable, as it sits—with important caveats—in the same category as trusting your OS, runtime, hardware, and landlord: if you’re not a high-value target (a “whale,” celebrity, or cartel boss), your risk exposure here is much lower.

Even regardless of SPoFs, being trustless (in the above sense, where no single agent is trusted and those semi-collectively trusted have limited capacity for harm) doesn’t imply security, as blockchains daily demonstrate:

1. Even with virtuous actors’ systems fail: Even if designers, developers, and operators are wholly virtuous and benevolent (ignoring for a moment that they generally can’t be held accountable) their systems routinely fail to achieve their functional and security goals. This stems from the combination of technical complexity, limited QA and security maturity, and overconfidence in the underlying trust assumptions.

2. Adversaries exist and are rational: Not everyone in the world prioritizes the interests of a blockchain protocol and its users (and why would they?). The parties we capture under the umbrella term “attackers” are, by definition and essence, untrustworthy. They will exploit any avenue to profit from the protocol in ways unforeseen by and undesirable to its users.

Lastly, trustlessness isn’t binary. Blockchainers routinely debate which chains are the “most decentralized,” and rightfully so. Consider for example the Base L2, which still operates a single sequencer (run by Coinbase). This makes it highly centralized, notwithstanding the Ethereum decentralization of Base’s settlement layer. Base users must (even if they’re unaware of it) trust Coinbase, an actor with agency and incentives.

Even the most trustless, decentralized blockchain introduces trust when you use it: when checking a transaction or querying an address balance, you’re typically hitting one interface: Etherscan, an Infura RPC endpoint, a specific node. That interface is both a single point of failure (if it goes down or gets compromised, you can’t access the chain) and an agent you must trust (it can lie about balances, censor transactions, or feed you stale data). The protocol may be trustless, but your access point isn’t: there’s a trustless consensus layer but a trusted access layer.

(This post may seem obvious to security folks but it's often misunderstood in public/online discourse about blockchains, where “decentralized," "trustless," and "secure" are often conflated.)

Feature image/song: Future, We Don't Trust You.