Penta Global’s vision is to become the most popular blockchain platform in the digital economy. The mission of the Penta Universal Connector is to create a global network that interconnects blockchain and blockchain, chain and centralization systems, and chain and chain systems. Based on this goal, we always pay close attention to the new development direction and ideas of the blockchain community, and we hope to make positive contributions in meaningful research areas.
Eitafang’s founder Vitalik recently published an article entitled “A Guide to 99% Fault-Tolerant Consensus Algorithms” that has caused widespread debate. We have published a corresponding view on this topic in Medium, and we hope to stimulate this discussion and stimulate a richer exchange of ideas as a way to promote the in-depth dialogue of the blockchain community.
Developing a consensus mechanism for scalability, security, and high performance is a major challenge for blockchain communities today, and constructive discussions will greatly advance the technology development process.
The article on 99% Fault Tolerance published by Vitalik on August 7 explores the idea of using the Byzantine protocol to achieve a high degree of fault tolerance. For this idea, the Penta team will then come up with ideas that may cause intense controversy within the community. Our discussion revolves around some of the complex issues that Vitalik pays particular attention to, especially the use of some of the key terms involved. We try to explain these related terms more precisely, solve the complex problems that are currently attracting attention, and ask some questions that can be triggered. The community is also invited to participate in fault-tolerant discussions to gain a deeper and clearer understanding of distributed consensus.
The Byzantine agreement has been around for more than 30 years. Some of the earliest solutions were proposed by Lamport, Shostak, and Pease (1980 and 1982), Dolev and Strong (1983), and Fischer, Lynch and Merritt (1986). Even today, there are still many international research groups active in this field. In order to understand the technical background of these papers, we first explain some of the terms and concepts used in the fault tolerance mechanism.
Failure – When the observable behavior of the system (network) deviates from its norm or its intended behavior, it is considered invalid. For example, adding a wrong amount of transactions on a blockchain or allowing a malicious node to add a fake block to a blockchain network. Both are wrong behaviors about network specifications. It may also fail by allowing the formation of a network monopoly control, which is contrary to the idea of a decentralized network. It is worth noting that the incorrect behavior of decentralized networks may be correct for some distributed networks.
Fault – A potential cause of failure. A fault can be a configuration defect, a code defect, a design defect, or another related factor that, when triggered, can cause the system to fail. Some potential failures may have existed for many years before the correct operation trigger
Error – The error is the difference between the actual output and the expected output. An important goal of a fault tolerant system is to ensure that faults are captured, circumvented, or effectively managed before the system fails. Fault tolerance mechanisms are often a means of achieving reliability and availability. Let us look at the formal definition of fault tolerance.s the failure.
Fault Tolerance – If there are m faults in the system and still function properly, the system can tolerate m faults.
Reliability – Technically, reliability is the probability that the system will operate without failure in the specified environment within a specified time. The reliability of the software is usually estimated at the rate of failure per working hour. When the fault is detected and eliminated, the reliability increases accordingly. It is worth noting that reliability is applied to monitor system failures, that is, to measure those observable behaviors of the system, rather than those specific failures that directly cause system failure.
Availability – Depends on reliability, availability is the probability that the system will function as required.
Although there are many different opinions, we assume that the system has four good reliability, which means that the system has a 99.9999% probability that it will not fail within the specified time (probability is 0.999999). For extremely important systems (such as nuclear reactors, airplanes, self-driving vehicles, space stations, etc.), at least 12 9 is required, ie 99.999999999999% reliability (probability is 0.99999999999999).
For example, suppose the blockchain platform has 12 9 reliability and handles about 1 million transactions per second, so we can expect an average failure every 3.2 years. A good system has at least 4 9 availability. In other words, the system performs its functions well in 99.9999% of the time, and only about one hour is unavailable each year. Critical systems often require a higher level of availability.
Early academic papers on Byzantine agreements, such as references , , and , highlighted how to develop a fault-tolerant system. It is worth noting that even if a fault persists or the fault does not fail after being temporarily triggered, in order to achieve four 9 or better system reliability, redundant nodes will still be added to the system and be responsible for Handling of important transactions to prevent failure of one or more network nodes in the system.
A node may fail for a variety of reasons, such as a silent failure (the processor does not work after it reaches its end of life), or the system cannot terminate, permanently generating a stream of constant values or a stream of seemingly random values. Malicious challenges to fault tolerance are also common, including some non-accidental collusion attacks: 51% attack, hard fork attack, double flower attack, witch attack, and DoS attack. This kind of attack can disguise itself like a normal transaction, albeit essentially malicious and abnormal.
Based on the above description of fault tolerance, the 99% fault-tolerant consensus mentioned at the beginning can now be rewritten more succinctly as follows: (1) In a synchronous network composed of n nodes, where m nodes are faulty, if m is less than n One-half of the consensus is possible. However, if m is greater than one-half of n, 51% of attacks may occur; (2) If the observer also actively observes (monitors) the consensus process, it is possible to achieve more than 99% reliability.
Vitalik’s article uses Lamport, Shostak and Pease’s signature message algorithm (which he affectionately calls the SM(m) algorithm ) and improves from two key points: (1) every round of message exchange A specified timeout so that any message arrives after a timeout will be rejected by the node; (2) Observers can participate in the consensus to improve reliability. However, please note that both network nodes and observers may fail (or worse, botnets or other malware infected with the network, see example ).
For critical systems like blockchain transaction processing, we expect to achieve a high reliability of 12-9. Based on this goal, it is generally achieved through two key design combinations: (1) redundancy; (2) “no single point of failure” design. This is exactly what system features that decentralized multipoint replication can bring to us. The combination of redundancy and no single point of failure allows us to ensure that even if a node fails, the transaction book is not lost and consistent.
The next major problem is how to achieve an effective consensus on the real state (storage block) of the chain between distributed nodes in an optimal way in any given time. Vitalik’s article proposes setting a timeout in each of the corresponding rounds in  as a practical way to solve the Byzantine general problem in a more realistic network.
Early studies of implementing Byzantine protocols in utility systems (see Castro and Liskov ) showed that if the message is authenticated, an asynchronous system with n processors can tolerate m equal to one-third of the absolute value of n-1. The opponents exist. However, a large number of message exchanges in the process makes it difficult for early systems to extend to the number of nodes required for blockchain consensus. Current research is seeking and using random algorithms to reach consensus in large networks. How to find an effective consensus optimization in a decentralized blockchain system is a continuing and controversial issue, but our Penta team is keen and always involved.
We hope that this article will help the blockchain community to delve into the basic issues of fault tolerance, while also helping us rethink the assumptions of the Byzantine agreement. Our desire is to trigger further analysis and exploration of the technical issues of the blockchain network consensus model. If we want to make blockchains suitable for real-world scenarios, then scalable solutions that achieve high reliability and high availability are key challenges that must be overcome.
A more difficult issue is how to implement a truly fast, robust consensus model in a decentralized network. Decentralization remains a core principle followed by Penta and blockchain projects. Therefore, our work has always focused on how to successfully implement the technical solution of the decentralized blockchain underlying consensus algorithm.
From the blockchain community, more and more consensus can be reached on consensus algorithms, and we are also looking forward to participating in more dialogue on the evolution of fault tolerance and consensus models.
- ‘A Guide to 99% Fault-Tolerant Consensus’,
Https://vitalik.ca/general/2018/08/07/99_fault_tolerant.html, August 2018.
- ‘The Byzantine Generals Problem’, Leslie Lamport, Robert Shostak, And Marshall Pease, research.microsoft.com/users/lamport/pubs/byz.pdf, July 1982.
‘Authenticated Algorithms For Byzantine Agreement’, Danny Dolev and H. Raymond Strong, SIAM Journal on Computing, 12(4): 656–666, 1983.
‘Easy Impossibility Proofs For Distributed Consensus Problems’, Fischer MJ, Lynch NA and Merritt M, https://doi.org/10.1007/BF01843568, Distrib Comput 1: 26; 1986.
‘Understanding Blockchain Fundamentals, Part 1: Byzantine Fault Tolerance’, Georgios Konstantopoulos, https://medium.com/loom-network/understanding-blockchain-fundamentals-part-1-byzantine-fault-tolerance-245f46fe8419, December 2017 .
‘The Byzantine Generals Problem’, Mark Nelson, https://marknelson.us/posts/2007/07/23/byzantine.html, July 2007.
‘Advanced Blockchain Concepts For Beginners’, Coral Health, https://medium.com/@mycoralhealth/advanced-blockchain-concepts-for-beginners-32887202afad, May 2018.
‘Hacking Blockchains with Smart Contracts to Control a Botnet’ https://www.esecurityplanet.com/hackers/hacking-blockchain-with-smart-contracts-to-control-a-botnet.html, November 2017.
‘Practical Byzantine Fault Tolerance’, Castro, M., and Liskov, B., Proceedings of the Third Symposium on Operating Systems Design and Implementation, New Orleans, USA, February 1999.
[su_quote]This article is writing on 04 September 2018 based on information available online & news portal. If you feel it’s outdated or incorrect, please write here to update it. Mail us: email@example.com Or Whatsapp Us- +13098896258[/su_quote]
The Information Presented Here Does Not Constitute Investment Advice Or An Offer To Invest. The Statements, Views, And Opinions Expressed In This Article Are Solely Those Of The Author/company And Do Not Represent Those Of Coinworldstory. We Strongly Advise Our Readers To Do Your Own Research (DYOR) Before Investing In Any Cryptocurrency, Blockchain Project, Or Ico, Particularly Those That Guarantee Profits. Furthermore, Coinworldstory Does Not Guarantee Or Imply That The Cryptocurrencies Or Projects Published Are Legal In Any Specific Reader’s Location. It Is The Reader’s Responsibility To Know The Laws Regarding Cryptocurrencies And Icos In His Or Her Country. Please Respect Your Country Law & Take Advice From Your Advisor .