Decentralization: a big problem for Blockchain
Hi, Habr! I present to you the translation of the article "Decentralization: The Big Problem For Blockchain".
Decentralization is one of the blockchain technology keywords: companies and websites have emerged that include this word in their name.
')
Decentralization was advertised as the most advanced FINTECH feature. The abbreviation DLT (Decentralized Ledger Technology) has become synonymous with blockchain in the approved Fintech environment.
Few people understand that decentralization itself is a problem, and for many years the blockchain technology has stopped.
Let me explain:
In the 1960s, computer systems were centralized or configured as a star network topology. Only in the early 1970s, the need to connect computers of several manufacturers became urgent.
At that time, the nodes of several existing communication networks were organized hierarchically, but from the very beginning, the protocols implemented in the ARPA, RPCNET, PISA, and other innovative networks that precede the Internet were developed with the general idea that the Central site or authority should control lead, center or own a network.
In other words, we knew that a centralized multi-level star network, with its inherent bottlenecks, could not even satisfy the needs of thousands of users in the 1970s. We also assumed that by reducing the number of bottlenecks as a result of decentralization, the problem will be reduced, but not solved. We knew that the solution should use a distributed peer-to-peer model.
Since many organizations will be involved in providing nodes, channels, and unreliable hardware and software, we assumed the network was unreliable. We did not know how a consistent data set, or even a single transaction, can be maintained in several databases through an unreliable network, when any node can generate a message, or in fintech terminology, a financial transaction. The problem was further aggravated by the presence of malicious players.
In general, we recognize that a network is decentralized when network management is shared by a subset of network nodes.
A network is distributed when all nodes share responsibilities equally and run the same node software.
Decentralized (allowed and leader-based) networks were often extensions of centralized networks arising from application requirements, for example, in the FINTECH industry.
Network blockchain software (basic system software) should not be designed to meet the requirements of the application, as they will change. We did not design network predecessors of the Internet and the Internet itself, based only on the requirements of the applications of the 1970s. We could not predict which industries will evolve based on the ability to share information on a global scale.
Similarly, the blockchain core network should be as general, flexible and scalable as possible. Permissions, client-server and private network requirements can then be considered as special cases of a distributed network, for example, using the concept of virtual private (blockchain) networks.
Distributed networks are more likely not to depend on any particular physical structure. Nodes can be dynamically connected to each other, and random connection procedures can be used. Consensus solutions implemented in distributed networks may also be invalid, majority-controlled and recursive.
Distribution, not decentralization, should have been the main goal of designing crypto networks.
The inability to investigate agreements on distributed consensus is partly due to the formulation of the problem of Byzantine generals in 1982, which models how to maintain the integrity of information in an unreliable environment. The problem of the Byzantine generals has been studied by researchers for more than thirty years.
The analogy of several allied army divisions holding the besieged city suggested that no one on the field could be trusted to deliver the message, and that some of the generals themselves could not be trusted when issuing a command.
However, the wording of the army analogy assumed the existence of at least two classes of troops: generals and soldiers.
Then some people limited their thinking to a more specific case, when the generals gave commands that needed to be passed on to other generals, as well as protected from interference by intruders or traitors.
In the end, this approach led to a limited definition of the problem of consensus.
Leadership-based consensus models, such as Paxos and Raft, were taught at universities and used as models by blockchain network developers.
As a result, practical solutions to the problem of the Byzantine generals focused on various methods of selecting a leader node that would send a block of verified information to all other nodes instead of trying to reach consensus on the content of the block.
Consensus on which node should be the current leader does not solve the problem of trust. The current leader must be trusted. He must do the work of checking and assembling the blocks in a fair manner.
Thus, based on current consensus protocols, the leader must provide some authority: proof of work, proof of stake, proof of ability or proof of anything else.
These “proofs” do not guarantee nothing more than the personal interest that leader nodes (or nodes aspiring to be leader nodes) in a network may have: the more percent they acquire, the less they will be ready to destroy their form of income.
These “proofs” ensure that potential leaders have authority, but do not guarantee that the information gathered in the block is correct, or that it has been verified by most of the nodes.
We saw more than 60 proposed solutions based on leadership models for various blockchain implementations. They suffer from a common error: one node decides what each other node in the blockchain will store. The result is almost the opposite of what is required.
Leader-based protocols have the following disadvantages:
Reflecting on the analogy with the problem of achieving a common solution in an unorganized and unreliable environment, we could use the analogy of an army without ranks, but it would not be very intuitive.
The best analogy would be to determine the daily closing price on the stock exchange. By this analogy, many buyers and sellers determine the daily closing price of stocks using a stochastic process, without any particular person making a decision for anyone else.
There is no “correct” answer to the stock price on the stock market, but only the agreed daily closing price.
Similarly, within a block, several variables, such as the order of transactions, may determine the final composition of the block. There is no “right” composition of blocks, only one with which the nodes agree.
Consensus protocols based on a more distributed analogy could have avoided the tendency towards centralization and the need for intermediate nodes typical of leader-based protocols.
Examples of online brokers:
First of all, it is a question of cost: if intermediaries perform useful work, for example, they check transactions, they should be rewarded.
It is also a matter of trust: customers using reseller network must trust:
Finally, it is a matter of data availability. If the network has a privileged or restricted class of nodes that control blockchain, then most nodes do not have instant access to the current blockchain replica. This may interfere with the development of real-time applications, such as automated trading applications.
Most experts will tell you that the main function of the agreed protocols is to maintain network security. This view mixes two problems. Security is necessary, but it is a completely different requirement that can be solved in other ways.
However, many developers adhere to the idea that consensus means choosing a leader, and that consensus is necessary to maintain security.
Looking back, if we thought about a better distributed analogy, the study could go in a different direction, offering stochastic approaches, and could lead us to an earlier development, better distributed solutions without intermediaries.
Now this is a problem of education, not a technical problem. Most researchers, consultants and experts on crypto networks, own all the details of PoW, PoS, DPoS and several dozen alternatives based on the same model based on the leaders.
Those few solutions that are not based on leaders are not blockchain solutions: these are solutions where each transaction is processed separately.
On the other hand, most people and 95% of companies, according to a recent survey, understand the potential of blockchain technology.
The transition from a decentralized to a distributed model is urgently needed to unlock the true potential of the blockchain, solve scalability problems, and run the blockchain on any user device without intermediaries.
Decentralization is one of the blockchain technology keywords: companies and websites have emerged that include this word in their name.
')
Decentralization was advertised as the most advanced FINTECH feature. The abbreviation DLT (Decentralized Ledger Technology) has become synonymous with blockchain in the approved Fintech environment.
Few people understand that decentralization itself is a problem, and for many years the blockchain technology has stopped.
Let me explain:
In the 1960s, computer systems were centralized or configured as a star network topology. Only in the early 1970s, the need to connect computers of several manufacturers became urgent.
At that time, the nodes of several existing communication networks were organized hierarchically, but from the very beginning, the protocols implemented in the ARPA, RPCNET, PISA, and other innovative networks that precede the Internet were developed with the general idea that the Central site or authority should control lead, center or own a network.
In other words, we knew that a centralized multi-level star network, with its inherent bottlenecks, could not even satisfy the needs of thousands of users in the 1970s. We also assumed that by reducing the number of bottlenecks as a result of decentralization, the problem will be reduced, but not solved. We knew that the solution should use a distributed peer-to-peer model.
Since many organizations will be involved in providing nodes, channels, and unreliable hardware and software, we assumed the network was unreliable. We did not know how a consistent data set, or even a single transaction, can be maintained in several databases through an unreliable network, when any node can generate a message, or in fintech terminology, a financial transaction. The problem was further aggravated by the presence of malicious players.
Why blockchain technology impedes decentralization
In general, we recognize that a network is decentralized when network management is shared by a subset of network nodes.
A network is distributed when all nodes share responsibilities equally and run the same node software.
Decentralized (allowed and leader-based) networks were often extensions of centralized networks arising from application requirements, for example, in the FINTECH industry.
Network blockchain software (basic system software) should not be designed to meet the requirements of the application, as they will change. We did not design network predecessors of the Internet and the Internet itself, based only on the requirements of the applications of the 1970s. We could not predict which industries will evolve based on the ability to share information on a global scale.
Similarly, the blockchain core network should be as general, flexible and scalable as possible. Permissions, client-server and private network requirements can then be considered as special cases of a distributed network, for example, using the concept of virtual private (blockchain) networks.
Distributed networks are more likely not to depend on any particular physical structure. Nodes can be dynamically connected to each other, and random connection procedures can be used. Consensus solutions implemented in distributed networks may also be invalid, majority-controlled and recursive.
Distribution, not decentralization, should have been the main goal of designing crypto networks.
Why did we fail
The inability to investigate agreements on distributed consensus is partly due to the formulation of the problem of Byzantine generals in 1982, which models how to maintain the integrity of information in an unreliable environment. The problem of the Byzantine generals has been studied by researchers for more than thirty years.
The analogy of several allied army divisions holding the besieged city suggested that no one on the field could be trusted to deliver the message, and that some of the generals themselves could not be trusted when issuing a command.
However, the wording of the army analogy assumed the existence of at least two classes of troops: generals and soldiers.
Then some people limited their thinking to a more specific case, when the generals gave commands that needed to be passed on to other generals, as well as protected from interference by intruders or traitors.
In the end, this approach led to a limited definition of the problem of consensus.
Leadership-based consensus models, such as Paxos and Raft, were taught at universities and used as models by blockchain network developers.
As a result, practical solutions to the problem of the Byzantine generals focused on various methods of selecting a leader node that would send a block of verified information to all other nodes instead of trying to reach consensus on the content of the block.
Missing target
Consensus on which node should be the current leader does not solve the problem of trust. The current leader must be trusted. He must do the work of checking and assembling the blocks in a fair manner.
Thus, based on current consensus protocols, the leader must provide some authority: proof of work, proof of stake, proof of ability or proof of anything else.
These “proofs” do not guarantee nothing more than the personal interest that leader nodes (or nodes aspiring to be leader nodes) in a network may have: the more percent they acquire, the less they will be ready to destroy their form of income.
These “proofs” ensure that potential leaders have authority, but do not guarantee that the information gathered in the block is correct, or that it has been verified by most of the nodes.
We saw more than 60 proposed solutions based on leadership models for various blockchain implementations. They suffer from a common error: one node decides what each other node in the blockchain will store. The result is almost the opposite of what is required.
Summary of deficiencies of leader-based protocols
Leader-based protocols have the following disadvantages:
- They do not solve the problem of trust. The leader node may enter erroneous data, intentionally or not, into a block of information.
- The rewards associated with the work of checking and assembling the blocks create an incentive for the nodes to compete for the rewards and advance to leadership positions. This incentive tends to create a special class of nodes. The network is becoming a decentralized network. For example, Bitcoin began as a network of partners, where each node could check transactions and fight for a reward. Today it is a network of two classes (miners and users), which is managed by the owners of large pools.
- When a block assembly is transferred to a single node, one of the basic requirements of the consensus theory becomes invalid: the agreement is not based on the majority consensus on what information will be stored in the blockchain. The only agreement reached is the method of selecting a leader node.
- A bottleneck, or a single point of failure, is introduced: one node must translate the block to every other node.
- Efficiency is not the best: large data blocks are more susceptible to transmission errors and retransmission of packets of maximum size.
- The redundancy is almost 100%: each transaction included in the block has already been received by each node separately when the transaction was initially completed.
Best analogy
Reflecting on the analogy with the problem of achieving a common solution in an unorganized and unreliable environment, we could use the analogy of an army without ranks, but it would not be very intuitive.
The best analogy would be to determine the daily closing price on the stock exchange. By this analogy, many buyers and sellers determine the daily closing price of stocks using a stochastic process, without any particular person making a decision for anyone else.
There is no “correct” answer to the stock price on the stock market, but only the agreed daily closing price.
Similarly, within a block, several variables, such as the order of transactions, may determine the final composition of the block. There is no “right” composition of blocks, only one with which the nodes agree.
Consensus protocols based on a more distributed analogy could have avoided the tendency towards centralization and the need for intermediate nodes typical of leader-based protocols.
Examples of online brokers:
- Miners, manufacturers or controllers who voluntarily participate or are involved in the provision of network services,
- Special nodes of federated systems that are interested in network success,
- Nodes selected with some criteria for network management
- Nodes owned by trusted companies or institutions
- Special players, such as centralized currency exchanges, owning users' wallets.
What is wrong with intermediaries?
First of all, it is a question of cost: if intermediaries perform useful work, for example, they check transactions, they should be rewarded.
It is also a matter of trust: customers using reseller network must trust:
- That the intermediary does not give preference to certain users or transactions,
- That the mediator was not or will not be captured by the attacker,
- That the broker system does not shut down, is not exposed to a DoS attack, system failure, or any other reason that will affect or delay client transactions,
- System software and data brokers are reliable, therefore the integrity and security of data is guaranteed.
- That they are really connected with a trusted system, and not with an imitator (for example, with some other system claiming to be a trusted intermediary), and
- That no other unpredictable event will occur. Recently, for example, the owner of the Canadian currency exchange Quadriga has died or disappeared. As a result, millions of dollars in customer funds are missing.
Finally, it is a matter of data availability. If the network has a privileged or restricted class of nodes that control blockchain, then most nodes do not have instant access to the current blockchain replica. This may interfere with the development of real-time applications, such as automated trading applications.
Is it too late to change the consensus model in the blockchain?
Most experts will tell you that the main function of the agreed protocols is to maintain network security. This view mixes two problems. Security is necessary, but it is a completely different requirement that can be solved in other ways.
However, many developers adhere to the idea that consensus means choosing a leader, and that consensus is necessary to maintain security.
Looking back, if we thought about a better distributed analogy, the study could go in a different direction, offering stochastic approaches, and could lead us to an earlier development, better distributed solutions without intermediaries.
Now this is a problem of education, not a technical problem. Most researchers, consultants and experts on crypto networks, own all the details of PoW, PoS, DPoS and several dozen alternatives based on the same model based on the leaders.
Those few solutions that are not based on leaders are not blockchain solutions: these are solutions where each transaction is processed separately.
On the other hand, most people and 95% of companies, according to a recent survey, understand the potential of blockchain technology.
The transition from a decentralized to a distributed model is urgently needed to unlock the true potential of the blockchain, solve scalability problems, and run the blockchain on any user device without intermediaries.
Source: https://habr.com/ru/post/447108/
All Articles