Trade-offs in blockchain projects: climb, walk, run

Foreword: When building a crypto project, there are always trade-offs involved. Because decentralization often means that it is difficult to start the project, it is difficult to achieve ease of use in the user experience, and the cost is high and the scalability is limited. 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, subtle differences, may lead the project to a completely different path. The writer of this article is Tellor (decentralized oracle), translated by "JT" from Blue Fox Notes.

When it comes to the decentralization of crypto projects, there seems to be different comfort levels. Perhaps this is because there are different views on what the purpose of the blockchain is, it may also be because of a lack of patience with scalability efforts, or because of the pervasiveness 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 a change from the focus on the original encryption ideal (immutable, decentralized) to speed, functionality, and efficiency.

On the surface, speculators are not fundamentally wrong. They stay in the crypto space and they bring value and users. At the same time, there is nothing wrong with wanting a better user experience, faster transactions, and more efficient systems.

However, there is a big difference between what you want to build and what you build as a basic build. (Blue Fox Note: What Tellor wants to express here is that in the encryption field, there is nothing wrong with wanting a better user experience and faster transactions, but if you take these as fundamentals, and forget the security and decentralization in the encryption field And that's the end of the book)

Bitcoin is not trying to become a more efficient payment method. That's the goal of Paypal. Bitcoin's attempt to free us from corrupt and outdated intermediaries and become a more efficient payment method than wire transfer is a secondary advantage. This is the crux of the problem.

These secondary advantages become the criterion 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 web 3.0, we must remember the errors of web 2.0, otherwise we are destined to repeat these errors.

Similar to the early era of the Internet, the first era of cryptocurrencies (2009-2017) was like the Wild West, which reached its peak in the 1CO era and the infamous bull market. (Blue Fox Note: Compare it to the 2000 Internet bubble)

We have seen the impact of the 1CO era. Some "copycat" crypto projects have no incentive to release projects, but only continue to promise future features and corporate customers, as well as a series of empty partner statements. The effect is a lack of trust and confidence in what is being built and claimed in the crypto space. Such good days are long gone, but we need to remind us that we have not come out of our predicament.

Now, there are fewer scam projects. However, the problems we face now are more subtle. Some projects centralize key parts of their projects, sacrificing censorship resistance, just to allow them to compete in the market.

As a result, we see a variety of dazzling projects that try to force as much decentralization and "blockchain technology" as possible, and where they cannot force it in, they promise to decentralize Into its roadmap.

What motivates developers to become completely decentralized? In fact, there is no incentive. For developers, there is no reward for including decentralization, because based on the early commitment, they often get rewarded for not doing it.

As we all know, it is difficult to step back and enter decentralization.

There is a project method called "crawl, walk, run", which is derived from Martin Luther King's famous saying:

"If you can't fly, then run; if you can't run, then go; if you can't go, then climb. But no matter what you do, you have to move on."

I think this illustrates what is currently happening in the crypto space. There are two different definitions of this method applied by the project:

* Definition error

Crawl-Partially decentralized

Go-mainly decentralized

Run-completely decentralized

Most are partially decentralized models and claim to be sufficiently decentralized, or simply ignore the term altogether. New users look happy as long as they 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. But, unfortunately, people do choose wallets over ideals.

Some of these projects have used a partially decentralized approach to raise huge amounts of money and have received a lot of attention. This has become a winning weapon for others, and has led to the emergence of a large number of copy projects, misleading projects, and even scam projects. A bit like a virus. The outbreak of this virus was driven by the 1CO era and continues to live on a feedback loop.

It spreads like this:

What prevents this counterproductive and contagious cycle from spreading further is to no longer build projects that are fundamentally flawed or retrogressive. We should look at the limitations of the current blockchain and build a fully decentralized product within these parameters:

* Defined correctly

Climbing-Slow & Expensive

Go-limited, but better

Run-scale operation, to be determined

That should be it.

Because permissionless decentralization is the killer function of the blockchain soul, while speed and user experience are not. In order to verify if these things provide the functionality we want them to provide, we need to iterate the idea of ​​decentralization on a testable scale. Only then can we expand functionality and add new variables to the equation. This is how we built Tellor, choosing a slow but secure design, and starting the network. Now that we are seeing it work, we are starting to increase speed and complexity.

Contrary to the tone of this article, the centralization function can play an appropriate role, and fundamentally, it is still reasonable and in line with the ideal of encryption. The key difference is whether the centralized function creates an auditable risk or simply causes inconvenience. For example, many projects use Infura, Etherscan, and Metamask.

Infura is free and easy. Infura can help projects get up and running more easily than running their own nodes. Compared with the centralized component of your smart contract, the difference is that even if Infura suffers or is even paralyzed, and your project will not be "reviewed", you can migrate to your node, although this process will There are some inconveniences. With the expansion of Ethereum and blockchain technology, centralized platforms can play a role in building a better user experience.

When building a project, we need to verify that the design choices we make can advance decentralization. Let's focus on growth and at the same time don't compromise on value. After all, it's not just technology, it's a sport.


Risk Warning: All articles of Blue Fox Notes can not be used as investment advice or recommendations. Investment is risky. Investment should consider personal risk tolerance. It is recommended to conduct in-depth inspection of the project and make good investment decisions.