Viewpoint | Incremental decentralization, decentralized and gradual approach

Author; Eric Chung

Translation: Frau Yang

This is an in-depth thinking and solution on how to achieve decentralization. This article discusses dapp products, but the four core ideas proposed by it are also applicable to DAO. The original title is: Incremental Decentralization. "Incremental decentralization" is my understanding of it. Increment has two meanings: 1. The improvement of the user rank, whether it is a dapp or DAO, there are certain entry barriers for users. The intervention of centralized elements allows users to get started with dapps or DAOs just like using Web2 products. On this basis, through some strategies, the user's Web3 segment is gradually cultivated, and finally complete decentralization is achieved; 2. The increase in scale, the same Regardless of whether it is a dapp or DAO, the user scale needs to be considered first. The centralization element is the bridge to the decentralization of the user. When the user scale reaches a certain level, the user will be gradually guided to decentralize. Incremental decentralization may be the decentralized way of survival and development. James Young mentioned in the article is a senior expert in decentralized practice. He is a "first honor" builder of Moloch and the core figure of MetaCartel and VentureDAO. This article has always been my "pillow book", and every time I turn it, I will gain something. Recommend to everyone! —— Typto

Introduction

There are a lot of signs that the UX experience of Web 3 in 2018 has become the focus of many project discussions. BUIDL 2018 is well organized, but the slogan of the conference " If you build it, they will come." Is not applicable to new areas that are not yet familiar to mainstream audiences such as blockchain and Dapp. Well-known issues , such as cost paradoxes and key management issues, have become obstacles to their widespread acceptance. So some people have given the expected solutions to these problems, and the "progressive decentralization" model has emerged.

Progressive decentralization is based on the idea that the degree of decentralization of basic functions should be positively related to the user experience of Web 3. As can be seen from the adoption curve in the figure below, it is clear that we are moving out of the original "innovator" stage and are now in the "seed user" stage. If readers of this article pay attention to decentralization issues, they may easily ignore the threshold for new users to enter the WEB3 world. They need to change many inherent cognitions. Therefore, the concept of progressive decentralization is used to pave the way for App user groups to cross early markets The transition to the mainstream market for the "faster-accepting mass users" stage is particularly important.

Can we bridge the divide?

Legend explanation: left to right: innovators, seed users, mass users who accept faster, mass users who accept slower, laggards

The evolution of the market is divided into two phases: early market and mainstream market, and there is a gap between the two phases.

Now that we have some background on progressive decentralized "what" and "why", let's start exploring the question of "how". We summarize four core ideas that underpin the entire model of progressive decentralization:

  • Minimum viable trust
  • Multi-level entry point
  • User-initiated exit
  • Layer2 priority design

Minimum viable trust

Minimum Viable Trust (MVT, Minimum Viable Trust, terminology proposed by James Young ) is the cornerstone idea of ​​progressive decentralization. MVT refers to prioritizing convenience and centralized features, so that it provides users with a free choice. They can introduce decentralized attributes when they think they are appropriate, thereby improving the timely feedback experience of web3 products. And visible value. The benefits of decentralization are many, but we should give users the opportunity to personally come to this conclusion. Instead of letting users accept pre-designed solutions like cookies made by poor molds, it is better to let users control their online 3 Right to explore on your own.

Obviously, this cookie mold can achieve the desired effect

This may mean that your users will have a hands-on process provided by a centralized service provider. For example, your dapp might use an account contract that integrates the AWS Cognito "username-password-mail" scheme to simplify the process of account registration, login, and recovery. In this case, while providing the user with a familiar onboarding process, the user is provided with an option to allow the user to transfer account information to a wallet in which the private key is completely controlled by himself. James Young states: "… If we do not give users this choice, then users will have to choose between the two extremes of centralization and decentralization, and dogmatic extremism may inadvertently result in a short period of time. The loss of users and their shift to centralized products is contrary to the original intention of decentralization. "

Multi-level entry point

This model provides us with a multi-level entry point, which is derived from the view that we should not define users with a cookie cutter-like binary model such as "pure rookie" or "Web3 master", dapp is best Can meet user needs at the stage (or stage) where the user is. Dapps can set various timings for users to help them "trick and upgrade" in the decentralized spectrum, instead of making assumptions and forcing delineation on which stage they should be. The blockchain itself is an incentive mechanism, so why don't we introduce an incentive mechanism (whether explicit or implicit) to allow users to implement self-education through benefits, challenges, and strategies to help users improve their rank?

