On Decentralized Trust

On Decentralized Trust

Understanding Trust

Let me make a bold claim: trust underpins everything in our lives. Without trust, we cannot do much of anything—have relationships, jobs, services, buy goods, a functioning government, property rights, or exist in a non-anarchic society. Trust is a cornerstone of everything we do and who we are. Each decision we make has some trust assessment: Is this a suitable caregiver for my child? Is this banana safe to consume? Is this truly my bank's website?

After consulting a dictionary and psychology blog, I'll define trust as a set of beliefs and feelings that lead to one tolerating uncertainty and risk, or phrased positively, exhibiting confidence and security. If I trust you, I'll let you drive me somewhere. If I trust you, I'll put you on track to be my friend—and if you're lucky, we can become good friends or even best friends. Trust exists on a spectrum: I may trust an acquaintance not to poison me, but I don't inherently trust that their food will taste good. Trust can be transitive: If someone I trust trusts a business, given no prior information, I'm more inclined to trust that business too. Finally, not all trust relationships are similar; they are context dependent and categorical: I may trust my colleague to review my code, but I won't trust them to operate on my brain.

I could spend a lot of time going into many aspects of trust, their implications, and their differences across societal, socio-economic, familial, political, and other boundaries, but I'll leave further exploration into what trust is as an exercise for the reader. Briefly, however, let's discuss decentralization and centralization. An overly simplified definition of decentralization is a system that does not have a single point of failure. Centralized trust is quite common: trusting a government for their financial system or protection, trusting a large provider like Google or Apple to store your data safely and not violate your trust. In digital contexts, centralized trust often takes the shape of Public Key Infrastructure (PKI), which relies upon trusted central authorities and delegated trust relationships. Decentralized trust has its roots in the Web of Trust concept, which allows any party to be its own root of trust or the authority from which we establish additional trust. In the decentralized identity space, an event called Rebooting the Web of Trust pays homage to this concept and applies it to modern contexts. More examples will help make the idea of decentralized trust clear in the coming text.

Setting the Stage for Decentralized Trust

Digital Trust is the concept of trust applied to digital contexts. It can take both centralized and decentralized forms. Digital trust can replicate physical world interactions in the digital world, such as talking to a friend—you trust their phone number is theirs once you verify their voice or online banking—you can trust digital financial transfers work when you can withdraw money from a real-world ATM. There can also be pure digital trust relationships, like two computers trusting each other to establish a secure connection for the transmission of data. As you read this, you are engaging in digital trust: is your web browser tracking you? Is this website what it claims to be and not under a defacement attack? Am I a reliable enough author not to spew brain-washing garbage that you're perfectly susceptible to?

Decentralized Trust, as I intend to discuss it, is a form of digital trust that is an emergent phenomenon with the prevalence of decentralized technologies like Blockchains, Decentralized Identifiers (DIDs), Verifiable Credentials (VCs), and Decentralized Web Nodes (DWNs). A blockchain like Bitcoin is an excellent example of decentralized trust, as that is its primary innovation. Multiple parties can exchange value without any central intermediary. As Lawrence Lessig stated in his essay Code is Law:

The code regulates. It implements values, or not. It enables freedoms, or disables them. It protects privacy, or promotes monitoring. People choose how the code does these things. People write the code.

Bitcoin and other decentralized technologies have created a set of laws that enable decentralized trust and its relationships to be viable.

Precedent

There's a good amount of precedent in this space. I'll talk through two decentralized trust players.

Up first, Chainlink. Chainlink, among other products, provides accurate and tamper-resistant data feeds–oracles–to smart contracts. If I want to get an accurate sports score to use in my on-chain sports betting smart contract, I need an oracle like those provided by Chainlink. Chainlink has an elaborate system as outlined in its 2021 white paper for Chainlink v2 that ensures its oracles are available, scalable, fair, and secure. There are critiques of Chainlink's approach to decentralized trust, one of which produced one of my favorite ever dunk-images.

Trust me because I trust me!

