Opinion | Satoshi Nakamoto's idea of ​​multi-client proves correct?

Ten years of development experience in the field of blockchain technology has collected a large amount of data, and we can use these data for analysis to reach consensus where there are differences.

Image source: pixabay

An important difference is the perception of multiple clients. In the Bitcoin space, Blockstream has managed to get miners to sign a document stating that miners can only run Bitcoin Core.

• CoinGeek Conference 2020 | Satoshi Omoto: You have a misunderstanding about Bitcoin!
• Why did Facebook create the Move language for Libra? Calibra digital executive tells the inside story
• Interpretation | FCoin Shutdown: A Quick Look at the Exchange's Death Stance

It's unclear exactly why they chose to do this, but Ethereum took a different approach, launching multiple clients from the beginning, and eventually formed a dual-headed monopoly pattern of Geth and Parity. Now it can be said that the duopoly operation is not very good, and currently Parity is in the process of being transferred to the "community".

Why doesn't it work? There are many reasons, but the main reason may be due to natural incentives. For example, if you work for Geth, you naturally want miners, businesses, and every user to run Geth; if you work for Parity, you also want everyone to choose Parity. Let's call it "Mynode" or "yournode" in the abstract.

In the beginning, "My Node" and "Your Node" have the same goals, so they are friends, but if a bug occurs in "My Node", you might point out that this is a "My Node" error, So people should use "your node".

This may sound like a fact statement, but "My Node" and developers may not be happy to say "Your Node", so they may point out questions about "Your Node".

At the beginning, although we worked for different clients, the code / project was basically the same. However, over time, we gradually evolved from one team to two teams with little intersection.

This is the nature of the competition, and the ultimate purpose of the two clients' competition is funds. This kind of competition is indirect in some procedures, but sometimes quite direct. If "your client" is considered better, then you will have more nodes, users, etc., then more code will pass through and eventually get more funds.

There are two ways to compete. By competing you become faster, higher, and stronger, ignoring competition to some extent. Or, for example, in order to escape the bear you are desperately running, you don't have to run faster than the bear, you just have to run faster than others.

Obviously, we all like those who become higher, faster, and stronger through competition, but they are not necessarily the ones who ultimately win. Those who are called "stumbling blocks", that is, those who throw obstacles at people who are about to overtake them behind them, may instead be winners.

Therefore, it can be logically concluded that in some cases, minimizing competition is far better than promoting competition.

Coordination problem

It is possible to translate everything and every design into an ability to facilitate coordination or organize more effectively if someone wants to.

Thought is probably the most powerful coordination tool, so it can stand on power, money, and even the army. It is subject to the motto: It is not the strongest or smartest people who can survive, but the people who are most adaptable to change.

The contradiction between a coordinated idea and the need to adapt to change can be a good excuse for many issues. Habit is the expression of thought. It's hard to change because it coordinates issues automatically: like what is the first thing you do when you get up. Time is very limited and you certainly don't want to spend too much time every morning deciding whether to eat breakfast, run, brush your teeth or other things.

If a habit is taking shape, you will encounter resistance to really develop it, because if you keep changing things, then you will not make many decisions automatically through habit. By the same token, once you develop a habit of running, if you feel uncomfortable and decide not to run, you will encounter resistance.

The purpose of saying so much is to point out that it is not necessarily better to have two teams, because they do not necessarily stand on the same stand, so coordination problems may occur, which eventually leads to the division of the two teams.

Redundant thought

Two teams doing the same thing can lead to inefficiencies, but this is probably the least feared when this comment was published ten years ago:

"I don't think Bitcoin's second compatible implementation would be a good idea. This design relies heavily on all nodes getting exactly the same results in the locking step, so the second implementation will pose a threat to the network."

This is a very powerful word. From the current experience, this seems to be a good reason, because every time there are two outstanding teams at the same time, there will be a blockchain split or something like that.

This is because the developers of "My Node" and the developers of "Your Node" may have different ideas about what code to execute. As a result, some disputes will eventually arise, as both parties want to do things their own way, leading to a collapse of coordination due to the absence of a good decision-making mechanism.

So hierarchy is important. If two teams run under one management layer and management can step in, then two teams may be better than one team, but if no one makes the final decision, then the time spent by the two teams in resolving coordination issues It will take much more time than construction.

However, this goes against the idea that there should be two or more clients so that no one can direct or control the network. However, experience has shown that this suggestion is too naive, and reality has shown that it is actually the opposite. In fact, both inside and between clients, there may be a lack of a final conclusion, or decentralized decision, that helps solve the problem between the need for coordination and the desire for autonomy, which is a very old problem .

