Viewpoint | Chinese cryptographer Wang Yongge: Byzantine consensus can no longer meet the security needs of today's public and alliance chains

Author: Wang Yongge

Source: block rhythm

Since Facebook launched Libra's white paper on the alliance chain and sought to gradually transition to the public chain after five years, many people in the blockchain community have had a very effective discussion on the differences and similarities between the alliance chain and the public chain. The industry has given some perspectives on some of the security concerns of the current public and alliance chains.

In simple terms, a coalition chain is a licensed blockchain, and only a few licensed nodes can determine the generation of the next block. The permissionless is an open system, and all nodes have the opportunity to generate the next node. Therefore, from the perspective of governance mechanism, the difference between the two chains is obvious. If you do not consider from the perspective of security, the application scenarios of the two chains should not be very different. The application scenarios that can be developed on the federated chain can also be used naturally as application scenarios on the public chain, and vice versa.

• Shanghai launches virtual currency transaction investigation and rectification actions; Zhejiang strives to develop blockchain leader
• Google entered the banking industry with a new attitude of "bitcoin killer", and bitcoin was threatened again?
• Will the miners escape the tide and the bitcoin price will peak again?

Today, we mainly discuss the difference between the two chain governance mechanisms. Why, under the current technical support, not all the application scenarios of the alliance chain can be used as the application scenario of the public chain. At the same time, I also tried to explain why Facebook did not launch Libra based on the public chain from the beginning. In the alliance chain, the voting rights are subject to review and the voting rights can be recovered. Therefore, the alliance chain has not reached a complete decentralization. However, due to the existence of such a review and approval mechanism, there is a certain competitive relationship between the voting nodes, but they cannot fully trust each other, but the relationship between them is not completely distrust.

In the study of cryptography, we generally use a semi-trust threat model to express this relationship. On the public chain, any node has the opportunity to participate equally in the generation of the next block. In order to maximize the respective interests, there is no trust relationship between the voting nodes. In cryptography research, we use the Byzantine threat model to express this relationship.

Neglected consensus mechanism threat model

The consensus agreement is the core technology of the blockchain. The consensus agreement determines how the next block is generated. Put another way, the consensus agreement determines a complete ordering of all transactions for the entire system. And this sorting must be a consensus among all honest participants in the system.

In real life, if we can't reach a consensus on the order of the two transactions, then we can't trust the whole system. If a dishonest blockchain node (whether or not it has voting rights) can attack this sorting in some way, it will produce immeasurable and catastrophic results, the most typical example of which is "double flower attack". This attack pattern has occurred on blockchains such as Zencash, Ethereum Classic, and Bitcoin Gold.

A safe and reliable blockchain consensus agreement should satisfy the following two conditions:

1. Safety: An honest node will reach a consensus opinion on legal transactions.

2. Liveness: A legal transaction will be confirmed within a reasonable length of time.

The Bitcoin consensus protocol is a workload-based PoW system. Due to the many challenges in the PoW system, the consensus in the community is that we will gradually promote a consensus agreement based on Proof of Stake ("PoS"). The PoS consensus protocol was first used in the blockchain Peercoin.

In the current PoS consensus protocol, a participant must meet certain conditions to be able to generate the next block. In many cases, multiple participants may meet these conditions. These satisfied participants will go to the next block. Because the block generator gets a lot of benefits, each block generator wants the block that it generates to be the one that is accepted by everyone. If the blockchain system allows two participants to simultaneously generate the next block, then a blockchain fork will occur.

In order to avoid the fork of the blockchain, whether it is a coalition chain or a public chain, the Byzantine protocol is generally used to select the next acceptable block from among these candidate blocks. This involves a lot of core issues:

1. What conditions does a participant meet to generate the next block?

2. How many people know his identity before a participant announces that he has the right to generate the next block?

3. How is the Byzantine agreement carried out?

4. Wait.

In different threat models, the solution to each of the above problems is different. As we mentioned above, the alliance chain uses a semi-trust threat model, while the public chain uses the Byzantine threat model. Because the secure and reliable application scenarios in the semi-trust threat model are not necessarily safe and reliable in the Byzantine threat model, not all application scenarios of the alliance chain can have corresponding public chain application scenarios.

