SCALABILITY MEASURES IN BITCOIN
At the time of writing, almost one transaction per second (tps)  is executed in Bitcoin; this results in an average block size of almost 400 KB. The maximum block size is currently limited to 1 MB, which corresponds to less than seven transactions per second. Given the increasing adoption of Bitcoin, the number of transactions, and the block sizes are only expected to increase. For example, if Bitcoin were to handle 1% of the transactional volume of Visa, then Bitcoin needs to scale to accommodate almost 500 tps—requiring a large amount of information to be broadcasted in the network.
Motivated by these factors, the current Bitcoin protocol implements various bandwidth optimizations and measures in order to sustain its scalability and correct operation in spite of ever-increasing use. In what follows, we detail the existing measures taken by Bitcoin developers.
Request Management System
Bitcoin uses an advertisement-based request management system to minimize the information spread in the network.
Namely, to minimize information spread in the network, messages are propagated in the Bitcoin network with the help of an advertisement-based request management system. More specifically, if node A receives information about a new Bitcoin object (e.g., a transaction or a block) from another node, A will advertise this object to its other connections (e.g., node V) by sending them an inv message. These messages are much smaller in size than the actual objects, because they only contain the hash and the type of object that is advertised. Only if node V has not previously received the object advertised by the inv message, will V request the
Figure 3.8 Propagation mechanism for blocks and transactions.
object from A with a getdata request. Following the Bitcoin protocol, node A will subsequently respond with a Bitcoin object (e.g., the contents of a transaction or a block).
By doing so, inventory messages limit the amount of data broadcast in the network. Note that in case the object advertised corresponds to a block, neighbor V first requests the block header before the actual block data. Here, when a block header is advertised via a headers message, the receiving node internally stores the highest block known by the sending peer. The receiving node also validates any received header by verifying its corresponding PoW. Transactions, on the other hand, are propagated directly following the reception of the corresponding transaction inv message. This process is summarized in Figure 3.8.
To minimize bandwidth consumption, Bitcoin nodes request a given object only from a single peer, typically the first peer that first advertises the object. Requesting the same object from multiple peers entails downloading the same data several times, and therefore can only increase the bandwidth consumption of the system.
As in the case of address discovery protocols, when a client generates a transaction, the client schedules it for forwarding to all of its neighbors. In particular, the client computes a hash of a value composed of the transaction hash and a secret salt. If the computed hash has the last two bits set to zero, the transaction is forwarded immediately to all the eight entry nodes. Otherwise, the transaction is queued for announcement as described before for addr messages: the neighbor receives the transaction whenever it is selected as a trickle node. To avoid flooding the network with unnecessary messages and messages similar to addr messages, a Bitcoin peer maintains history of all forwarded transactions for each connection. If a transaction was already sent over a connection, the transaction will not be resent another time. In addition, a Bitcoin peer keeps all received transactions in a memory pool, such that if the peer received a transaction with the same hash as one in the pool or in a block in the main blockchain, the received transaction will be ignored.
-  Currently, the Visa network is designed to handle peak volumes of 47,000 tps .