This month’s development is about block propagation and how we are solving this in Purple. The block propagation rate is one of the most important things to consider when thinking about scalability in blockchain systems. Without a high block propagation rate, we cannot achieve the fundamental breakthrough that we are aiming for.
Block propagation mechanisms have much evolved since the Bitcoin protocol was first conceived. Some of these advances in this have also been applied to the Bitcoin protocol itself.
They also both suffer the same fundamental flaw that was also present in the original propagation system of Bitcoin: on each hop the whole block has to be downloaded and validated before being propagated further.
What we want is to minimize round-trips as the average round-trip time is around 200ms. We also want nodes to be able to download a single block from multiple, vetted sources in parallel.
The problem of block propagation can be thought of as a file replication problem with a few caveats. We can look at how the Bittorrent protocol achieves this and how it is optimized for maximizing bandwidth.
There are a few key concepts that make the Bittorrent protocol achieve optimal file replication:
- Each file is broken into chunks (or pieces) of usually
- The torrent file contains the hash checksum of each piece.
- Each piece is further divided into sub-pieces, of usually
- A requesting peer selects pieces and downloads them in parallel from multiple peers.
- Each requesting peer selects a few best peers to download and upload from based on previous download/upload rate and availability.
Purple Parallel Propagation
If we think of a block as a torrent, we can then begin to draw inspiration from Bittorrent and achieve optimal block propagation:
- Transaction data can be split as in Bittorrent and a transaction block header will contain
8bytechecksum hashes of each chunk.
- Block headers are propagated as previously but without waiting to validate the transaction set.
- Nodes will then begin requesting pieces of the block from its peer set, prioritising pieces with a lower height.
- At a
4mbblock size we only need to store
128 bytesof checksums in the header.
- A node will upload pieces of a block to other peers without waiting for the whole block to download.
By using this mechanism, the peers with the best download/upload speed will mostly always be able to stay in sync while nodes with a lower internet speed will not slow down the faster nodes.
While this change will definitely delay the release of Purple, we have currently began implementation of the parallel propagation mechanism. While we don’t know yet any numbers, we expect an exponentially higher transaction throughput after the implementation is complete.
In this development update we have presented the final block propagation mechanism that will be used by Purple which was inspired by the way Bittorrent handles file replication on a peer-to-peer network.
Spread the word
Help us spread the word by sharing this article about the Purple Protocol! Stay tuned for more!