In general, when developers develop application scenarios, they must consider which application scenarios are safe in what threat model . In addition, we also need to specifically consider whether our application scenario can run on a specific alliance chain or public chain? Although it is said earlier, the assumption of the alliance chain is a semi-trust threat model, which does not mean that all alliance chains are safe and reliable in the semi-trust threat model. Similarly, we talked about the need for the public chain to be safe and reliable in the Byzantine threat model, but it does not mean that all public chains in the market are safe and reliable in the Byzantine threat model.

Read this, you may ask: How many public chains on the market can be completely safe in the Byzantine threat model? Of course, everyone will ask: Does our current public chain have enough technical support to ensure that it is completely safe in the Byzantine threat model? We try to answer these questions in this and subsequent series.

When you can guess who is coming out of the next block, it’s horrible!

Let's start with a very basic example to illustrate the gap between ideal and reality: in a PoS-based coalition chain or public chain, if the next block is generated, you can predict that the next block will be specific to a particular block. Participant A is generated , then this blockchain system will be vulnerable to attack. This situation has occurred several times in the EOSIO – Blockchain software architecture blockchain. The blacklist mechanism of the EOS system and the super-node sequential block-out mechanism allow hackers to easily complete transactions during the blackout of some blacklisted nodes.

For example, some participants or non-participants may bribe A to exclude certain transactions from the next block . In addition, if both participants A and B satisfy the generation condition of the next block, A may initiate a DoS attack on B's network, so that B cannot publish the block it generates. The result is likely to be that the block of A is accepted by everyone. So in an ideal blockchain system, participants want their producer identity to be unpredictable until the next block is generated . But many blockchain systems on the market have not fulfilled our ideals. Perhaps in the semi-trust threat model adopted by the alliance chain, the predictability of the identity of the next block generator can be "accepted".

But in the Byzantine model used in the public chain, this predictability is absolutely unacceptable . In some current public chains, some systems (such as Algorand ) use a verifiable random number generator (VRF) to ensure the unpredictability of the identity of the next block generator. Other public chains (such as Sperax ) use tamper-resistant hardware systems to ensure the unpredictability of the identity of the next block generator. So everyone is analyzing whether a chain is safe and reliable. First of all, we should analyze where the random number of the system comes from and whether it is safe. Although most of the federation chains do not use enough random numbers, we believe that even in the semi-trust threat model, we still need to ensure the unpredictability of the identity of the next block generator. As an exercise, readers can analyze all the blockchains on the market to see if they can meet this basic condition.

Another important core question is whether the Byzantine protocol currently used by people is still safe in an Internet-based network environment. The Byzantine agreement is an old topic. Byzantine (present-day Istanbul), the capital of the Roman Empire more than 2,000 years ago, the various forces of the Roman Empire were separated far apart, and the generals and the generals could only rely on messenger to transmit news. The generals of the Imperial Army must unanimously decide whether to attack a certain enemy. But there are traitors in the general. The traitor can take any means to prevent the loyal generals from reaching a unanimous decision.

In order to solve the problem of coordination between servers in distributed computing, Turing Award winner Lamport and his collaborators introduced the Byzantine protocol issue to computer science around 1982. Since then, a series of distributed consensus protocols have been designed and widely used (such as Rampart and SecureRing). These protocols are mainly used in relatively closed environments (such as data centers), so they all have strong assumptions. In particular, many Byzantine agreements use the following two assumptions:

1. The communication network used by the Byzantine protocol is a complete graph. Put another way, there is a safe point-to-point communication channel between all participants in the Byzantine agreement. This assumption is difficult to achieve for the alliance chain. For a completely open public chain, we doubt that this assumption is still true.

2. The communication network used by the Byzantine protocol is a synchronous network . That is, there is a global variable △. The message sent by each protocol participant at time t must arrive at the receiving node before t+ △.

These two assumptions are relatively easy to achieve for a relatively closed environment. But for an open network, this assumption is obviously unrealistic . For example, on the Internet we use, DoS attacks are easy to deploy. So even the Internet-based federation chain does not use the assumptions above. In general, the Internet is an asynchronous network, and the commonly used asynchronous network is characterized by the following model:

