In our previous post (The scalability problem, (very) simply explained), we outlined why the P2P block propagation used in blockchain is the main bottleneck for scaling blockchains and cryptocurrencies. In short, holding everything else constant, if you increase the number of transactions per second (TPS) by increasing the block size by a factor of x10, you increase the time for blocks to propagate by x10 and the probability of a fork by roughly x10. So if you increase it by x100, you will see more forks than blocks to resolve them, which will in turn cause the blockchain to break.
There have been several proposals to reduce the block propagation time, most notably FIBRE and Falcon, Compact and XThin Blocks, and Graphene. Unfortunately, these approaches are insufficient for the following reasons.
FIBRE and Falcon
The first significant improvement to the block propagation time came from the FIBRE and Falcon relay networks. These relay networks aim to reduce orphan block rates (which occurs whenever there is a fork), and to place smaller miners on par with larger miners. The primitive of the relay network is simple: rather than using the slow P2P propagation mechanism, it uses a network of well-connected servers, and any block sent to one of these servers is broadcasted immediately to all of the other servers, and to all of the nodes connected to them.
Falcon, which was created by Prof. Emin Gün Sirer and Soumya Basu, two of bloXroute’s co-founders, also adds cut-through routing. Whenever a block is sent to Falcon, Falcon’s servers only validate the first bytes of the block (making sure the PoW is valid), and stream it to all of the other nodes, without waiting until the entire block is received. By the time the last packet of the block arrives to Falcon, Falcon has already broadcasted the data it previously received, and only that last packet needs to be broadcasted.
Both FIBRE and Falcon are doing a terrific job reducing the block propagation time for Bitcoin and Bitcoin Cash. They are reducing forks and orphan block rates, and they are the reason why the current block propagation time to the entire network remains in the order of 10 seconds.
Unfortunately, blockchains cannot depend on these relay network systems to scale.
If Bitcoin were to use FIBRE to scale to 300 MB blocks, decentralization will be unachievable, since the decision whether a transaction or a block go on the blockchain or not will be subject to the whims of the relay network owner. The relay network owner could send blocks faster to some miners, drop or delay them to others, and even ban wallets by rejecting all blocks which include them. This breaks the decentralization and trustlessness promised by blockchains. As we established in the previous post, the 300MB blocks could not simply be propagated by using the P2P system, and so it is almost certain they will be forked off by the blocks which are propagated by the relay network.
Scaling using a relay network such as FIBRE or Falcon requires everyone to place their trust in the relay network. And if the blockchain requires everyone to place their trust in a single centralized entity in the middle of the blockchain in order to operate at scale, what’s the point of using the blockchain anyway? You might as well continue using the bank, who we already have to trust to control our funds.
bloXroute’s work begins where Falcon’s work ends, allowing orders of magnitude more transactions per second, and in a provably neutral manner, without requiring trust. We will detail how bloXroute archives its neutrality in our next post.
Xthin blocks and Compact blocks
Xthin blocks and Compact blocks are two similar techniques which replace each transaction with its 6 bytes hash (not the usual 32 bytes SHA-256 hash), thus reducing the amount of data each block contains. There are a few differences between Xthin and Compact blocks, but they both rely on transactions being known ahead of time to all nodes, so each node would know to translate the hashes back to the transactions, and they both have a fall-back mechanisms to minimize the overhead when nodes’ mempools are not completely in sync, or when there is a collision in the hashing of transactions.
Keeping mempool in sync becomes harder, and collisions become frequent when the volume of transactions increases. The Bitcoin Unlimited team have presented the ability of Xthin blocks to support up to 500 TPS in a small network of:
· 10–12 nodes
· 4–6 of which are miners
· Running on a global cloud infrastructure (DigitalOcean), which provides low latencies and great connectivity
They were unable make further progress due to the block propagation time (see Peter Rizun and Andrew Stone’s presentation below), despite their network being very small, well provisioned, and without the messy details of large-scale real-world networks (nodes joining, leaving, and restarting, links failing, congestion conditions changing rapidly, topology inefficiencies, etc.). The real-world volumes of TPS that Xthin can support are unknown, but are expected to be significantly smaller.
Another relevant technology is Graphene, a block propagation protocol developed by A. Ozisik, Prof. B. Levine, Gavin Andresen, et al. Graphene tries to reduce block size further by combining two techniques: a bloom filter and an IBLT (invertible bloom lookup table). The key principle is clever — the receiver of a block uses the bloom filter to filter out transactions from its mempool (or IDpool), and the remainder of the transactions are used to create a new IBLT, which is used to decode the sender’s IBLT.
bloXroute outperforms the other solutions by x10–100, by leveraging its advantage on two dimensions: propagation topology and compression. We will give specific details in our next post, but in general, bloXroute can represent blocks using much smaller pieces of data, and it streams blocks to all nodes.
— — —
We’re always looking for good people!
If you’re equally excited to solve the scalability bottleneck for all blockchains, consider joining our team! We are always looking for passionate partners to help us on this important journey. Check out our available positions to work with us in our Chicago offices.