Incremental Decentralization
Introduction
Web 3 UX has been the focus of many projects’ conversations in the last year for good reason. The BUIDL rally of 2018 was well-founded, but the catchphrase “If you build it, they will come” is clearly not applicable to novel technologies like blockchain and dapps that are still unfamiliar to the mainstream audience. Well-known issues like the cost paradox and key management hinders widespread adoption, and many bright minds have proposed promising solutions that are resulting in the emerging pattern of Incremental Decentralization.
Incremental Decentralization is based on the concept that the decentralization of fundamental features should be positively correlated to user comfort with Web 3. Looking at the adoption curve, it seems clear that we are exiting the “Innovators” phase and are now in the beginnings of the “Early Adopters” phase. Assuming that many readers have been around for a while, it can be easy for us to forget the immense leap of faith required of new users to engage with the Web 3 world and it’s important to set the stage for the successful transition across the chasm into the “Early Majority” phase.
Now that we have some context around the “what” and the “why” of Incremental Decentralization, let’s get into the “how”. 4 core ideas underpin the pattern of Incremental Decentralization: minimum viable trust, multiple graded entry points, user-initiated exits, and layer 2 first design.
Minimum Viable Trust
At the risk of propagating another 3 letter buzzword, minimum viable trust (MVT) — a term coined by James Young — serves as the cornerstone idea of Incremental Decentralization. MVT refers to the prioritization of convenient, centralized features that add immediate, tangible value with the option for a user to introduce decentralization at their own convenience. The rewards of decentralization are many, and the user should be given opportunities to arrive at this conclusion on their own will through direct experimentation. Instead of sticking every new user into the deep end of the decentralization spectrum like we do now with poorly designed cookie-cutter molds, we let the users take ownership of their journey through Web 3.
This might mean that your users have an onboarding process that is facilitated by a centralized provider. For example, your dapp may integrate account contracts that use AWS Cognito’s username-password-email scheme to facilitate signup, login, and recovery processes. The use of a centralized provider in this scenario enables a familiar onboarding process while preserving the user’s choice to move on to a self-managed private-key based wallet. James Young aptly puts it like this: “… if this option does not exist then the user is forced to choose between two extremes. Dogmatic maximalism may unwittingly drive mass adoption to centralized custodial providers in the short term, which kind of defeats the purpose.”
Multiple Graded Entry Points
That brings us to the provision of multiple graded entry points. This expands on the idea that users shouldn’t be defined by binary cookie-cutter molds of complete noob or Web 3 pro, and dapps would be better off meeting users where they are. Instead of making assumptions or imposing decisions about where they should be, dapps can provide a variety of opportunities for a user to “level up” along the spectrum of decentralization. Blockchain is all about incentives, so why not bake in incentives (both implicit and explicit) for users to self-educate themselves on the benefits, challenges, and means to get to the deeper end?
Much has been said about the mechanisms of explicit incentives through tokenization, so let’s explore a simple real-world example of implicit incentives. Abridged has built an implementation of account contracts that enables users to counterfactually generate contract-based accounts. This allows a novice user to immediately onboard with a dapp, add work-based value, and start accruing funds. Since the account is counterfactually instantiated, the user must deploy the account contract to access the funds. When she has accrued enough funds that she wants to withdraw it, her gas fee is covered and she is implicitly incentivized to learn more about contract deployment and the implications of a decentralized money. (Note: even better, deployment and gas can be abstracted in this scenario by using language like “Pay a nominal one-time transaction fee to access your funds.”) As alternative entry points, a more experienced user might simply import a seed phrase, transfer funds from another wallet, or use Universal Login.
User Initiated Exits
A corollary to having multiple graded entry points is to enable user-initiated exits. If your user decides that a certain level of decentralization (and potential accompanying discomfort) is not her cup of tea, she could be given the option to add some centralization back into her experience. Centralization of features is acceptable only if users have self-custody and can exit anytime. Coinbase is an example of a service that has superb UX through centralization, but the inability to claim your private keys creates user lock-in and that is something we’d like to avoid.
Let’s look again at the previous example of a dapp integrating account contracts using AWS Cognito. In that scenario, funds in the account contracts always belong to the user. If AWS Cognito were to ever disappear, the user would be unaffected because it would be a simple matter to recover the funds using a different interface. A user could also easily exit by deploying the account contract and withdrawing the funds, unencumbered by the absence of AWS Cognito. Using a centralized provider in this case doesn’t bind the user to the trappings of Web 2.0.
Layer 2 First Design
Finally, we arrive at layer 2 first design for dapps. A number of useful layer 2 solutions have been invented and while they seem to feature in a number of planned product roadmaps, current utilization is few and far in between aside from the projects that built them. Coming from another angle, blockchain dapps should be data-informed just like any Web 2.0 apps, but there is a glaring lack of an analytics tool for off-chain activity. This demonstrates the current heavy skew towards on-chain transactions (understandably) but it’s becoming clearer that layer 2 solutions contribute immensely to a delightful dapp UX.
It’s important to point out that some layer 2 solutions like state channels and account contracts are production-ready. When used strategically, they can serve as vessels for dapps to offer their users avenues for Incremental Decentralization. Layer 2 first design primes dapp-building teams to look ahead and account for UX elements that differ from those used by on-chain only activities, and it may be challenging to retrofit a dapp that didn’t consider layer 2 solutions. Off-chain transactions will become as important, if not more, as on-chain transactions and the dapp narrative needs to reflect this shift in design strategy.
Conclusion
Incremental Decentralization as a pattern has been developing for some time now, but 2019 seems to the year that it will take the main stage to become a best practice. Incremental Decentralization is like cake frosting. Cake frosting is not necessary, but it makes cake look much more appetizing and prompts you to give it a taste. In a similar vein, you may be the best baker (developer) in the world making the best tasting cake (dapp). However, no one is going to try your cake if it doesn’t look good no matter how much you tell them it’s super tasty.
The maturity of layer 2 solutions, the palpable shift within the Ethereum community towards sustainable businesses, and the need for user-focused dapps all converge towards the 4 core ideas outlined above. A future post will explore suggestions for a developer workflow centered around layer 2 design and in line with the pattern of Incremental Decentralization. We’ll specifically focus on the use of Abridged account contracts, Wyre and the Gas Station Network to provide a delightful experience for a new user’s first 2 minutes on your dapp. Feedback is always welcome, and we highly encourage you to reach out if any of these ideas resonate with you.
Special thanks to Sina Habibian and Charles St. Louis for excellent feedback on the draft of this post.