For multiple clients, the best proof is probably the best argument. That is, if one client is defective and the other is not, the network can continue to operate.

This ignores a more complicated fact: why one client was vulnerable in the beginning and the other was not. Is this because of uneven distribution of resources? Without these resources, wouldn't there be such a loophole? Could it be "your node" is happy to let "my node" continue to run this vulnerability, even though they may be aware of this vulnerability? If all resources are concentrated in one team, can vulnerabilities be fixed faster? Assuming cross-client decision-making is required, will consensus be reached faster if it is one team instead of two teams?

Depending on the circumstances, the answer is likely to be different. But usually, this is obviously the case when multiple clients convert to multiple networks.

Hayek Road

The field of cryptography has its theoretical foundation. It can be said that it runs on Hayek's "denationalization of money" thought. Thoughts are universal and abstract, so they are being enriched through experience.

In the era of Hayek, even computers were not popular, so he envisioned that there might be some centralized companies issuing private market currencies in a competitive manner. This competition tends to keep the value of funds relatively stable, that is, you can Buy an apple with one unit of currency. After a century, you can still buy an apple with so many, no more and no less.

Bitcoin has a very specific monetary policy in a complex design that reveals a lot of information about the nature of the currency, but Satoshi Nakamoto pointed out that if people want something like domain name services, they should create their own network.

So we now have all these different networks that do all these different things and are influenced by market judgment. This means that decentralization is more about competition between different projects than competition within projects.

From this it is clear why Satoshi Nakamoto believes that scalability is not a problem at all, even if it is converted to a data center node. For him, this is not a problem, because he believes that good management does not necessarily come from within the network, but from competition between networks.

Expansion of the economy will naturally make him think that the network itself will become quite centralized. The phrase "the core design of Bitcoin is immutable throughout its life cycle" shows that he obviously believes that there cannot be two parameters on the same network Different nodes, so there can be no competition.

Instead, you have a design that is enforced by certain incentives, and these incentives will continue to be enforced even if some components (such as developers, miners, or well-known companies) become centralized. Decentralization within the network can test whether these different components can work together against users.

If instead of malicious or improper execution from the outside of the network, there is "better" development, the different interests between these components will cause friction and division, thereby forcing the ultimate decentralization through design: multiple The internet.

This brutal division largely ignores the impact of this competition on the "mother" (parent network). We think this is basically a brutal battle of giants and a battle of market forces. It is for the phrase "the ones who can survive are not the most powerful or the smartest people, but the people who are most adaptable to change." The motto adds vitality.

Therefore, you would think that this analysis is a point of view: When hungry babies should eat cake, if their parents are too busy to keep up, they should completely ignore the baby. It's like a parent network ignores the development of its child network due to poor management.

This is in combination with the collapse of the Rubble and Iranian rials, the current financial collapse in Lebanon, the bankruptcy of Greece and Detroit, the Great Depression of the United States in the last century, and the Bank of England's joining the European currency market The situation is very similar to the case of bankruptcy.

This is the status quo of things, and how they are proposed is no longer important. On the contrary, experience tells us that this proposal is different, probably because of different habits.

From experience, we choose two networks. When BCH forked from Bitcoin, it rose from the lowest $ 50 all the way to a high of $ 5,000. Instead of falling from $ 2,000 to $ 200, Bitcoin has risen to $ 20,000. When Ethereum rose wildly, Bitcoin rose even more. When ETC rises, Ethereum's trend is parabolic.

Therefore, it is not that if a situation occurs, an instantaneous transition occurs. On the contrary, it seems that the gradual exertion of competitiveness has satisfied different stakeholders, thereby increasing the benefits of all stakeholders. This is in contrast to giants fighting on burning houses, because maybe these giants cannot withdraw from the war.

For example, if we compare the ruble to burning down all the houses in the area, you would force the local government to devalue it through sanctions or any mechanism. In the case of Lebanon, the government simply stole the money of the people.

The "mothers" here have no choice, no one asks them, and no one even talks to them. But in the crypto space, they can choose to ignore something, or be slightly more diversified, or even react to events that are in the interest of all asset holders under the joint decision of all asset holders.

Therefore, compared with currency competition between countries, whose feedback is not completely decentralized, competition between different projects seems too mild.

Through this analysis, we have come to the conclusion that crypto projects need to be coordinated in a way that adapts to market feedback / autonomy, which may indicate that the key to measuring whether a project is truly successful is to see if it can successfully centralize and decentralize Find the best balance in the middle.

We will continue to update Blocking; if you have any questions or suggestions, please contact us!