Ethereum: a web of... trust?

Within Ethereum and the broader, if ill-named, Web3 space, one does not need to look far to find examples of people and organizations being exploited. Indeed, it is a rare month that goes by without someone losing a considerable amount of money.

Despite large investments into protocols' development, security improvements, smart contract audits and research, it seems that smart contracts, protocols and applications are broken on an almost regular basis, often with catastrophic results.

To a newcomer, this state of affairs may seem quite scary, and rightfully so. When even technically-minded people have difficulties participating securely in the Web3 space, is it really reasonable to assume that the next billion will manage to do it?

While there are many reasons for the current state of affairs, ranging from outright maliciousness and technical incompetence to economic incentives, there is one that deserves to be more prominent: hiding trust relationships.

Trustless. But not quite.

Human society has been built on trust. Trust allowed individuals to cooperate efficiently, form groups and build relationships, facilitating rapid progress.

People trust their car mechanic with fixing their car's brakes; the car mechanic trusts the customer to pay after the service is provided. There are many examples where modern society would simply come to a halt if there were no trust between parties. A major reason for trust being so widespread is the existence of penalties for trust violations. Those can be formal, such as sentencing a car mechanic to a prison term if the brake service was done badly and caused driver's death, or they can be informal, such as terminating a friendship because someone publically revealed a secret entrusted to them. It is interesting to note that both examples involve removing a person from an existing social group. It could be argued that penalties that do not involve removing a person from a social group, such as financial penalties, seem less effective.

So it would seem that formal and informal trust enforcement has been working pretty well for thousands of years. Why would then "trustless" anything be better? And what does even "trustless" mean?

As is almost a tradition in the Web3 space, "trustless" is more marketing than substance. The term is often used to advertise a particular protocol as being trustless, meaning there is no hidden actor or entity that needs to be trusted in order for the protocol to work as intended. More broadly, the term can also be used to indicate that the user has full control over their data and digital assets and, if something bad happens, only the user is at fault.

Unfortunately, this is quite far from the truth. Starting with Ethereum itself and the RPC provider ecosystem, one already encounters problems with centralization of trust, where an enormous amount of trust is put into just the few biggest RPC providers. The issue is well-known and is being addressed with efforts such as the DRPC network and the Helios client, but one still needs to wait some time before the problem is solved. Moving further, the problem only gets worse with various L2 solutions and bridges, where most projects rely on some kind of trusted entity (e.g. a single sequencer) in order to work. All too often, the projects' response to trust concerns is "We will decentralize the system, it will come, we are working on it.".

Finally, at the application layer, trust concerns are the biggest because they encompass the entire stack and claiming that a system or an application is trustless is misleading marketing at best. For a basic Ethereum application, the user needs to trust at least

• that all involved smart contracts do what they are supposed to do
• that contract owners are not malicious
• the user's wallet application
• the web application and/or the mobile application
• the RPC provider(s)
• the DNS system

That is a lot of trust, and the list is not even exhaustive.

So by saying "X is trustless", projects are not saying much and are not being helpful, at best. At worst, the claim might simply be untrue and would drive people to put a lot of trust into the system where there should be none.

Instead, projects should really be saying "Trusting X requires that you trust A, B, C and D". Listing the trust requirements explicitly, even in a non-exhaustive manner, would provide more clarity and would invite people to start thinking about their trust assumptions and possible risks. Similarly to how smart contract code and application code need to be open and transparent for everyone to see and verify, trust relations need to be clear and communicated in an understandable and precise way.

The web of trust.

Still, even if all Ethereum projects clearly communicated their trust requirements, how is the casual user going to decide whether to trust a random application?

Imagine the following scenario. Alice moves to a new city and needs an Internet service provider (ISP). There are several ISPs, some of which are good, some of which are bad, but she doesn't know which one is which. How does she pick a good one? Luckily, Alice has two friends living in the same city and they both vouch for the same ISP which they are also using. Since Alice trusts her friends, she chooses the same ISP.

This is similar to the web of trust. Applying the same concept to the Web3 space, one could imagine an application and a set of contracts being vouched for by a number of people having certain trust relations between them. The relations need not be symmetrical.

More concretely, a trust relation could be described as a set of triples ${ (A, B, w) }$ where $A$ and $B$ denote persons and $w$ is the measure of how much $A$ trusts $B$, between $0$ (zero trust) and $1$ (full trust).

Note that $A$ trusting $B$ with a weight of $w$ $(A, B, w)$ does not imply $B$ trusting $A$ with a weight of $w$ $(B, A, w)$.

It is also possible to define transitivity, with various degrees of complexity:

• no transitivity: if $(A, B, w)$ and $(B, C, y)$, then it does not follow $(A, C, z)$ for $w, y, z \ge 0$
• simple transitivity: if $(A, B, w)$ and $(B, C, y)$, then it follows $(A, C, w \cdot y)$
• complex transitivity: if $(A, B, w)$ and $(B, C, y)$, then it follows $(A, C, z)$ where $z = f(B, w, C, y) \ge 0$ and $f$ is an arbitrarily complex function

Suppose now that there is a mechanism where any person $A$ can vouch for a decentralized service in two ways:

• $A$ says the service can be trusted
• $A$ says the service cannot be trusted

and, furthermore, that there is a mechanism for wallets to access that information and compute the overall trustworthiness of the service based on user's preferences. A simple rule could be "if any of my fully trusted friends trust the service, consider the service fully trusted", but of course more complex rules could be imagined. Similarly, a rule "if any of my highly trusted friends marked the service as untrusted, deny access to the service" would seem useful.

With the web-of-trust scheme, it is good to note how the trust-related claims made by projects' organizations become less relevant and, instead, statements about trust are both produced and consumed by people directly involved in trust relations, allowing organic forming of islands of "good" and "bad" services and applications. There is no need for intermediaries or brokers of trust in the system.¹

In short, such a scheme that leverages existing trust relations between people would allow for much better user experience and improved security compared to the current state of the Web3 ecosystem. While average users cannot be expected to be able to audit smart contract source code, or understand and review application code, they are more than capable of understanding and managing trust relations. As a species, we have been doing it for thousands of years.

Back to top