Academic orientation makes Bitcoin more secure, how does the Erlay protocol save 84% of the bandwidth of the node?

As the forerunner of the blockchain world, Bitcoin has suffered numerous attacks in 10 years. Because of this, the protocol that constitutes Bitcoin must adapt to the development of the network to ensure the security of the network.

The security of a bitcoin network depends on the connections between the nodes. Higher connectivity leads to better security, but under the current BTCFlood protocol, this creates bandwidth inefficiencies.

In this regard, Pieter Wuille, one of the Bitcoin code maintainers, Gregory Maxwell, a major bitcoin contributor, and Gleb Naumenko, Sasha Fedorova, and Ivan Beschastnikh, University of British Columbia scholars, jointly proposed a bitcoin transaction relay protocol called Erlay .

So, what are the advantages of the Erlay protocol compared to the BTCFlood relay protocol currently used by Bitcoin?

• The most stringent regulation in the history of digital currency? Sorry, there may be misunderstandings
• How to solve problems in Bitcoin and Ethereum programming models
• "618" shopping festival e-commerce giants trick play blockchain experts said that relying on "chain" to solve commodity security "a little difficult"

The picture below can clearly tell us the answer:

Figure 1: Comparison of Erlay protocol and BTCFlood relay protocol, from Erlay paper

In this paper, the researchers put forward two observations: (1) the current connectivity of the Bitcoin network is too low, which can not achieve the best security; (2) At the same time, increasing the connection will greatly increase the transaction spread. The bandwidth used by the protocol makes the cost of operating Bitcoin nodes prohibitively high.

Currently, half of the total bandwidth required to run a Bitcoin node is only used to announce transactions. Unlike block relay, in the early work, transaction communication has received very little attention. Here, the researchers proposed a new transaction communication protocol – Erlay. This not only reduces bandwidth consumption in the case of the current connection, but as the connection increases, the bandwidth usage remains almost unchanged. In contrast, existing protocols increase bandwidth consumption as the number of connections increases.

In general, Erlay improves the security of the Bitcoin network at a lower cost while allowing more connections. And, as the researchers showed, Erlay will also strengthen the network to resist attacks that attempt to understand a transaction source node. Currently, the Bitcoin development community is studying the Erlay protocol for future use in the Bitcoin core protocol.

I. Introduction

Bitcoin is a peer-to-peer (also known as peer-to-peer) electronic cash system. According to statistics from March 2019, the number of nodes in Bitcoin's entire network exceeds 60,000. In order to keep up with the number of nodes and the use of the network, researchers must constantly optimize the system while maintaining its security, which is what Bitcoin users expect. The security of a bitcoin network depends on adequate network connectivity. Many Bitcoin literature has repeatedly suggested increasing the number of connections between nodes to make the network more robust. As explained in Section 3 of the paper, if the network is highly connected, the attack will be more difficult to succeed, but unfortunately, increasing the connectivity of the Bitcoin network will linearly increase the bandwidth consumption of the transaction relay! The current Bitcoin protocol will account for as much as half of the total bandwidth required to run a Bitcoin node. Today, the transaction is relayed, and each node consumes 18 GB per month. If the connection is increased from the currently used 8 outbound connections to 24, each node used to relay transactions will consume more than 50 GB per month, which makes the cost of the node too expensive for some people. high.

Despite this, transaction relays have not received much attention in the scientific literature, and block relays are different.

The main reason why the Bitcoin transaction relay protocol is inefficient is that it relies on flooding . A bitcoin transaction is equivalent to the transfer of funds between several accounts. Figure 2 outlines the life cycle of transactions in a bitcoin network. A transaction is intended to be accepted by a network node, which must first be broadcast or relayed over the network. It must then be verified and packaged into a block along with other valid transactions. Finally, the block containing the transaction must be relayed to all nodes in the network. Every bitcoin transaction must reach almost all nodes in the network, and previous work has proven that full coverage of the network is important for security.

Figure 2: The life cycle of a bitcoin transaction, the Erlay protocol optimizes the part of the Bitcoin network node relay transaction (gray box)