With enough explicit incentives through tokenization, let's explore a simple example of implicit incentives in the real world. Abridgeed has designed an account contract implementation that allows users to "contra fact" generate contract-based accounts so that novice users can immediately use dapps, create work value, and start accumulating funds. As the account is a counterfactual instance, the user must deploy this account contract to access her account funds. When she has accumulated enough funds to withdraw, GAS fees have been offset, and inadvertently in the process Inspired her to learn more about contract deployment and decentralized assets (note: better yet, in this case, you can use something like "pay a token one-time transaction fee to access your funds" Class methods so that contract deployment and GAS fees can be abstracted). As an optional entry point, more experienced users in the Web3 world simply need to enter a mnemonic, transfer funds from other wallets, or use Universal Login .

Translator's Note: The "counterfactual" mentioned in the article asks Baidu "counterfactual thinking" to understand its meaning.

User-initiated exit

The inevitable consequence of having multiple hierarchical entry points is that users must be able to initiate exit requests on their own. If your user thinks that a certain degree of decentralization ( and the resulting unsuitable user experience) is not the type she likes, you can choose to add some centralization elements to her experience. The premise of centralization is that users must have self-management rights and can exit at any time. Coinbase is an example of a centralized service that provides an excellent user experience, but it can't let you get your private key, so it will lead to the risk of users being locked out. This is something we want to avoid.

Let's take another look at a dapp instance using the AWS Cognito integration account contract. In this case, the funds in the account contract always belong to the user. If AWS Cognito disappears forever, the user will not be affected because there is no centralized account system for the same simple operation for receiving funds In addition, users can easily withdraw funds by deploying account contracts without any restrictions from AWS Cognito. Based on this model, intervention in centralized service providers will not fall into the trap of binding users to Web2.0.

Providing users with an option to opt out at any time can increase their comfort with the dapp

Layer 2 priority design

Finally, let's look at the Layer 2 priority design for dapps. We already have a large number of practical Layer 2 solutions, and although they seem to have appeared on many planned product roadmaps , except for building their own projects, they are currently underutilized. From another perspective, blockchain dapps should have data notification capabilities like any Web 2.0 application, but obviously we also lack analytical tools for off-chain activities. This shows that people currently have a serious preference for on-chain transactions. Although understandable, it is becoming increasingly clear that the Layer 2 solution greatly promotes the enjoyment of the dapp user experience.

Translator's Note: James Young is already working on an "open-metrics dashboard" specifically for dapp big data analysis

This is especially important. Some Layer 2 solutions, such as status channels and account contracts, are ready for use. They can be used strategically as dapp containers, providing users with an effective way to progressively decentralize. The concept of layer 2 priority design can help dapp development teams focus on the future and consider those user experience (UX) elements that are different from pure on-chain behavior. It is well known that transforming dapps that do not consider Layer 2 solutions will be a huge undertaking. Challenge. Off-chain transactions will become as important as or even more important than on-chain transactions, so the design of dapps needs to reflect this shift in design strategy.

in conclusion

Progressive decentralization has evolved as a model for some time, but 2019 seems to be the best practice phase of the model. Progressive decentralization is like sprinkle a layer of frosting on the cake. The frosting on the cake is not necessary, but it makes the cake look more appetizing and more attractive to people to taste. Similarly, you may be the best baker (developer) in the world and can make the most delicious cake (dapp) in the world. But if your cake doesn't look tempting, no one will want to taste your cake, even if you tell them how delicious your cake is.

You want your dapp to look like the cake on the right, delicious inside and out

Left: Progressive decentralization is not applied. Right: Progressive decentralization is applied.

Users want the Dapp to look like the cake on the right, delicious inside and out

The maturity of the Layer 2 solution, the transition of the Ethereum community to sustainable business, and the demand for user-centric dapps all tend to the four core ideas mentioned above. I will explore suggestions for building a developer workflow around Layer 2 in a future article, which is consistent with the progressive decentralization model, and we will also focus on the use of Abridged account contracts, Wyre, and Gas Station Network for new The user has a pleasant experience within 2 minutes of using the dapp. We welcome your feedback. If you resonate with any of our opinions, we strongly recommend that you contact us.

Special thanks to Sina Habibian and Charles St. Louis for their excellent feedback on this draft.

Original address: https://medium.com/abridged-io/incremental-decentralization-7f0110b0997