search

Joystream / joystream

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

Faster block time? #4791

Open bedeho opened 1 year ago

bedeho commented 1 year ago

I think I read somewhere that the 6s block time was partially, or entirely, from constraints that derive from being a parachain, and that the consensus algo in Substrate safely can have substantailly lower block intervals even with large validator sets. We should def. inspect this, as it impacts UX a lot.

traumschule commented 1 year ago

Good idea. The speed improvement would probably outweigh higher validation costs due to increased disk space and slower syncing.

The maximum number of blocks in a single batch currently depends on the @subsquid/substrate-gateway implementation. Currently there are two main components that affect the size of the returned batch: the time it takes to read & prepare a batch (by the gateway) is limited to 5 seconds the size of the batch is limited to "1 MB", however, this depends on some assumptions about "average" event/call/extrinsic size, so the actual final batch size may be much greater (SubstrateBatchProcessor)

bedeho commented 1 year ago

Good idea. The speed improvement would probably outweigh higher validation costs due to increased disk space and slower syncing.

If you have cycles to look into this, please do <3

mnaamani commented 1 year ago

We currently use 1s block interval in integration tests. We have a version of the runtime that can be compiled to have 1s block interval, by having different values for MILLISECS_PER_BLOCK and SLOT_DURATION and EPOCH_DURATION_IN_BLOCKS

https://github.com/Joystream/joystream/blob/master/runtime/src/constants.rs#L24

We have experienced test/staging chain getting bricked in the past doing a runtime upgrade where we didn't maintain the same constants. This is why in the runtime-upgrade integration tests, to get around this problem we use the testing runtime but when we take a snapshot of the production chain we filter out the babe pallet (among other consensus related pallets) state.

The BABE pallet clearly mentions that "Currently it is not possible to change the epoch duration after the chain has started. Attempting to do so will brick block production." - https://github.com/paritytech/substrate/blob/075ba84345c58611beaf8b3effcd321db5a92f6b/frame/babe/src/lib.rs#L121

Ehe epoch duration configuration is in slots. https://github.com/Joystream/joystream/blob/cc43a96c15cb16f01cca6c47752444a8863e6fc3/runtime/src/lib.rs#L307

I think we have also tried keeping the duration constant (number of slots) but that still bricked the chain. So its not about the number being constant but more fundamentally about the real time interval needing to be constant?

It seems to me that it is not possible to change the interval unless we start a new chain.

mnaamani commented 1 year ago

It seems to me that it is not possible to change the interval unless we start a new chain.

https://substrate.stackexchange.com/questions/1034/how-to-change-the-era-period/1035#1035

This confirms it:

In BABE, the EpochDuration config member is used to set the number of slots (and therefore the amount of time) in a session. This can only be set in the genesis. The actual parameters given to BABE which determine the block time are in the epoch_config field of pallet_babe's GenesisConfig.

mochet commented 1 year ago

Coincidentally just came across a blog post from a substrate project that changed the blocktime via runtime change and it resulted in breaking the chain: https://www.t3rn.io/blog/testnet-halt-lessons-learned