Today, Bitcoin propagates transactions by ensuring that every message received by a node is transmitted to all of its neighbors.

This flooding method is highly fault tolerant, and because the nodes know the transaction as quickly as possible, this leaves the network with low latency.

However, flooding (具有flooding) has a very poor bandwidth efficiency: nodes in the network know the transaction multiple times. The empirical measurement by the researchers shows that the transaction is declared to account for 30%-50% of the total bitcoin traffic. This inefficiency is an important scalability limitation: this inefficiency will become more connected with the network. It becomes worse for a long time, and the connectivity of the network is desirable for network growth and security.

Previous research efforts have explored two issues that address the inefficiency of bandwidth usage. The first is to use short transaction identifiers (to reduce message size). The second is to monopolize the use of blocks without transmitting personal transactions. Unfortunately, both methods have drawbacks. Short identifiers only reduce the constant factor, but do not expand with the connectivity of the network, and exclusive use of the block will cause peaks in block relay and transaction verification. For these two schemes, the original paper is in section 11. Discussed more in the middle.

The Erlay protocol mentioned in this paper aims to optimize bitcoin relay transactions while maintaining existing network security. The main idea behind the agreement is to reduce the amount of information that is propagated through flooding, but to use an effective set-reconciliation method in most transactional broadcasts. In addition, the researchers also designed protective measures to enable the Erlay protocol to withstand other attacks such as DoS and Timing Attack.

The researchers implemented the Erlay protocol in a simulator as part of the mainline bitcoin node software and evaluated the scale of Erlay. The results show that Erlay can make the bandwidth consumption associated with the transaction announcement negligible while keeping the delay at a fraction of the block interval.

All in all, the contributions of the paper are as follows:

1. The researchers analyzed the bandwidth inefficiency of the Bitcoin transaction relay protocol and did so by running a node connected to the Bitcoin network and running a bitcoin simulation network. The results of the study show that 88% of the bandwidth usage for transaction announcements is redundant, which accounts for approximately 44% of the total bitcoin bandwidth.
2. The researchers proposed a new, bandwidth-efficient Bitcoin transaction relay protocol called Erlay, which combines fast low fanout flooding (flooding) and efficient set reconciliation. Designed to improve the Bitcoin network.
3. The researcher proves that the protocol achieves an approximate optimal combination of resource consumption and propagation relay, and achieves robustness against attacks. Erlay can immediately reduce the use of bandwidth for 84% of transactions and allow Bitcoin networks to achieve higher connectivity in the future for better security.

Next, let's review the background of the research work.

Second, the background of Bitcoin

First, we need to understand that there are two types of nodes in the Bitcoin network: Private nodes that do not accept inbound connections, and public nodes that accept inbound connections (see Figure 3). Public nodes act as backbones of the network: they help new nodes connect to the network. Once they join the network, the public node and the selfish node are indistinguishable in operation: both types of nodes perform transaction and block verification and relay valid transactions and blocks.

Figure 3: Private nodes and public nodes in a bitcoin network

The current version of the Bitcoin Transaction Trunking protocol uses diffusion, a variant of random flooding (ƒflooding). The so-called flooding method is a protocol in which each node announces every transaction it receives to each of its peers.

Transaction announcements can be sent via inbound and outbound connections. For diffusion, the peer node injects a random delay before announcing the received transaction to its peer. This reduces timing attacks and greatly reduces the probability of collisions (when two nodes simultaneously announce the same transaction through the connection between them).

Figure 4 illustrates the propagation of a transaction between two peer nodes. When a Bitcoin node receives a transaction (peer node 1 in Figure 4), it advertises the transaction to all its peers (except for the node that sent the transaction in the first location, and Other nodes that have received the announcement).

Figure 4: Transaction exchange between two peer nodes

To announce a transaction, a node will send a hash of the transaction in a list or INV message. If a node (peer node 2 in Figure 4) first contacts a transaction, it requests a complete transaction by sending a GETDATA message to the node that sent the INV message.

