If I'm running a benchmark and I get the current block number from inside the benchmark code (i.e. in the setup before I actually call the call I'm trying to benchmark) using frame_system::Pallet::<T>::block_number() the block number I get is 0.

Then within call I'm trying to benchmark I get a block number of 1.

I'm assuming the benchmark setup code is run like / after genesis, in block 0, and then the chain progresses to 1 for the calls?

Not exactly clear why this is the case if I haven't told it to progress, especially because you do have to explicitly tell the TestExternalities in a test that you are at block 1.

1 Answer 1


Your observation is correct that the block number is being set to 1 if it is 0 between the setup and call phase. This is confusing and should be improved, I opened substrate #12559 for that.

The current safe way of doing it is to always set the block-number in the setup phase of the benchmarks to something non-zero. Eg:

block_does_not_change {
}: {
    assert_eq!(frame_system::Pallet::<T>::block_number(), 2u32.into());

In this case it will not be modified.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.