@xgreenx came up with this idea.
We should look into making the block time here configurable for CI/testing purposes. In those environments most often only a standalone node is used anyway (so no consensus issues) and in the case of e.g. ink-waterfall the tests are often blocked waiting for the next block.
|
/// This determines the average expected block time that we are targeting. |
|
/// Blocks will be produced at a minimum duration defined by `SLOT_DURATION`. |
|
/// `SLOT_DURATION` is picked up by `pallet_timestamp` which is in turn picked |
|
/// up by `pallet_aura` to implement `fn slot_duration()`. |
|
/// |
|
/// Change this to adjust the block time. |
|
pub const MILLISECS_PER_BLOCK: u64 = 6000; |
By decreasing this to a way smaller value the CI's which are using this node could be sped up significantly.
@xgreenx came up with this idea.
We should look into making the block time here configurable for CI/testing purposes. In those environments most often only a standalone node is used anyway (so no consensus issues) and in the case of e.g.
ink-waterfallthe tests are often blocked waiting for the next block.substrate-contracts-node/runtime/src/lib.rs
Lines 107 to 113 in 82834b3
By decreasing this to a way smaller value the CI's which are using this node could be sped up significantly.