Last week, I explored Cherie Aimée's suggestion that if blockchain technology is to achieve mass adoption, people need to know they can trust blockchains. Since stories cultivate trust, I suggested that storytelling about the ecosystems that grow and nurture the technology could help encourage mass adoption. Now I would like to take a step back and look at the concept of trust in blockchain adoption. What is a "trustless" system? Can a trustless system be trusted? And what's the relationship between trust, architecture, and adoption?
Blockchains are not called "trustless systems" because no trust is involved; rather, users trust the technology to do what it's been designed to do. Instead of relying on human intermediaries to create or enforce the terms of a transaction, users can rely on the stability and predictability of the blockchain protocol. As the Lisk Academy explains, the protocol provides the basis for trust:"Participants on the network run complex consensus protocols to unanimously and securely agree on what should be added to the distributed ledger of blockchain, whilst also ensuring its integrity at all times. As it is these failsafe protocols providing the basis for trust, it allows for the removal of middlemen and, as a result, decrease in the overall cost of transacting."
In this system, trust is not eliminated, but reduced. As Preethi Kasireddy, founder and CEO of TruStory, writes, "[Blockchains] minimize the amount of trust required from any single actor in the system. They do this by distributing trust among different actors in the system via an economic game that incentivizes actors to cooperate with the rules defined by the protocol."
But although reliance on any single actor is minimized and trust is distributed, the efficacy of the blockchain depends on the faith in (i.e., the use of) the protocol, which amounts to faith in the designers of the software involved. When you move into a house, you are trusting not only that the roof won't come crashing down on your head, but also that the house has all the design features needed for dignified living.
Likewise, when users rely on the protocol, they are trusting that the software has been built in such a way that benefits their specific needs as users of a product. The "middleman" has not been entirely removed, though there is a primary difference here between, say, the central banks and blockchains (and houses, for that matter). The public nature of distributed ledger technology requires transparency: Users can see the technology at work and how the form affects its function. It's faith, but it isn't blind.
Trust and Adoption
Trust and adoption go hand in hand. Users will adopt what they consider trustworthy. To some extent, on a practical level, this means what is functional or useful to them. Users are trusting the architecture designed by developers, and the proof is in the pudding.
As previously explored in a discussion on evolving Web3 infrastructure, blockchain architecture and adoption often have a simultaneous and symbiotic relationship. In a way, architecture and adoption are swapping stories: Developers tell a story in the ways they construct the technology and users respond to this initial yarn with the story of their encounter with it. It is by no means a one-way encounter or even a trustless one: Trust is developed through mutual interaction.
In this sense, storytelling to build trust isn't something that happens only after the design process is finished in order to market a product. To use Marshall McLuhan's famous adage: The medium is the message. Human stories are implicit in the structures they build. The architecture tells the story and becomes the trusted meditator.
If people don't believe dApps are useful or reliable, they won't adopt them. Of course, people can choose to use a dApp – even a flawed one – without believing in it wholesale if it suits some of their needs. But if the story being told by the technology doesn't have relevance for users, they have little reason to trust it.
This starts to get to the bigger question: Should people trust blockchain technology? As we saw with internet adoption, people may entrust their data to less-than-trustworthy entities. People can use a technology without being aware of all the consequences or possible things that can go wrong. They may only be privy to part of the story, or the story they are being told about the product may not match the story inherent in the product's structure.
This is very important to keep in mind when discussing who is involved in the development of blockchains and dApps. As Taylor Monahan observed in the AraCon 2019 panel titled "Recruiting for a Diverse Web3," the danger of not prioritizing diversity in blockchain development is that you will end up with products that primarily or exclusively benefit white, privileged young males. Panelist Medha Kothari pointed out that the biases of developers are present in the technologies they create, so if the goal is for blockchains to benefit everyone, the people building these systems need to be representative of the world's global, diverse population.
If people of color, women, and LGBTQ+ people are not actively invited, supported (financially and otherwise), and included in design discussions and development of blockchains, the story being told to them is very clear: This technology isn't for you. And there is no reason in the world why they should voluntarily adopt or trust a technology if it isn't built for them by people who represent them and are attuned to their lives and stories.
Blockchain technology has the potential to revolutionize the world. But if we want to get there, we might have to a hard look at the stories our technology is telling.