фото показано с : cryptobriefing.com

Decentralization is one of the buzzwords of blockchain technology: companies and web sites have sprung up that include this word as part of their name.

Decentralization has been touted as a most advanced feature in fintech. The acronym DLT (Decentralized Ledger Technology) has become a synonym for blockchain in the fintech permissioned environment.

Few realize that decentralization is itself the problem, and has kept blockchain technology stalled for many years.

Let me explain:

In the 1960s, computer systems were centralized, or configured as a star network. Only in the early 1970s did the need to connect computers from multiple manufacturers become urgent.

At the time, the nodes of the few existing communication networks were typically organized hierarchically, but from the very beginning the protocols implemented in the nodes of the ARPA, RPCNET, PISA and other groundbreaker networks preceding the internet were designed with the general idea that no central node or authority should control, lead, be the center of, or own the network.

In other words, we knew that a centralized, star, multi-tier network, with its innate bottlenecks, was not going to satisfy even the 1970’s requirements of thousands of users. We also guessed that by reducing the number of bottlenecks through decentralization the problem would be reduced, but not solved. We knew that a solution would have to use a distributed, peer-to-peer model.

Since many organizations would be involved in the provision of nodes, links, and possibly-unreliable hardware and software, we had to assume that the network was unreliable. We did not know how a consistent set of data, or even a single transaction, could be maintained in multiple databases through an unreliable network when any node could generate a message or, in fintech terminology, a financial transaction. The problem was further compounded by the presence of deliberately malicious players.

In general terms, we recognize that a network is decentralized when the control of the network is shared among a subset of the network’s nodes.

A network is distributed when all nodes equally share responsibilities and run the same node software.

Decentralized (permissioned and leader-based) networks were often extensions of centralized networks deriving from application requirements, for example by the fintech industry.

The blockchain network software (basic system software) should not be designed according to application requirements, as these will change. We did not design the network precursors of the Internet and the Internet itself based only on the requirements of 1970’s applications. We could not have predicted what industries would develop based on the ability to share information globally.

In the same way, the underlying blockchain network should be as general, flexible and scalable as possible. The permissioned, client-server, and private network requirements can then be considered as special cases of a distributed network, for example by using the concept of Virtual Private (blockchain) Networks.

Distributed networks are more likely to be independent of any specific physical structure. Nodes can dynamically connect to each other and random connection procedures could possibly be used. Consensus solutions implemented on distributed networks can also be unpermissioned, majority- driven and recursive.

Distribution, not decentralization, should have been the main objective of crypto-network design.

The failure to investigate distributed consensus agreements partly derives from the 1982 formulation of the Byzantine Generals problem, which models how information integrity can be maintained in an unreliable environment. The Byzantine Generals problem has been studied by researchers for over thirty years.

The analogy of several allied army divisions holding a city under siege correctly assumed that no-one in the field could be trusted to deliver a message and that some of the generals themselves could not be trusted when issuing a command.

However, the formulation of the army analogy suggested at least two classes of troops: generals and soldiers.

Some people then restricted their thinking to a more specific case in which the generals issued commands that needed to be both carried to other generals and protected from tampering by attackers or traitors.

Eventually, this approach led to a limited definition of the consensus problem.

Leader-based consensus models such as Paxos and Raft were and taught in universities and adopted as models by designers of implementations of blockchain networks.

As a result, practical solutions of the Byzantine Generals problem focused on various methods for selecting a leader node, which would send a block of verified information to all other nodes, instead of seeking to achieve a consensus on the content of the block.

A consensus on which node should be the current leader does not solve the problem of trust. The current leader must be trusted. It must do the job of verifying and assembling blocks in a fair manner. Thus, the leader in current leader-based consensus protocols is required to provide some credentials: proof of work, proof of stake, proof of capacity or proof of anything else.

These “proofs” do not guarantee much more than a vested interest that leader nodes (or nodes aspiring to be leader nodes) may have in the network: the more interest they acquire, the less they will be willing to destroy their form of income.

These “proofs” guarantee that potential leaders have credentials, but do not guarantee that the information assembled in the block is correct, or at least that it has been verified by a majority of the nodes.

We have seen more than 60 proposed solutions based on leader-based models for various blockchain implementations. They suffer from a common fault: one node decides what every other node will store on the blockchain. The result is almost the opposite of what is required.

Leader-based protocols have the following disadvantages:

When thinking about an analogy for the problem of reaching a common decision in an unorganized and unreliable environment, we could have used an analogy of an army without ranks, but it would not have been very intuitive.

A better analogy could have been the challenge of deciding the daily closing price on a stock exchange. In this analogy, a multitude of buyers and sellers determines the daily closing price of stocks using a stochastic process, without any particular person taking a decision for anyone else.

In the stock market there is no “right” answer for a stock price, just an agreed daily closing price.

Similarly, in the composition of a block several variables, such as the order of the transactions, can determine the final block composition. There is no “right” block composition, just one that nodes agree on.

Consensus protocols based on a more distributed analogy could have avoided the tendency towards centralization and the requirement of intermediate nodes, typical of leader-based protocols.

Examples of intermediaries in a network are:

First of all, it is a question of cost: If the intermediaries are doing useful work, for example verifying transactions, then they need to be rewarded.

It is also a question of trust: customers using a network with intermediaries need to trust:

Finally, it is a question of data availability. If a network has a privileged or restricted class of nodes managing the blockchain, then the majority of nodes do not have immediate access to the current replica of the blockchain. This may preclude the development of real-time applications, such as automated trading applications.

Most experts will tell you that a major function of consensus protocols is to maintain the security of the network. This view confuses two issues. Security is certainly needed, but it is a completely different requirement that can be solved by other means.

Still, many developers are stuck with the ideas that consensus means choosing a leader and that consensus is needed to maintain security.

With hindsight, if we had thought of a better distributed analogy, the research could have turned towards a different direction, suggesting stochastic approaches and possibly could have led us to the earlier development of better distributed solutions without intermediaries.

This is now an education issue, more than a technical issue. Most researchers, consultants and experts on crypto-networks are proficient in all the details of PoW, PoS, DPoS and several dozen alternatives, all based on the same leader-based model.

The few solutions that are not leader-based, are not blockchain solutions: they are solutions in which each transaction is handled separately.

On the positive side, most people and 95% of companies, according to a recent poll, understand the potential of blockchain technology.

A transition from a decentralized to a distributed model is urgently required to unlock the blockchain’s true potential, to solve the problems of scalability and to run the blockchain on any user device without intermediaries.

The author is the CEO of Gorbyte, a blockchain research, development and innovation company. Crypto Briefing does not accept any payment or financial benefit from expert guest authors.

If you are a blockchain expert with an interest in sharing your knowledge and experience, please contact our Managing Editor, Jon Rice, via email at editor AT cryptobriefing.com

The post Decentralization: The Big Problem For Blockchain appeared first on Crypto Briefing.

Similar to Notcoin - Blum - Airdrops In 2024

origin »

274 +