Bandwidth and the Blockchain
How developers are minimizing overhead
Blockchains keep the entire world on the same page. As each block is minted, a new ledger state supersedes prior states. Consensus mechanisms work to ensure that the state is agreed on by the wider community. In a well designed system, incentives ensure immutability. After enough time has elapsed, the state can’t be tampered with. These blockchains give us programmable money, and have rightfully captured the imagination of so many.
Bitcoin and Ethereum are two of the earliest incarnations of blockchains. These ledgers have proven to be popular and robust, yet it is commonly believed that they do not scale. Why would that be? And what can be done to improve the situation?
Background
Blockchains themselves are referred to as layer 1. The blockchain acts as a global source of truth on the current locations of all cryptoassets within the network. Full nodes on the network keep track of the current state of the ledger. To maintain decentralization or a lack of a power center, it must be possible for small miners to verify and contribute to the blockchain. Small miners may have system resources and bandwidth vastly inferior to larger players.
In order for blockchains to be trustless and censorship resistant, they cannot be controlled by any single entity or small group. Developers believe it is important to keep participation accessible to players of all sizes to avoid consolidation of power, and the emergence of a single point of control. It is for this reason that there has been such resistance to increasing the block size limit in bitcoin. The limit acts to throttle the entire system, keeping it widely accessible.
It should be noted that local agreements can be made between parties to transfer coins without making a global update. This is often referred to as layer 2 or off-chain transactions, and has profound effects on scaling up transactions (not necessarily users). The idea is that transactions can be aggregated between parties before being written to the blockchain. The window for flushing local state to the global blockchain can be several months or even longer in some designs.
Engineers are optimistic that layer 2 solutions will bring massive scalability to blockchains and will be critical before cryptocurrencies are able to meet the demands of a large userbase. However, even though layer 2 acts as great leverage, it can only amplify the scale of the base blockchain. Layer 2 cannot provide unlimited scale on its own. Therefore, it’s important to optimize the network to use as little resources as possible for each transaction.
The problem
The decentralized Bitcoin blockchain is globally shared broadcast medium — probably the most insanely inefficient mode of communication ever devised by man.
- Greg Maxwell
The basic problem that layer 1 has is that copies of the ledger must stay in sync across the globe. Every full node stores a copy of the blockchain, and those copies must be identical to each other and independently verified by each node.
When a new block is found, it must be communicated to all other nodes. Latency is especially critical for mining nodes, since they need to be working on top of the most recent block at all times, or their effort is wasted. In order to verify the most recent block, miners need to know which transactions are included as well as have copies of all of these transactions.
Currently, Bitcoin software uses a naive approach to propagate transactions and blocks. Transactions are forwarded to all peers as they are received. Blocks are transmitted wholesale without regard for pieces of data that the recipient may already have. These inefficiencies are not tolerable for miners who need to make sure they have access to the most recent block.
Remedies
These inefficiencies within Bitcoin are well known. Efforts to make the network more efficient in terms of reducing bandwidth overhead as well as speeding up propagation have been ongoing for years. Former Bitcoin maintainer, Gavin Andresen, published a roadmap for O(1) block propagation back in 2014. The roadmap has been significantly altered since, but the ideas are still relevant.
Relay Networks
Miners have taken initiative upon themselves to implement block relay networks such as FIBRE and Falcon. These relay networks work by using low latency + high bandwidth connections, but they have drawbacks such as being centralized and using significant amount of bandwidth in an effort to minimize latency. They do not reduce overall bandwidth demands of running a non-mining node, which is needed before engineers will feel comfortable to scale up the system.
Compact Blocks
When it’s time to transmit a block, it’s suboptimal to transmit transactions that the recipient already has. Cryptographer Greg Maxwell recognized that recipients already know much of what’s included in a newly found block. Concretely, the recipients’ mempool (set of received, but unconfirmed transactions) likely contains many of the transactions that are within the new block. He studied this problem and drafted a proposal in December 2015.
Core developer Matt Corallo took Greg’s work and polished it up and it became BIP152 specifying Compact Blocks in early 2016. Compact blocks is a protocol that sends the block header, a list of shortened transaction IDs, and a set of transactions that the sender believes the recipient is unlikely to have rather than sending a block with all of its data. This change was meant to save on bandwidth, but has the nice side effect of reducing latency as well.
Erlay
The flood broadcasting based approach within Bitcoin is clearly not optimal for disseminating transactions within the network. A node can receive multiple copies of each transaction and must forward them to each peer they are connected to. This results in large amounts of bandwidth consumed resulting in unneeded overhead. It also encourages nodes to connect to fewer peers since each peer will require incremental bandwidth per transaction.
Connecting to fewer peers does limit bandwidth consumption, but it can be dangerous, as it opens the user up to what’s known as an eclipse attack. Ethan Heilman, creator of TumbleBit, published a research paper on the eclipse attack in 2015. The basic idea is related to a Sybil attack. An attacker pretends to be many different entities in an effort to confuse the victim. The attacker monopolizes all outgoing connections to the victim’s node. By acting as the victim’s sole source of information, they mine special blocks to falsify the current state. It’s costly, but if the attacker can get the victim to believe that they have received a large sum of bitcoin, when in fact the funds have been moved elsewhere, the victim could be persuaded that they have received funds and release property.
Erlay results in a more well connected and robust network. If a node were to connect to 32 peers, Erlay researchers find that their optimizations would result in the node using 75% less bandwidth than they would with current software.
What’s next?
Block propagation has been heavily optimized with the relay networks that the miners use and compact blocks for ordinary node users. Still, researchers are working to remove overhead from the system to make it as streamlined as possible. Only once developers are satisfied that bandwidth requirements are as low as possible for the current amount of throughput, will increasing throughput be on the table.
Further Resources
- Greg Maxwell’s 2017 talk on advances in block propagation
