How much storage migration do you have time for per block?

Question

I am trying to come up with some practical bounds on how much storage migration one has time to do in a single block as part of a runtime upgrade.

So assume

• there are N validators running the current consensus system found in the Substrate setup, not as a parachain
• the nodes are running on decent civilian workstations
• the migration code is dominated by doing sequences of database reads/writes pairs, as well as the normal associate encoding/decoding logic
• the size of the data in each read/write pair is pretty stable, with M bytes on average

let f(N, M) be the number of read,write pairs you will be able to safely do in a single block when there is no other extrinsic handling.

What is a good guess at what f(N,M) looks like? just some decent answers for popular values of N (e.g 40) and M (e.g. 32, 1024).

I ask, because constraints around this will have to inform how a module is built to begin with.

Answer 1

First, why is N relevant here? the migration can happen at a particular block and the constrain is to be able to fit it inside the block time.

For this, I would recommend doing some micro benchmarking (in WASM) and getting an estimate of how much each operation costs. Put that next to your desired block time and you should have a good number. I would further reduce that to be safe as well.

Note that the type of the data migration does matter here; If you are storing values, this is fairly easy and I assume you should be fine, since the bottleneck is probably decoding, not hashing. If your value (say, a large vec) is already so big that it cannot be read + written once in a block, then you have much bigger problems. With maps, you have to take into account that you will do more state lookups, so the whole process differs.