Certainly, we don't want to set up a system of trust with the same assumptions as a perpetual motion machine. And also, by using Chainlink, you buy into their system of establishing trust, which involves using a shitcoin.

💩
There are many definitions of shitcoins, such as those designed to make a quick profit via a pump-and-dump scheme. Here I mean shitcoin because any business that requires you to pay it in its own currency is undoubtedly ridiculous. Imagine if you could only buy things on Amazon with Amazonbucks?

That said, decentralized oracles and trust are hard problems, and I like what Chainlink has done. Trust needs to start somewhere. And once you establish that trust, you can build upon it and establish other trust. Even if Chainlink doesn't have it quite right, I think their ideas are worth learning from and applying to contexts that don't require a blockchain.

The Trust Over IP Foundation

The second example that I'll point to is the Trust Over IP Foundation (ToIP). ToIP exists at the Linux Foundation, in the decentralized identity space, and aims to "[Develop] a complete architecture for Internet Digital Trust." As far as I can tell, ToIP's crowning achievement is the image below and the dense technical documentation that describes and prescribes how trust should be carried out in decentralized contexts.

The dual stack table showing four layers of the ToIP Technology Stack and the ToIP Governance Stack
Decentralized trust for toddlers

ToIP's work is in progress and has many valuable, interesting, and promising works on decentralized trust. Specifically, I believe ToIP's research on digital trust, trust modeling, and reasoning for "why decentralized trust" is monumentally important in the Decentralized Identity space. Not only that, ToIP's work aims to build a bridge between the existing world and the decentralized world. Bringing everyone along to the DID-future is a noble cause. I applaud their work and believe it needs to be more widely read and understood by those in the space. I'm confident that Web5 will likely use much of what ToIP has and will come up with.

That said, my critique of their work is that I see ToIP's perspective as "to have trust, we must define it," and I do not believe that decentralized trust can be prescriptive, even if it ends up looking like what ToIP has conjured up. Put another way: most people don't read books on how to have human interaction before forming a friendship or having conversations.

Trust in Decentralized Interactions

Now that we understand what trust and decentralized trust are a bit better and have some perspective on the ecosystem, I will share my own thoughts on decentralized trust.

Low Switching Cost

My first idea is that decentralized trust will sometimes look quite similar to centralized trust—and this is okay. The key difference between centralized and decentralized trust is the switching cost. In Bitcoin, you have a concept of a "hard fork" where a majority of the network moves to change the rules of the protocol. This is an effective mechanism to act against attacks on the Bitcoin network. If any malicious actor(s) attempts to undermine the protocol, or grow too powerful, then the majority can exclude them and their changes from the system with a hard fork. This concept is important to combating would-be attackers from the network because they now know that they shouldn't go and burn a lot of money in attacking the system because even if they're successful, they could have their work un-done with a hard fork.

Applying this to decentralized trust, we can imagine a lot of Trust Brokers that look a lot like today's Certificate Authorities. Trust Brokers can be responsible for aggregating things like trust scores—this merchant has a trust score of 89% for selling authentic baseball cards, or sentiment results—e.g., this merchant has a 95% favorable review rating from customers in Australia over the last six months, or even hosting trusted registries for data–e.g., this DID belongs to Acme Corp., this is the California Government's official website. The difference is anyone can be a Trust Broker and gain the trust of the masses because the network itself is open, permission-less, and decentralized. The switching cost comes in should a Trust Broker act in bad faith or stop being trustworthy (who watches the watchmen?). This is made possible because the data that influences the Trust Broker's computations are held by individual entities that can do a few interesting things in our decentralized world:

  1. Use open-source Trust Broker software to re-compute trust results
  2. Run "accuser" software to flag and broadcast unexpected deviations from Trust Brokers
  3. Collectively agree on new sets of rules for computing trust

Those who rely on the Broker's trust must be able to fork away from the Broker instantly. Low switching cost.