• There is a Global Stabilization Time (GST), and any messages may be lost (such as DoS attacks) or reordered before GST. After GST, the network becomes synchronous. When the GST starts, no one knows.

Therefore, the Byzantine protocol required by our blockchain must be robust to asynchronous networks that can lose a lot of information. Many of the most used Byzantine protocols in the blockchain currently on the market are the Turing Award winner BARBARA LISKOV and her student-designed PBFT (practical BFT) and its variants (such as Tendermint BFT).

The Byzantine agreement does not guarantee that the blockchain system is safe and reliable.

So the question we care about is: Are these Byzantine protocols designed for asynchronous networks safe and reliable for blockchain applications? In particular, are these Byzantine protocols secure in an Internet-based network environment? If these Byzantine agreements fail to achieve security in the Byzantine threat model, it is hard to imagine that everyone will trust the services provided by these blockchain systems.

If we carefully analyze these Byzantine agreements, we will find that they all have a basic assumption: there is a secure broadcasting protocol for the communication network used by Byzantium.

• If a node broadcasts a message m at time t, all nodes will receive the same message m before t+ △

However, we know that in the Internet environment, DoS (Denial of Service) attacks can make certain nodes not accept messages sent by broadcasters. In particular , DoS is allowed before the GST moment of an asynchronous network . So the broadcast protocol is not secure before the GST moment of the asynchronous network. Our conclusion is: If a DoS attack is possible, then we can't guarantee that the Byzantine protocol used by many blockchains today is safe.

With curiosity, you may be wondering how the current blockchain system implements the broadcast protocol. Most of the broadcast protocols are based on the following paper published by Bracha in 1987:

• G. Bracha. "Asynchronous Byzantine agreement protocols." Information and Computation 75.2 (1987): 130-143.

But unfortunately, Bracha's paper has a hypothesis that is often overlooked:

• If Bracha's broadcast protocol is to be secure, its communication network must have a bit of reliable communication channels.

The problem lies in this assumption. Because reliable peer-to-peer communication channels are required, DoS attacks should not be allowed. In addition, to ensure reliable peer-to-peer communication channels in the network, the network needs to have sufficient connectivity. You can refer to the following article on the relationship between reliable peer-to-peer communication channels and network connectivity:

• Y. Wang and Y. Desmedt. Perfectly secure message transmission revisited. Information Theory, IEEE Tran., 54(6): 2582–2595, 2008

Based on the above discussion, it is easy to conclude that the Byzantine protocols currently used in many blockchain systems (the alliance chain and the public chain) are not guaranteed to be secure in an Internet-based network environment. We will analyze in each of the following articles one by one whether the Byzantine protocols currently used in the alliance chain and the public chain are safe in an Internet-based network environment.

If the Byzantine protocols used by these blockchain systems do not achieve the security of the Byzantine threat model, it is hard to imagine that everyone will trust the services provided by these blockchain systems.

To sum up: We believe that the security of the blockchain system that has been developed so far has not been adequately analyzed. So we can't confirm which application scenarios can run on the federation chain or the public chain. Our research on the security of blockchain systems is still at a very early stage. Just like our understanding of Internet security research in the 1980s.

In 1988, a caterpillar Morris worm written by a MIT graduate student infected 10% of the world's computers at the time. This puts the entire world's Internet system in a state of paralysis. If we do not have enough research and preparation for the security of the blockchain system, this caterpillar attack is likely to be staged on the blockchain system. We will introduce our research to everyone in the series of articles in the next few months! Please pay attention to everyone.

about the author

Professor Wang Yongge, chief scientist of Sperax, famous Chinese cryptographer, tenured professor of computer science at the University of North Carolina at Charlotte (UNC, Charlotte), and Ph.D. from the University of Heidelberg, Germany. Professor Wang has published more than 100 academic papers on computational complexity theory, cryptography (encryption, decryption and cryptanalysis), fault-tolerant computing, distributed computing, infrastructure protection, secure communications, computer and network security, and cloud. Security, information theory and post-quantum cryptography. Professor Wang participates in standards organizations such as IETF, W3C, XML Security Protocol, IEEE 1363 Encryption Technology Standardization Group and SAN Network Security Standard ANSI T11 Team.

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