Foreword: there are always trade-offs when building encryption projects. Because decentralization often means that it is difficult to start a project, easy to use in user experience, high cost and limited scalability. In this case, in order to achieve the ultimate goal, how to iterate? Subtle choices, subtle differences, may lead the project to a completely different path.

When it comes to decentralizing encryption projects, there seems to be a different level of comfort. Maybe it’s because of different opinions on what the purpose of blockchain is, or it’s because of a lack of patience with scalability efforts, or it’s 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 area of WiFi, you may notice a change from focusing on the original encryption ideal (tamper proof, decentralized) to speed, functionality, and efficiency.

On the surface, speculators are not fundamentally wrong. They stay in the field of encryption, and they bring value and users. At the same time, it’s also right to want a better user experience, faster transactions, and more efficient systems.

But there’s a big difference between what you’re building and what you’re building as a basic building( Blue fox notes: what telor wants to express here is that in the field of encryption, there is nothing wrong with wanting better user experience and faster transactions. However, if we regard these as fundamental and forget the security and decentralization in the field of encryption, we will go from the beginning to the end.)

Bitcoin is not trying to be a more efficient way to pay. That’s PayPal’s goal. Bitcoin’s attempt to free us from corrupt and outdated intermediaries to become a more efficient way of payment than wire transfer 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. Every time this happens, we get further away from the spirit of encryption. When we build Web3.0, we must remember the mistakes of Web2.0, or we will be 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 peaked in the 1CO era and the infamous 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 have no motivation to release projects, but continue to promise future functions and enterprise customers, as well as 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 far away, but we need to be reminded that we are not out of the predicament.

Now, there are a lot less scams. But the problems we face now are more subtle. Some projects centralize the key parts of their projects, sacrificing the anti censorship attribute, just to let them compete in the market.

As a result, we see a variety of dazzling projects that try to force decentralization and “blockchain technology” in as much as possible. Where they can’t, they promise to include decentralization in their roadmap.

What motivates developers to be completely decentralized? In fact, there is no incentive. For developers, there is no incentive to include decentralization, because they are often rewarded for not doing it based on early commitment.

As we all know, it’s hard to step back to decentralization.

There is a project method called “crawl. Walk. Run”, 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 have to move on. “

In my opinion, this shows what is happening in the field of encryption. There are two different definitions for project application of this method:

*Definition error

Climbing: partial decentralization

Go ahead – focus on decentralization

Running – Total decentralization

Most of them are partially decentralized and claim to be sufficiently decentralized, or ignore the word altogether. New users look happy as long as they make money or look cutting-edge. But 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 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 fraud projects. It’s kind of like a virus. The outbreak of this virus was driven by the 1CO era and continued to live on a feedback loop.

It spreads like this:

How to balance the decentralization of blockchain technology

The way to stop this counterproductive and infectious cycle from spreading further is to stop building fundamentally flawed or regressive projects. We should look at the limitations of the current blockchain, and then build a fully decentralized product within these parameters:

*Correct definition

Climbing – slow & expensive

Go – limited, but better

Run – scale operation, to be determined

That’s what it should be.

Because decentralization without permission is the killer function of the soul of blockchain, while speed and user experience are not. To verify that 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 our functions and add new variables to the equation. That’s how we’ve built the telor, choosing a slow but secure design, and starting the network. Now that we see it working, we’re starting to work on speed and complexity.

Contrary to the keynote of this paper, the centralized function can play an appropriate role, and fundamentally speaking, it is still reasonable and in line with the encryption ideal. The key difference is whether a centralized function creates a risk of censorship, or just inconvenience. For example, many projects use infra, Etherscan, and metamask.

Infera is free and easy. It can help projects start and run more easily than running their own nodes. Compared with the centralized component of your smart contract, the difference is that even if infera is in trouble, or even paralyzed, and your project will not be “censored”, you can migrate to your node, although there will be some inconvenience in the process. With the expansion of Ethereum and blockchain technology, the centralized platform can play a role in building a better user experience.

When building a 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, it’s not just technology, it’s a sport.

Responsible editor; zl

Leave a Reply

Your email address will not be published. Required fields are marked *