search

Joystream / joystream

Joystream Monorepo
http://www.joystream.org
GNU General Public License v3.0
1.42k stars 115 forks source link

Reduce block time #5032

Open bedeho opened 8 months ago

bedeho commented 8 months ago

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.

kdembler commented 8 months ago

For reference:

kdembler commented 8 months ago

@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).

bedeho commented 8 months ago

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?

kdembler commented 8 months ago

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