💡
Trust Brokers can differentiate themselves with more accurate algorithms, higher-availability, lower latency, more robust query-ability, and other factors. It could be a viable business!

One example of precedent for low switching costs near and dear to my heart is that of Tezos Bakers. Tezos is what I believe to be the most fundamentally sound Proof of Stake blockchain. Stakers, known as Bakers on Tezos, are those who are responsible for securing the network, gaining rights to produce and validate blocks, and gaining rewards for doing so. Anyone can be a Baker as long as they are willing to dedicate a minimal amount of compute and a small amount of stake (as of writing, you can run a Tezos baking node on a Raspberry Pi with 6000 XTZ, or $6000 USD). Tezos has just over 400 bakers at the moment, 157 of which are public. This means any Tezos holder can choose to delegate their XTZ to one of these bakers. Delegating enables you to receive rewards (profit-sharing) from the Baker, who you trust to pay you rewards accurately in proportion to your delegated stake, and on time, in addition to voting for protocol changes on your behalf. Bakers are incentivized to attract more delegates to increase their block-producing rights (to make more money) and get more voting rights—somewhat similar to the US electoral system. Baking info is completely public. So is payout information. People are free to switch their delegation between bakers or have the option to become a baker themselves at any point in time. The switching cost is incredibly low, and as a result, Tezos is a highly democratic, open, fair, and innovative blockchain ecosystem.

Trust Broker software in some form will be built into the SSI Service we're working on at TBD. Some base concepts are being formed at the DIF under the Trust Establishment work item.

Close The Loop

As we progress into a decentralized world, we are going to be facing a lot of data. Thousands of DIDs, millions of VCs, many millions of interactions between parties. Many interactions will go right, but some won't. When they don't, what happens? Let's go through an example.

Jimmy uses a Credential

Jimmy has had a DID for a while with some credentials relating to his job. Now, for the first time, Jimmy's favorite local venue, DecentralStage, is selling tickets as VCs. Jimmy gets a VC ticket to an upcoming concert and heads to the venue where he is rejected at the door! The building is at capacity. How could this be? Jimmy has an authentic ticket VC from the merchant. Jimmy's wallet told him the merchant had a high trust score and the credential was authentic. Unfortunately, DecentralStage sold more tickets than they had space for—time for a bad review.

Jimmy, bummed, needs to close the loop. He heads to the popular decentralized review service, Drust Pilot, submits his VC as proof he is authorized to write this review and enters all details of what occurred. The site's algorithm updates the venue's trust score, and Jimmy has just prevented another rocker from getting scammed by DecentralStage.

Loop Closing as a Service

Whether the close-of-loop is a review or a more automated system is TBD—there are a number of close-of-loop service ideas that could work. Perhaps they could be a part of the same service the Trust Broker above runs too.

The important part is that things won't always go according to plan, and we need skin in the game to create a functional decentralized ecosystem. With nothing at stake, we're creating systems that are rife with fraud and abuse. Being able to quickly detect and stamp out fraud is a necessity. On the flip side, we should aim to create systems that are purpose-fit for the alleged injustice. Operate a faulty bungee jumping company and kill someone? One strike, and you're out. Sell too many tickets by accident one time? Foul ball, we'll give you another chance.

Skin in the game can take a number of forms, too. Public shaming and trust scores are just one avenue for loop closing. We could consider systems that put monetary assets at stake, such as a decentralized escrow service with trusted arbiters that could be real entities or algorithms. Similar to making sure the loop-close is purpose-fit for the injustice, it should be purpose-fit for the interaction too. Before engaging in a trust interaction, we'll need to ask ourselves, what am I risking here, and what mitigations do I have in case something goes wrong? Let's lose trust judiciously.

I'm excited for the world where such trust services and metrics exist, and they are integrated, consumed, and automatically processed by our smart decentralized applications: bumping down bad actors and promoting good ones. Of course, we'll need to prevent them from being gamed, too...

Towards Automated, Decentralized Trust

