Foreword: there are always trade-offs when building encryption projects. Because decentralization often means that it is difficult to start the project, easy to use in the user experience, high cost and limited scalability. In this case, in order to achieve the final goal, how to balance the degree of centralization and decentralization, and how to iterate? Subtle choices and differences may lead the project to a completely different path. The author of this paper is Taylor (decentralized Oracle), translated by “JT” in blue fox’s notes.
When it comes to the decentralization of encryption projects, there seems to be different degrees of comfort. Perhaps this is because there are different views on what the purpose of blockchain is, or it may be because of lack of patience with scalability efforts, or because of the universality of speculators and their subsequent impact on the success or failure of the project.
Either way, if you stop and look at the current field of defi, you may notice the following changes: from focusing on the original encryption ideal (tamper proof, decentralization) to speed, function and efficiency.
On the surface, speculators have no essential mistakes. They stay in the field of encryption. They bring value and users. At the same time, there is also nothing wrong with wanting a better user experience, faster transactions and more efficient systems.
However, there is a big difference between the functions you want to build and treating these built functions as basic builds（ Blue fox notes: what tellor wants to express here is that in the field of encryption, there is nothing wrong with wanting better user experience and faster transactions, but if we take these as the root and forget the security and decentralization in the field of encryption, it is to abandon the Basics)
Bitcoin is not trying to be a more efficient payment method. That’s PayPal’s goal. Bitcoin tries to free us from corruption and outdated intermediaries and become a more efficient payment method than wire transfer, which is a secondary advantage. This is the crux of the problem.
These secondary advantages become the criteria for some people to judge the success or quality of a project. Whenever this happens, we are getting farther and farther away from the spirit of encryption. When we build Web3.0, we must remember the mistakes of Web2.0, otherwise we are doomed to repeat them.
Similar to the early era of the Internet, the first era of cryptocurrency (2009-2017) is like the wild west, which reached its peak in the 1CO era and the notorious bull market（ Notes on blue fox: compare it to 2000 Internet bubble.
We have seen the impact of the 1CO era. Some “Shanzhai” encryption projects do not have any motivation to release projects, but continue to promise future functions, enterprise customers, and a series of empty partner statements. The impact is that people lack trust and confidence in what is built and claimed in the field of encryption. Such a good day is gone, but we need to be reminded that we have not got out of the dilemma.
Now, there are many fewer scams. But the problem we face now is more subtle. Some projects centralize key parts of their projects at the expense of anti censorship, just to allow them to compete in the market.
As a result, we see a variety of dazzling projects that try to force decentralization and “blockchain technology” in as many places as possible. Where they can’t, they promise to incorporate decentralization into their roadmap.
What motivates developers to completely decentralize? In fact, there is no incentive. There is no reward for developers to include decentralization, because they often get rewards for not doing it based on previous commitments.
As we all know, it is difficult to step back into decentralization.
There is a project method called “crawling, walking and running”, which comes from Martin Luther King’s famous saying: “if you can’t fly, run; If you can’t run, go; If you can’t walk, climb. But whatever you do, you must move on. “
I think this shows what is happening in the field of encryption. There are two different definitions for the application of this method in the project:
Climbing – partial decentralization
Go – focus on decentralization
Running – complete decentralization
Most are partially decentralized models and claim to be sufficiently decentralized, or simply ignore the word altogether. New users look happy as long as they can make money or look cutting-edge. However, we should stop rewarding these ideas. Remember, in the creative market, we play a natural role in the survival of the fittest. Unfortunately, however, people do choose wallets over ideals.
Some of these projects have adopted a partially decentralized approach, raised huge funds and received a lot of attention. This has become a magic weapon for others to win, and led to the emergence of a large number of copy projects, misleading projects, and even scam projects. Kind of like a virus. The outbreak of this virus was driven by the 1CO era and continues to live on the feedback cycle.
It spreads like this:
The way to stop this counterproductive and contagious cycle from spreading further is to stop building fundamentally flawed or regressive projects. We should look at the limitations of the current blockchain and build fully decentralized products within these parameters:
Climbing – slow & expensive
Go – limited, but better
Run – scale operation, TBD
Because decentralization without permission is the killer function of the soul of blockchain, while speed and user experience are not. To verify whether these things provide the functionality we want them to provide, we need to iterate the idea of decentralization on a testable scale. Only in this way can we expand the function and add new variables to the equation. That’s how we built tellor, chose a slow but secure design, and started the network. Now that we see it working, we’re starting to improve speed and complexity.
Contrary to the tone of this paper, the centralized function can play an appropriate role, and fundamentally, it is still reasonable and in line with the encryption ideal. The key difference is whether centralized functions pose a censurable risk, or just a risk of inconvenience. For example, many projects use infra, Etherscan and metamask.
Infra is free and easy. Compared with the project running its own node, infra can help the project start and run the project more easily. Compared with the centralized components of your smart contract, the difference is that even if infra is in trouble or even paralyzed, and your project will not be “reviewed”, you can migrate to your node, although there will be some inconveniences in this process. With the expansion of Ethereum and blockchain technology, the centralized platform can play a role in building a better user experience.
When building the project, we need to verify whether our design choices can promote decentralization. Let’s focus on growth and at the same time, don’t compromise on value. After all, this is not only a technology, but also a sport.
Responsible editor: CT