This is the fifth in a series of articles explaining technical concepts related to on-chain network scaling, block propagation, and other related subjects

This is our final article in our five part series on the Velocity Protocol. For perspective, please check out previous installments:

1. Bloom Filters
2. Invertible Bloom Lookup Tables (IBLTs)
3. Graphene Protocol
4. Poison Block attacks

The Velocity Protocol is the result of research by ASU blockchain lab. Specifically, Nakul Chawla submitted this work for completion of his master’s degree at ASU.

As a recap, the Compact, Xthin, and graphene protocols broadcast blocks throughout the network by communicating a list of transactions in a block. This saves a lot of bandwidth as an eight byte identifier can replace a transaction of hundreds or thousands of bytes. We also discussed how graphene utilizes data structures to achieve more efficiency, and discussed how these protocols are vulnerable to a poison block attack, where a miner broadcasts a blocks with many transactions that have not been broadcast to the network.

Maximizing bandwidth efficiency rather than reducing bandwidth required

The Velocity Protocol solves block prorogation in a completely new way. It is expected to work well with the masternode network. Unlike the other protocols, the Velocity Protocol does not reduce the amount of bandwidth required to propagate a block. The Velocity Protocol uses available bandwidth more efficiently. Recall that bandwidth is a use-it-or-lose-it type of resource. A data center with a 1GBPS connection could use every second of the GBPS or only max-out at peak times only. The cost is the same.

Let’s explain the Velocity Protocol with some numbers given. The idea is that a block is broken up into pieces which we call symbols. A block could be broken up into 1000 symbols. A node that learns about a new block might ask all 25 peers for this block. Let’s say that 14 of those 25 peers have the new block and they start sending symbols to the requesting node. The receiving node might receive 995 symbols plus 6 repair symbols. In this case the receiving node can construct the full block with extreme certainty. As the full block is recovered, velocity is immune to a poison block attack. Simulations carried out by Nakul Chawla suggest this protocol works very well. We suspect that these results are explained by the use of bandwidth in parallel.

Minimizing the effect of the weakest nodes

The Velocity Protocol minimizes the effect of poorly connected nodes. For example, if a block is requested through a poor connection there will be a delay of propagation. With velocity, a node connected to five nodes, A, B, C, D, and E, where D and E are weak connections. When receiving symbols A and B could provide 350 symbols each while C provides 200 while D and E provide 50 each. D and E actually speed up propagation even if the connection is weak. Without sharing the bandwidth burden, weak connections could slow down propagation.

In some papers it is asserted that the bitcoin network is as robust as its weakest node. Bitcoin Unlimited chief scientist Peter Rizun will counter this claim citing that an obsolete Commodore 64 on the Bitcoin network would not harm the network, in fact it would eventually would be dropped. If velocity is integrated into Dash or other network, then weak nodes have a negligible effect on the network, while the network could provide better support for weak nodes and support more weak nodes. This means that the network would be more Resilient, Robust, and Flexible.

Known “breaking point” of over VISA transaction capacity

In short, the results from our simulations are fantastic. There is still a long road to go until something is in production and our simulations verified. There are also complicating factors which I will explain.

In short, we consider there to be two breaking points of these networks as they scale. There is one limit where the network loses consensus. There is a smaller economic limit where miners may decide not to make blocks bigger. Our simulations suggest that Dash with velocity has a consensus limit of 500MB, while the economic limit is just under 300MB. To put this in perspective, Dash with 250MB blocks would be able to process the average transactions per second as VISA. This is fantastic.

Comparing with gigablock testnet research

Related research is the gigablock testnet research by Peter Rizun, Andrew Stone, et al. In this research it was shown that Bitcoin could support 1GB blocks. Our result is that Dash can support 500MB blocks. As Dash’s blocks come out four times as often this means that Dash would handle twice the throughput. Notable facts is that the gigablock testnet used 18 nodes and was an emulation. Our velocity experiments assumed 24 nodes and was a simulation. An emulation should be more true to life than a simulation. In both cases the number of nodes assumed was small. I have speculated that Dash can handle more transactions per second because the demand to process each block is less due to a quicker block time. This research may be the first evidence of this claim.

There are hurdles between simulation and production. One is that the simulations do not find that current Dash clients can only accept so many transactions per second. This is a solved problem, but it is possible that the simulations did not identify other hurdles. The number of nodes is low in our simulations. Introducing more nodes generally slows propagation. We found the orphan rate to be around 30% when operating at the economic limit. That orphan rate is not suited for production.

Combining Graphene with Velocity to solve the poison block attack?

An idea worth exploring is to understand a graphene/velocity hybrid. Velocity performs the poorest when a block is new and hasn’t made it to many nodes. I want to know how graphene preforms when it falls back on velocity when there is a fail to decode. This would provide a graphene protocol which will have significant mitigation of a poison block attack.

This different approach to block propagation should also produce auxiliary benefits. For example this could allow for a quicker sync time. The expectation is that, instead of a few days to sync the Bitcoin blockchain, velocity could reduce this to hours. It’s exciting to consider the possibilities.

Here is the complete velocity write-up if you’re technically inclined and interested.

Follow us on Linkedin | Twitter | Facebook