Is there a way to determine/calculate what the minimum block time would be? If not, what could we consider before lowering the block time, and how to monitor the side effects of small block time?
I know that there are lots of things to consider before doing this, but I just wonder about the possibility of the lower block times.
There is not a way to deterministically calculate a minimum block time, since it is ultimately a soft metric.
To help with your decision process, you should understand the breakdown of the current default Substrate block time of 6 seconds:
If you reduce the block time of your chain, you must reduce some of the assumptions above.
You can always reduce the amount of weight available per block, for example only allocating .5 seconds for block production and block import. However, you will reduce the amount of transactions you are able to do in a single block by 4x in this scenario.
It is not clear to me that you can similarly just reduce the overhead for network propagation, but it should also be clear that this metric seems incredibly hard to robustly benchmark. Nodes can be spun up anywhere in the world, with varying network capabilities and bandwidth.
By lowering the allocated network propagation time, you risk your network forking more often and likely create delays in finalization. Beyond that, in the extreme scenarios, it is unlikely your distributed network would be able to keep up with some milli-second block times.
Additionally, there are likely some overheads within the runtime / blockchain environment that we ignore due to how small they are relative to the block time. For example, there may be some processes which have a cumulative 100 ms delay that we are not currently measuring. Relative to the 6 second block time, this is only ~1.7% error, which is probably within any reasonable margin for error for these kinds of systems. However, if your block time was just 1 second, then this constant overhead now becomes 10%. This would probably be beyond what is acceptable margins for error. I am unaware of any such overhead that we are not tracking, but it is worth considering these kinds of non-scaling effects.
Finally, there is an optimization problem. Assume that you do reduce the network propagation to 1 second, while keeping computation at .5 seconds. That means for a 2 second block, you will get a total of .5 seconds of weight to work with. So 1/4th of your block time will be used for actual runtime logic. On the other hand, the default configuration gives 2 seconds of computation for 6 second blocks, which is 1/3rd of your block used for runtime logic.
Since it is not clear how aggressive you can get with the networking propagation delay, likely driving lower and lower numbers will actually be a negative return on how much your blockchain will actually be able to process.
That being said, all of these things are completely customizable on Substrate, and if you are working in certain controlled environments, like all nodes on a local network, you probably can push these numbers pretty hard. Testing and benchmarking of your Substrate network will be the only way to really determine how low you can safely get your block time.