The researcher referred to the transactional broadcast portion of the protocol (all INV messages) as BTCFlood. Since it relies on flooding, most transactions are broadcast unidirectionally through each connection in the network (except those that are broadcast during the block relay phase). Therefore, a node with n connections will send and receive n and 2n INV messages for a single transaction (two nodes may announce the same transaction to each other at the same time).

Both open and private nodes limit inbound and outbound connections (Figure 3). By default, a self-contained node has no inbound connections and has up to 8 outbound connections, while a public node can have 8 outbound connections and up to 125 inbound nodes (but inbound connections can be as high as 1000 or so) . Therefore, as the number of selfish nodes in a bitcoin network increases, the bandwidth and amount of computation required to run a public node increases rapidly.

This is because the selfish node is connected to multiple public nodes to ensure that they are connected to the network through multiple peer nodes. As a result, Bitcoin designers will focus on (1) making open nodes easier to implement in terms of required bandwidth, computing power, and hardware resources, and (2) making public nodes more efficient so that they can accept from More connections to selfish nodes. The Erlay agreement is aimed at both goals.

Third, the flooding method (ƒ flooding) trading problems

The flooding method is inefficient. BTCFlood will send a lot of redundant transaction notifications. To understand why, let's consider what the number of notifications should be if the agreement is considered to be efficient. In the most ideal case, each node only accepts one announcement, so the number of times each announcement is sent should be equal to the number of nodes.

Next, let's consider passing BTCFlood, an announcement will be sent several times. By definition, each node relays an announcement on each connection (except for the connection that the announcement originally arrived). In other words, if no two nodes send the same notification to each other at the same time, each connection will see each notification once, and if they are sent at the same time, it will see multiple times. Therefore, in BTCFlood, the number of times each announcement is sent is at least several times the number of connections.

If the number of nodes in the Bitcoin network is N , then the number of connections is 8N , because each node must make 8 outbound connections. Therefore, the number of redundant announcements is at least 8N − N = 7N . Each announcement will account for 32 bytes of the 300 bytes required to relay a transaction (this 300 bytes includes announcements, responses, and complete transaction subjects). Therefore, if at least 7 of the eight announcements are redundant (corresponding to 224 bytes), then at least 43% of the traffic consumed by at least all announcements is wasteful. The researchers verified the analysis by experiment. The specific researcher configured a public Bitcoin node with 8 outbound connections and ran it for a week. During this time, the researcher's node also received 4 inbound connections. Researchers measured the bandwidth dedicated to trading announcements and other transactional broadcast traffic. If the received announcement corresponds to a known transaction, it is considered redundant. If there is no transaction request following the sent announcement, the researcher also considers it to be redundant. According to the researcher's measurements (multiple nodes are running in different areas), 10% of the traffic corresponding to receiving the announcement, and 95% of the traffic corresponding to the sent announcement are redundant. In total, 55% of the traffic consumed by the researcher nodes is redundant.

Higher connectivity requires more bandwidth. In the case of BTCFlood, increasing the connectivity of the network (ie, the number of outbound connections per node) linearly increases bandwidth consumption, given the number of redundant traffic is proportional to the number of connections.

Figure 5: Analysis cost of a Bitcoin node relaying transactions through flooding in one month

The researchers simulated how the bandwidth consumption of a transaction spread over a network of 60,000 bitcoin nodes increased as the number of connections increased. Figure 5 (the results obtained by simulation) shows that as the connectivity of the network is stronger, transaction announcement traffic will dominate. Each node has 8 connections. A self-serving node can consume 9GB of bandwidth traffic for monthly transaction announcements. Today, adjusting the number of connections to 24 will result in transaction relay consumption exceeding 15GB per month.

The stronger the connectivity, the higher the network security. In a P2P network, better connectivity will increase the security of the network. The traditional P2P research and the preliminary work of Bitcoin prove this.

If the connectivity of the network is highly developed, the success rate of some attacks will decrease. The eclipse attack paper shows that less than 13 connections will cause a lot of security risks to the website. The recently discovered vulnerability relies on the InvBlock technology, a technique that blocks the transaction from being first announced by the node, and then retains the transaction for 2 minutes, with higher connectivity. Attacks are easier to mitigate.

