Before the beginning
A large number of tasks related to data science constantly arise around the topic of blockchain. Today, many Web 3.0 projects have started and continue to develop, directly related to decentralization tools. Developing applications inside the blockchain, most of which are increasingly moving away from the cryptocurrency topic, is gradually becoming a trivial task for various companies. In addition, recently blockchain has increasingly been linked to the topic of artificial intelligence. That is not accidental, since it is already obvious that the synergy of blockchain and artificial intelligence represents a very interesting direction in the development of Web 3.0.
Practice has shown that the development and maintenance of Web 3.0 projects occurs much faster and more efficiently if the development life cycle process is managed by the DevOps methodology. Participants in this process are DevOps engineers – the specialists who are well versed in both programming and administration. However, not every company has such specialists in its structure and, accordingly, DevOps tools remain outside the scope of its attention. Such collision is not inherent in processes performed by a team of professionals at https://dysnix.com/. Their work and level of competence are guaranteed to assure that any Web 3.0 projects meet the requirements of the modern market.
From Byzantium to decentralization
The creation of decentralized, distributed, highly reliable systems has its origins from an unusual but landmark work by Leslie Lamport called “The Byzantine Generals’ Problem.” At its core, the problem is quite simple to understand, but quite complex to solve. Lamport’s article was published in the early eighties of the last century. It invited readers to plunge into the atmosphere of the Byzantine Empire of the 6th century AD and imagine a group of Byzantine generals who did not have a single military leader and were not subordinate to each other. The generals are faced with the task of conducting a military operation against a certain besieged city. The generals must come to some kind of unified decision – to jointly attack the city in order to take it, or to retreat together in order to save the lives of the soldiers. The generals have a significant problem – they do not have a reliable channel for mutual communication, and they transmit all messages using couriers. However, there is a high probability that couriers could be intercepted by the enemy, and real messages could be replaced with fake ones. As a result, the generals cannot be sure of the veracity of the messages received, or even of the very fact that they were sent from the true source. In addition, there may be traitors among the generals themselves who are not interested in the overall optimal solution.
This example is a classic illustration of a technical system in which there are several components that perform general backup, while some components may be subject to failure. Failures include both cases when the component simply turns off, and situations in which the component continues to work, but at the same time generates arbitrary messages that are perceived as normal. When developing the first blockchain project, Bitcoin, a solution was proposed that did not exist before. The so-called consensus protocol was introduced into the asset exchange processes of the blockchain network. This consensus protocol is quite simple; its essence lies in the fact that the longest one is selected from all existing options for blockchain chains. In other words, the chain for which the greatest amount of work was completed is selected. Each participant in the blockchain tries to mine his own block, and if he finds it before other participants, he releases it into the network. Accordingly, other participants in the network see the longest chain and join in the release of a new block for this chain. As you can see, the algorithm of actions is very simple: the longest chain is selected, transactions are collected together, a new block is mined and sent to the network. If a participant sees a longer chain, he switches to it. With this algorithm, there is no connection to the number of participants and the need to register participants in advance; the network is automatically configured.
Byzantine Fault Tolerance
Let’s return to the problem of the Byzantine generals and extrapolate it to our blockchain network. Byzantine generals, as participants in the protocol, exchange messages, and there is no limit on the delivery time of these messages, but there is a possibility of losing some message and the possibility of some participants being traitors (malicious nodes). The logic of the problem states that if there are no malicious nodes less than one third of all participants, then the protocol will not be able to come to any reliable solution. In this case, the order of operation of the blockchain network will be determined by BFT protocols (Byzantine Fault Tolerance). For these protocols:
– no central trusted party,
– nodes interact with each other equally,
– some nodes are malicious,
– the network may delay messages,
– messages may be lost,
– each honest node in a finite number of message exchanges comes to the same final state as all other honest participants,
– there should be more than two-thirds of honest participants of the total number.