I'm confident to make a bet that AI will rule the future. Even if we're not enslaved by highly intelligent computer overlords, their thoughts and actions will influence all aspects of our lives. With that understanding, what does AI applied to decentralized trust look like?

First, I believe that if we successfully build the decentralized web, our data will be unlocked. This means that nearly all data related to us online will be accessible to use in standards-based formats. This is extremely powerful for a single individual to have all their data, but en masse, there can be great benefits of sharing privacy-preserving data between individuals and groups, and put towards noble purposes much broader than trust, but also applied to trust. AI will power Trust Brokers and on-the-spot calculations of trust decisions throughout the decentralized web.

I believe that a robust decentralized trust system will make use of complex graph operations over the decentralized web. This looks like making each DID a node and each interaction, whether it be via a Decentralized Web Node message or Verifiable Credential, an edge.

Being able to make semantic queries over decentralized webs (there will likely be many disconnected webs) will unlock a powerful artificially intelligent mind to pick up on all the nuances of contextual trust and help us evaluate complex trust decisions in real-time. There will certainly be public, general-purpose AIs that can aid with this task; however, I believe an interesting usage is a form of a personal assistant. As mentioned above, not all data on the decentralized web will be public. Most (hopefully) will be private or permissioned—shared between 1 or more entities. Feeding your own personal AI assistant your own data, mixed with data that is public and permissioned can fuel a powerful agent that intelligently acts on your behalf, assessing trust decisions, surfacing them to you when it makes sense, and automating the rest.

Similar to the robo-investors of today, imagine being able to automate digital trust decisions in your life tomorrow, whether finding an authentic item at a resale shop, forming a new relationship, scoping out a prospective employer, or even more touchy causes like confiding in the right individual for a sensitive personal matter. Also, trust agents will be used by organizations in the middle of all these decentralized communications for risk/threat scoring, matching algorithms, and more.

It may be hard to imagine going from nascent technologies like DIDs and VCs to automating the most important trust decisions you make in your life, but I believe the vision of the decentralized web, when fully realized, will encompass nearly all that we do and all that makes us ourselves. Having trusted intelligent artificial companions will be fueled by our work here.

Parting Thoughts

The most important place to start is with trust we're familiar with: identifying people, businesses, websites, etc., online. It can be helpful to map our existing concepts of trust to a decentralized model before pushing forward into the less-charted territories of the future. Having meaningful decentralized interactions that mimic those you're familiar with today would be a momentous step for the decentralized identity community.

The perfect decentralized trust system, or systems, do not exist yet. They may never exist. But it's worth starting somewhere. I laud the approaches of Chainlink, the Trust Over IP Foundation, the work we're doing at DIF, and others I may not have mentioned. I'd like to especially call out this recent paper from Rebooting the Web of Trust in the Hague, which covers much of what this post did. Establishing trust in a decentralized manner is hard and extremely delicate.

As more and more sensitive information gets into our hands with the DID movement, the more we have to lose. We need to thoughtfully design our systems of trust to work for us and not create a new less-trusted world than what we have today with centralized trust. We also need to consider the interactions between trust and reputation—for another time. We are in a good position to learn from the mistakes of those who have come before us.

To summarize, here are a few thoughts I think are essential in developing a system of decentralized trust:

  • Low switching cost is a key to decentralization. High switching cost has a centralizing effect on systems.
  • There are trust systems everywhere, let's draw inspiration from the best parts of all of them.
  • Make sure to have a system that closes the loop.
  • We first need to replicate existing trust models.
  • The DID movement will give each individual the data they need to make important trust decisions; in aggregate, we'll have a wealth of public and permissioned data to create a flourishing trust ecosystem.
  • AI is coming, let's embrace it and put it to work to become our digital trust guardians.
  • Do not be prescriptive with trust. Run experiments and iterate. We won't solve it in standards bodies alone.
  • Trust and reputation are closely intertwined.

I look forward to helping think, debate, and build the trust systems of our future. I'll leave you with an invitation: decentralized key signing party, anyone?

Show Comments