Fourth, the agreement needs

Requirement 1: Expand by number of connections . The main goal of the researcher is to design a transactional broadcast protocol with good connection scalability. With this approach, researchers can make the network more secure without sacrificing performance.

Requirement 2: Maintain a network topology that is suitable for a decentralized environment . The premise of the bitcoin decentralized environment has imposed restrictions on the design of its network. Although a structure is imposed on a network, for example by organizing it into a tree or star topology, or using DHT-style routing, a bandwidth efficient flooding protocol can be implemented, but this also brings about censorship or segmentation. risks of. Therefore, the topology of the network must remain unstructured, and each node must make routing decisions independently based on its local state.

Requirement 3: Maintain a reasonable delay . Transaction broadcast delays should remain within the scope of the existing agreement. Low latency is essential for the user experience and for achieving greater efficiency in block relaying.

Requirement 4: Robust against attacks under existing threat models . The researcher's agreement must remain robust under the same threat model assumed by existing protocols.

Transaction relay protocols must be resistant to DoS attacks and client anti-anonymity, and must not reveal any more information about the network topology than existing protocols.

Five, Erlay's design

Traditionally, P2P networks address the flooding inefficiencies of the network by applying structured coverage on specific topologies. For the security reasons discussed in Section 4, researchers avoided institutionalized network organization. Instead, the researchers' design relies on two common system building techniques: delay and batching.

Nodes using this protocol do not advertise each transaction on each connection, but instead advertise it to a subset of peer nodes, which is known as low fanout flooding. To ensure that all transactions reach the entire network, the node periodically participates in interactive protocols to discover lost notifications and request lost transactions. This is called set reconciliation. The Erlay protocol consists of a low fanout flooding method and a set reconciliation (Fig. 6).

Figure 6: Erlay uses a low fanout flooding method to propagate transactions as a first step, followed by several rounds of reconciliation to reach all nodes in the network.

Low fanout flooding: The basic principle of low fanout flooding is to conveniently relay a transaction from each node in the network to a small number of hops. If each transaction is close to each node, then reconciliation can use a small number of rounds to complete the propagation, so a key decision for low fanout flooding is which peer is going. Following.

Set reconciliation: Set reconciliation is proposed as a synchronous alternative in distributed systems. Using set reconciliation, a node in a P2P network periodically compares its local state with the state of the peer node and sends/requests only the necessary information (ie, state differences). A set reconciliation can be thought of as a valid version of a batch (accumulating multiple status updates and sending them as a single message). A key challenge in the actual reconciliation process is that the peer node can accurately calculate its lost transaction status and limit the exchanged transactions to transactions lost by another peer node.

Figure 7 shows how Erlay finds the best position in terms of bandwidth and latency by combining flooding and reconciliation.

5.1 Low fan flooding method (ƒflooding)

Flooding is inefficient and expensive, so researchers should use it cautiously and strategically. Therefore, only well-connected public nodes flood the other nodes through outbound connections. And because each selfish node is directly connected to several public nodes, this strategy ensures that transactions are quickly propagated to a hop in most nodes in the network. Therefore, full reachability (R3) requires only 1-2 rounds of reconciliation. According to this, the protocol proposed by the researcher can be regarded as two-tier optimistic replication.

To achieve the scalable target (R1), the researchers limited the flooding method to set the outbound connections of the public nodes to eight (even if the total number of connections is higher). In this way, while increasing the number of connections, the transaction cost will not increase proportionally.

The decision to relay through an outbound connection instead of an inbound connection is to prevent timing attacks.

