Shulou(Shulou.com)06/01 Report--

The purpose of this article is to share with you about how Conflux optimizes the efficiency of bandwidth use. The editor thinks it is very practical, so I share it with you. I hope you can get something after reading this article.

The early blockchain systems tend to have low throughput and low bandwidth requirements, and the consensus protocol itself is the bottleneck of their performance. Bitcoin networks, for example, generate only 1MB-sized blocks every 10 minutes, which is almost negligible in today's broadband network environment.

In recent years, with the development and maturity of new generation block chains such as Conflux, the throughput of block chains has made a qualitative leap, and network bandwidth has increasingly become a bottleneck to limit the further improvement of the performance of block chains. This time, let's talk about how Conflux optimizes bandwidth efficiency.

The deal broadcast is the first step towards reaching a consensus on the blockchain. Whenever a user initiates a transaction, the transaction is sent to one or more full nodes from the client program. After that, the transaction between the whole nodes is forwarded to their neighbor nodes through the peer-to-peer network, until finally all the nodes receive the transaction.

The greater the throughput of the blockchain, the more transactions each node needs to forward. Therefore, when the throughput and network bandwidth of the blockchain are of the same order of magnitude, the bandwidth utilization of the transaction forwarding process will directly affect the final throughput performance of the whole blockchain system.

Let's first look at the simplest scenario: whenever an all-node receives a new transaction, the all-node sends the transaction to all its neighbors.

According to the above scheme, each node will receive the same transaction from different neighbor nodes many times, which means that both the sending and receiving of the transaction have multiple redundancy, and the utilization of network bandwidth is naturally very low. Take a 200-byte transaction, for example, if each node has eight neighbors, then the transaction will bring about the amount of 1.6kB sent and the amount of 1.6kB received for each full node-and most of that traffic is wasted.

Even Bitcoin, as a system with a throughput of only 7 calls per second and bandwidth utilization of transaction forwarding does not constitute a performance bottleneck at all, no longer uses the above unoptimized scheme.

Bitcoin's solution is that when a Bitcoin node A first receives the transaction, it sends the hash value (32 bytes) of the transaction to all neighboring nodes (except the node that sent it for the transaction). After receiving the hash value, neighbor node B checks to see if there are any transactions with the same hash value in the transactions it has received. If there is, it means that B has received the transaction and does not need to receive it again; if not, B will ask A for the full content of the transaction.

In the above process, the link of sending the transaction hash value is called announcement, and the detection of the transaction hash value can ensure that each node only needs to receive the complete transaction content once, and MT5 avoids the bandwidth waste caused by repeatedly transmitting the complete transaction.

But announcement itself also needs to use network bandwidth. A rough calculation shows that each node in the above scheme sends about 250bytes in the announcement link, which is much less than 1.6kB, but still exceeds the amount of data needed to forward a transaction.

Our goal is to reduce the amount of data sent from announcement to 1/8 based on the Bitcoin transaction forwarding scheme.

To achieve this, the easiest way is to shorten the length of the transaction hash broadcast on the announcement link. In this paper, in order to distinguish this hash value from the 32-byte transaction hash value used at the application level (wallet / smart contract), we call the hash value of the transaction at the application level the ID of the transaction, and the short hash value used in the announcement link in forwarding as the FID of the transaction (Forwarding ID).

In the Bitcoin scheme, FID is equivalent to ID, with a length of 32 bytes. If we set FID to the first 4 bytes of the ID value, we can achieve the goal of reducing the amount of data sent.

However, shorter transaction FID not only saves bandwidth, but also brings security risks. If two different transactions Tx1 and Tx2 have the same transaction FID, after a node receives the first transaction Tx1, when the neighbor node sends the FID of the second transaction Tx2, it will mistakenly think that it has received the transaction because of the FID conflict, so it will no longer request the full content of the Tx2. This will block the broadcast of the second transaction Tx2 on the network.

We can specifically calculate the probability of the FID conflict of the transaction:

Assuming that the transaction generation rate is 6000 transactions per second, when each full node receives a transaction FID, it will compare it with the FID received in the past 5 minutes to determine whether to request the full content of the transaction. In this way, the probability of conflict between the FID of a transaction and the FID of an existing transaction is 6000 * 300 / 232, which is about 0.04%. This means that an average of 2. 4 transactions per second cannot be broadcast because of FID value conflicts.

Although the 0.04% collision probability does not seem very high, it is only a normal situation without attack. With a specific attack strategy, an attacker can block the broadcast of any transaction, thus achieving the purpose of blocking a particular transaction.

The strategy of the attack is not complicated either: there are only 232 possible values for the 4-byte FID, or about 4.2 billion. As long as the attacker constructs a transaction for each FID value in advance and coexists, then according to the FID value of the transaction broadcast by the victim, he can find the transaction with the same FID value from his own pre-stored 4.2 billion transactions and send it to as many nodes as possible ahead of the victim, then the node that first receives the transaction sent by the attacker will ignore the victim's transaction because of the FID conflict. Even if the victim resends another deal, the attacker will be able to repeat the process.

Based on probabilistic calculations, attackers need to try to construct about 100 billion transactions to select 4.2 billion different FID transactions. For server-level CPU, it takes only a week to construct about 100 billion transactions. The storage space needed for calculation only needs 32GB after optimization.

Overall, the cost of carrying out these attacks is not very high. However, in certain situations (such as Fomo3D and other contracts), the blocking of the transaction may bring a lot of losses to the victims. So this risk must be eliminated from the beginning.

This is how Conflux optimizes the efficiency of bandwidth use, and the editor believes that there are some knowledge points that we may see or use in our daily work. I hope you can learn more from this article. For more details, please follow the industry information channel.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.