Previously, I explored decentralization benefits from first principles and why progressive decentralization is failing short of its goal. In this section, I will argue for centralizing some functions while decentralizing others.
To understand the tradeoff of decentralization, we must clearly define the system in which we are talking about decentralization in. In the L1 case, when researchers talk about decentralization, they are talking about the decentralization of the network operation layer, specifically around the decentralization of block generation and verification. Decentralization in the network operation layer is well-understood. While decentralization in the network layer has clear mathematical relationships with other key properties, decentralization in the L1 governance process does not (Vitalik, 2017). This is why on L1s we apply different meanings and measures of decentralization when talking about the L1 itself and the governance/upgrade process of L1.
In DAOs, decentralization is often discussed by bundling protocol and product together and applying the same logic. However, I argue that protocol and product should be treated explicitly differently regarding decentralization. Here are the reasons:
1. Protocol governance offers higher decentralization benefits than product governance.
2. Protocol development and product development have different natures.
Some definitions here, not strict but to give an idea what I am referring to here.
Protocol: onchain code facilitating interactions.
Protocol governance: governance process on changes to the code/logic of the onchain interaction.
Product: interface for user to engage with the protocol.
Protocol governance: governance process on changes to the interface on how the user interacts.
Decentralization in the protocol governance layer offers greater benefits than decentralization in the product governance layer. Protocol governance changes have on-chain outcomes, while product governance changes have off-chain outcomes. In product governance, the finished work requires privileged access to centralized off-chain services (such as front-end hosting and app store upgrades) to be implemented. This centralized nature of the product provides less regulatory protection compared to decentralization. This privileged group always initiates changes. Additionally, if a regulatory agency aims to restrict access to an innovative crypto protocol, it will target the product first. Therefore, even if we decentralize the governance process for product changes, the benefits of such decentralization are limited due to the underlying technology's centralization nature.
Products do not pose the same platform risk as protocols. Our assets and the protocol exist on-chain, so the product lacks the same power as its web2 counterparts. For instance, if the current Uniswap front-end were to impose a 3% charge on every swap, users could simply interact with the underlying protocol through another front-end. This is because the network effect between swappers and liquidity providers is at the protocol level, not the product level. However, if the Uniswap Protocol were to suddenly take 3% of every swap, it would be much more difficult for swappers and liquidity providers to coordinate and find an alternative solution. Therefore, the benefits of eliminating platform risk are much greater when the protocol is decentralized compared to when the product is decentralized.
Decentralization in the product and protocol layer would benefit the preservation of legitimacy. By decentralizing the decision-making process, the development process would be perceived as fair, thereby better preserving social legitimacy. Therefore, both the protocol and the product would benefit from decentralization in terms of legitimacy.
Decentralization in the governance layer often results in higher coordination costs among participants. However, the participants involved in protocol development and product development differ significantly. In the protocol development process, the main parties are coders and researchers. In the product development process, designers, product managers, and marketing professionals join the coders. This influx of talent increases communication costs among participants. It is reasonable to assume that if product development operates in a decentralized manner, it would be slower than protocol development due to higher communication costs. While there isn't a perfect example of decentralized product development, decentralized protocol development already exists in Ethereum and other blockchains. One thing we have observed from this process is that the speed of adoption is slow. The average time for an Ethereum Improvement Proposal (EIP) to be adopted is around two years, and there are more than a dozen EIPs authored by Vitalik that are still in the queue.
If the development process of decentralized protocols is slow and the development process of decentralized products is even slower, can we create competitive products when decentralizing everything? I believe the answer is no.
Product development is a rapid and iterative process. Questions like "Where should we place this button?" and "Should we add another analytics page?" are subjective and influenced by people's opinions. Excessive oversight and unnecessary overhead can significantly impede the creative process. Even with a streamlined governance process like optimistic approval, the barriers to product innovation remain.
Crypto products need to iterate quickly to meet user needs and compete with existing web2 solutions (Moxie, 2016). However, iterating publicly presents strategic challenges because competitors can potentially monitor all actions taken by the development team. To address this, many core teams develop the complete product in-house before unveiling it to the community (e.g., Aave and $GHO, Uniswap V3 upgrade), similar to how a company builds a product.
In summary, I believe the benefits of decentralization in protocol development outweigh the tradeoffs, making it favorable for protocol development to be decentralized. However, the cost of decentralization in product development does not justify the benefits, so it is more practical for product development to be centralized.
Now, how do you put it into practice? In the last part, I will combine all these together into a playbook and explain how could a prominent protocol, Uniswap, decentralize using this playbook.
this is super cool. i recently broke down the different approaches to products/protocols from the founder's perspective. could be cool to combine some of what's here on the governance front