In a timing attack, an attacker connects to the victim and listens for all transactions that the victim might send on the connection (the victim's inbound connection). If an attacker learns a transaction from multiple nodes (including victims), the time the transaction arrives can be used to guess whether the transaction was sent from the victim: if this is the case, it is likely to be earlier The victim arrives there, not the other nodes. BTCFlood introduces a diffusion delay to prevent timing attacks. In the Erlay protocol, this delay is not needed because the researcher does not forward a single transaction to an inbound connection. So this decision is good for both R3 and R4.

Transactions in the Bitcoin network may come from both open and selfish nodes. In the protocol proposed by the researchers, the nodes do not relay transactions through flooding, so the network understands the transactions they initiate by reconciling: the self-owned nodes forward their own transactions to the reconciliation period. Other transaction batches for peer nodes (attached to their peer nodes during reconciliation). This is used for hiding when the transaction is initiated from a selfish node. If the transaction is sent from a selfish node, then obviously, for the public node, these transactions must be created on these nodes, because according to the selected flooding strategy, this is a selfish node flooding one. The only case of pen transactions is because they do not have an inbound connection. Since a selfish node forwards its own transactions as part of a batch process rather than forwarding it separately, a malicious public node is unlikely to discover the source of a transaction (R4).

5.2 set reconciliation

In Erlay, the peer node performs set reconciliation by computing the local set of sketches, as described by the PinSketch algorithm. A set of sketches is a type of set checksum with two important properties:

1. The sketch has a predetermined capacity, and when the number of elements in the collection does not exceed the capacity, the entire set can always be recovered from the sketch by decoding the sketch. The sketch of the b-bit element of capacity c can be stored in the bc bit.
2. The symmetric difference between two sets (that is, all the elements that appear in one input set, not the two input sets) can be obtained by XORing the bit representations of the sets of these sets.

These attributes make the sketch suitable for a bandwidth-efficient set reconciliation protocol. More specifically, if both Alice and Bob each have a set of elements, they suspect that these sets are largely (but not completely) overlapping, they can use the following protocol to let both parties know all the elements of the two sets. :

1. Both Alice and Bob calculate the sketch of their collection locally;
2. Alice sent her sketch to Bob;
3. Bob combines these two sketches and gets a symmetric difference sketch;
4. Bob tries to recover elements from the symmetric difference sketch;
5. Bob sent her the elements that Alice lacked.

When the size of the difference (that is, the elements owned by Alice, but not owned by Bob, and the elements that Bob has, but not Alice), does not exceed the capacity of the sketch sent by Alice, this program always It will be successful. Otherwise, the program is likely to fail.

A key attribute of this process is that it is not related to the actual set size: it is only related to the set difference size.

The computational cost of decoding a sketch is high and is squared with the size of the difference. Therefore, before the set difference becomes too large (Section 5.2.2), accurate estimation of the size of the difference (Section 5.2.1) and reconciliation are important goals for the agreement.

5.2.1 Reconciliation round . Figure 7 summarizes this reconciliation agreement. In order to perform a round of reconciliation, each node maintains a reconciliation set for its peers. The reconciliation set contains the transaction short ID sent by the node to the corresponding peer node through the regular BTCFlood, but the situation is different because Erlay limits the flooding method. The researchers set Alice's reconciliation set for Bob to A and Bob's reconciliation set for Alice to B. Alice and Bob will calculate the sketches for these reconciliation sets (as described in the previous section.)

The important parameters of the protocol are: D – the actual size of the set difference, the estimated value of d – D, q – the parameter used to calculate d. The investigator will provide the source of these values ​​below. First, the researcher described a reconciliation round:

1. According to the selected reconciliation plan (Section 5.2.2), Alice sent the size of A and q to Bob;
2. Bob calculates an estimate d for D between his B and Alice's A (see below);
3. Bob calculates the sketch of B with D trading ability and sends it to Alice along with the size of B;
4. Alice received Bob B's sketch, calculated A's sketch, and XOR the two sketches. Now, Alice has a sketch of the difference between A and B;
5. If the difference is estimated correctly, Alice can decode the sketch calculated in the previous step, ask Bob for her lost transaction (or transaction), and then notify Bob of his lost transaction (or transaction). If the estimate is incorrect (sketch decoding fails), Alice will use the equalization method (Section 5.2.3);
6. After this process, Alice updates q (see below) and clears A, Bob clears B;

Accurately estimating the D value is critical to the success of the reconciliation. Previous work used techniques such as minwise hashing or random mapping to estimate. These technologies are complex, and researchers worry that these technologies will eventually consume a lot of bandwidth. Therefore, the researchers adopted a minimalist approach in which the investigator estimated the size of the set difference based only on the size of the current set and the differences observed in the upper reeling round:

d = abs(|A| − |B|) + q · min(|A|, |B|) + c,

Where q is the "floating point coefficient" (derived as follows) that was previously characterized by previous reconciliation, and c is the parameter used to handle the special case.

In fact, the difference between the two sets cannot be less than the difference in their size. To avoid costly underestimation, the researchers added the size of the smaller set normalized by q, and a constant c = 1, when |A| = |B| and q ·min(|A|, |B|) = At 0, avoid estimating d = 0.

This coefficient q depicts the previous reconciliation, so it is set to 0 before the first reconciliation round. At the end of the reconciliation round, the researcher simply updates q according to the real D found in this round, replaces D with d in the above formula, removes c, and then solves q:

q =D − abs(|A| − |B|)/ min(|A|, |B|)

This updated q will be used for the next pair of account turns. Researchers use this method to calculate q because the researchers assume that each node in the network has a consistent optimal q.

Reconciliation is a fertile ground for DoS attacks because the computational cost of decoding a sketch is high. In order to prevent these attacks, in the researcher's agreement, the nodes interested in reconciliation (and the nodes that need to decode the sketch) will initiate reconciliation (in the case of the researcher Alice), Bob can't force Alice to execute Excessive sketch decoding.

5.2.2 Reconciliation schedule . Each node initiates reconciliation through an outbound peer node every T seconds. Choosing the right T value is important for performance and bandwidth consumption. If the T value is too low, the reconciliation will run too often, which will consume too much bandwidth. If the T value is too high, the reconciliation set will become very large and the decoding set difference will become expensive (will be quadratic with the number of differences). A large T value also increases the delay in the propagation of transactions (or transactions).

A node reconciles with a peer node every T seconds. Since each node has c outbound connections, each connection in the network performs an average reconciliation every T · c seconds. This means that the average reconciliation set set before the reconciliation will contain T · c · TXrate transactions (or transactions) where TXrate is the global transaction (transaction) rate. That is, during the reconciliation period between each node, the node will receive a T· TXrate pen transaction (or transaction).

In the Erlay protocol, the T value is set to 1 second. With this setting, and the ratio of the current selfish node to the public node, each public node will perform approximately eight reconciles per second. Considering that the current maximum transaction rate of the Bitcoin network is 7 tps, the average difference set size of this protocol is 7 elements. For the selection of this parameter, the original paper is described in detail in Section 8.

5.2.3 The equalization method for the set difference estimation failure . The researcher's set reconciliation method relies on the assumption that for setpoints, the difference between two peer nodes is predictable. If the actual difference is higher than the estimated value, the reconciliation will fail. This failure can be detected by the client calculating the difference. An obvious solution to this failure is to assume that the differences in the collection are greater, recalculating and retransmitting the sketch. However, this would invalidate the previous reconciliation transfer, which is very unlikely.

Instead, Erlay uses a reconciliation bisect that reuses previously transmitted information. The bisector method is based on the assumption that the elements are evenly distributed in the reconciliation set (which can be achieved by hashing). If a node is unable to reconstruct a set difference from the product of two sketches, the node issues an additional reconciliation request similar to the initial reconciliation request, but this request only applies to a small portion of the possible message (for example, to a range of 0x0–0x8 transactions (or transactions)). Due to the linearity of the sketch, the transaction subset's sketch will allow the node to calculate the sketch for the remaining nodes, which saves bandwidth.

However, this approach ultimately allows recovery of the difference in the number of 2d, where d is the estimated set difference in the initial step.

Six, discussion

Researchers believe that only reconciliation transaction relay protocols are inherently susceptible to timing attacks, which may reveal the source of the transaction. Unlike flooding, reconciliation is essentially bidirectional: an inbound connection to a peer node is an outbound connection to another peer node. It is not possible to apply a relay per connection, but per connection. Therefore, BTCFlood's di‚ffusion relay cannot be applied in reconciliation.

Erlay increased the delay from 3.15s to 5.75s . The Erlay protocol increases the time to relay unconfirmed transactions between all nodes, which is a small part of Bitcoin's peer-to-peer transaction processing (average 10 minutes). The researchers adjusted Erlay to maximize bandwidth savings, assuming that the delay increased from 3.15s to 5.75s is acceptable. Of course, if you want to keep the same latency as BTCFlood, we can adjust the reconciliation frequency of the Erlay protocol, which will slightly increase the bandwidth overhead (from 84% savings to 70% savings).

In practice, there are two main effects of increased transaction relay latency:

1. The block production rate is defined by the block relay delay, and the block relay delay can only be defined indirectly by the transaction relay delay: if fewer transactions are relayed, the propagation block takes longer (because Lost transactions must be relayed and verified). Because Erlay has a better delay between public nodes than BTCFlood, the use of Erlay miners may have a lower lone rate.
2. User experience: If a transaction is accepted in the unconfirmed state, the user will feel a 2.6 second delay increase. However, unconfirmed transactions are rarely accepted by users, and users usually wait at least 10 minutes to confirm the transaction. Therefore, we can think that the 2.6 second delay brought by Erlay has no negative impact on the user experience.

Compatibility with the Dandelion (dandelion) protocol . Dandelion is another transaction relaying protocol designed to increase the anonymity and robustness of Bitcoin. Dandelion (dandelion) has two phases: stem (average spread on a single link of 10 nodes), and ƒfluff (using the last node in the stem link for flooding relaying). Erlay and Dandelion (dandelion) protocols are complementary: Erlay will replace the ƒfluff phase in the Dandelion protocol, while the stem phase in Dandelion will flood through inbound and outbound connections to protect the privacy of selfish nodes.

Backward compatibility . Currently, only 30% of nodes on the entire network run the latest version of Bitcoin Core software, so Erlay must be backward compatible. If not all nodes use the Erlay protocol, the connection between them will activate Erlay when both peers support it.

Attacks related to mining . There is no direct relationship between Erlay and attacks such as selfish mining. By making timing attacks more expensive, Erlay makes the inference of network topology more difficult. Therefore, Erlay indirectly makes the network more robust.

Correlation with other blockchains: Erlay is not only applicable to Bitcoin in practice, but most of the deployed blockchains on the market can use the Erlay protocol (eg Ethereum, Zcash, etc.) because they all use flooding Method (ƒflooding) to relay transactions. Even if there is a possibility of a difference in the TXID size or the number of connected peer nodes, what is really important is the transaction rate. Erlay is theoretically applicable to systems with high transaction rates. On the other hand, since PinSketch has the complexity of a quadratic relationship, using it without modification will result in higher reconciliation costs and higher hardware requirements. For example, a bitcoin-like blockchain network, but with a transaction throughput of 700 tps, if the bitcoin's Erlay protocol is moved directly, the average reconciliation set difference will consist of 1000 elements. According to the benchmark, direct reconciliation through Miniicketch will take 1000 milliseconds. If recursively applies the equalization method 3 times, it needs to reconcile 8 chunks composed of 125 elements, which takes 20 milliseconds. Thus, Erlay can be applied to systems with higher transaction rates.

Seven, conclusion

Bitcoin is one of the most widely used P2P applications worldwide, and its network currently relies on 60,000 nodes for flooding transaction relaying. The flooding method provides low latency and is robust against hostile behavior, but it is also bandwidth inefficient and causes a large amount of redundant traffic. The Erlay protocol proposed by the researchers can effectively reduce the bandwidth required for transactions, and achieve a 84% bandwidth savings through a 2.6 second transaction broadcast delay. Erlay allows bitcoin nodes to achieve higher connectivity, which will make bitcoin networks more secure. Currently, researchers are actively introducing the Erlay protocol to Bitcoin Core software.

Other similar blockchains can also use this protocol to reduce node bandwidth requirements.

Interested readers can read the original paper to learn more about the Erlay protocol: https://arxiv.org/pdf/1905.10518.pdf

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