joystream
joystream copied to clipboard
Joystream
Reduce block time
Currently, we have a 6s block time, I suspect this is quite arbitrary, and that it may be safe to reduce it, also possibly reducing max block weight of each block, as we likely are very far from exhausting that also. This will give us lower finality time, and will very much help the UX of Atlas, which currently is a bit rough around doing key transactions. Safety bounds on block time likely depend on assumptions around size of validator set, network latency, etc. so getting to the bottom of this is not trivial. I do believe there are examples of chains in both the Cosmos and Substrate ecosystem which have significantly reduce the default block times.
For reference:
- https://github.com/Joystream/joystream/issues/4791
- https://substrate.stackexchange.com/a/3030
@bedeho apart from whether this is a good idea or not (separate discussion), considering that everything points to the fact that reducing block time would require launching a new network instead of upgrading, I don't think doing so is feasible any time soon (definitely not the next runtime upgrade).
Totally happy with that, there are also ways of improving this at the app layer, and it will also increase processing load in indexers, as there is plenty of block level overhead. I was not aware that it def. required an upgrade, but it does not surprise me, how did you determine that?
Agreed that we can do much more on the app level. The latest version of Subsquid for example, has sub-second latency and automatically handles reorgs, reverting writes to the DB and replacing with the correct ones.
I was not aware that it def. required an upgrade, but it does not surprise me, how did you determine that?
Check last 3 comments from https://github.com/Joystream/joystream/issues/4791