I see that the DB weights (Rocks or Parity) are directly imported as constants in the runtime code. This means that whenever the runtime is built, it will use those constants. Why was this approach taken, since the runtime does not "know" which database is actually used by the hosts?
1 Answer
The database weights used by the runtime is defined in your FRAME System configuration.
https://github.com/paritytech/polkadot/blob/master/runtime/polkadot/src/lib.rs#L172
type DbWeight = RocksDbWeight;
So in this case, you tell the runtime which database your clients are using, and all the weights will be correct for that database.
answered Jul 11 at 20:41
-
Thanks for answer. I am aware how they are used. My question was related to why this approach was taken. Why couldn't the db weights be imported as a function from the host, since the runtime does not know which db is used, it only calculates weights. On the other hand, if the db weights are imported by the host, I guess whenever these db weights are updated, it will be difficult to update all the hosts at the same time and transactions might begin being rejected/failed from other nodes. Is it expected db weights to be updated at all?– limeJul 12 at 5:55
-
This is logic handled and configured in the runtime, and must be in consensus with the whole network. For example, if you run Parity DB, but the network is configured for Rocks DB, you must still use Rocks DB weights, else your network will fork. DB Weights are completely configurable by the user, you could build a substrate chain using your own custom database, and configure your runtime for those weights. We have a benchmarking pipeline build into FRAME benchmarking to help calculate that. If you have more questions, you should ask a more specific question in a new thread.– Shawn Tabrizi ♦Jul 12 at 13:07