This question was taken from here
The Orbs consensus algorithm (Helix) attempts to close blocks as quickly as possible (assuming there are pending transactions in the pools that were not processed yet). Unlike protocols like Bitcoin (and most PoW algorithms actually), there is no fixed block time.
This means that if you want to know the practical block time, it needs to be measured on a live system and it would depend on several configuration values:
- Number of transactions per block (if I remember correctly, current default value is 1000) - the larger the blocks are the better the throughput (tx/sec) but latency (confirmation time) takes a hit.
- Committee size - how many different validators participate in the consensus of a specific block (current value IMO is 22)
- The physical location of these validators (eg. AWS region) and how strong their connection is - validators are usually running on large data centers since every validator runs a cluster of multiple machines
This measurement will also provide us with the latency of the network (see below) because once a new transaction arrives, a new blocks will be closed as quickly as possible to hold it.
Another interesting number is how often the system will close empty blocks if there are no pending transactions. In this case, it doesn’t make sense to close blocks as quickly as possible because this will just waste resources (these are empty blocks). This number is currently about 10 seconds. You can see it on the live Prism: https://prism.orbs.network/vchains/1100000
Regarding tx per sec, we need to differentiate between tx/sec of the entire network vs. tx/sec of a single virtual chain (a single “shard”).
For a single shard, V1 without optimizations can reach about 400-500 tx/sec stable without dropping some client requests and aggressive stress tests showed even up to 900 tx/sec if you don’t mind that some client requests will fail.
So, if we have 100 live virtual chains, the tx/sec of the entire network is about 40,000-50,000 tx/sec.
The cool thing about the number of virtual chains is that it is dynamic - this means that new virtual chains can be created by apps on demand so resources aren’t wasted if they’re not needed. The network can hold a theoretically infinite number of them in parallel… also, if different apps run on different virtual chains, they will not compete over tx/sec and each will have its own guaranteed throughput.
I asked @IdoZ to share some measurements of latency, I don’t recall them off the top of my mind… latency is the sum of how long a tx is propagated between validators and how long the consensus takes to approve the block it’s in… should be below 1 second