You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
With the introduction of the frame-omni-bencher binary we have the option to initialize genesis state with multiple methods.
The underlying implementation in benchmarking-cli provides options:
We can provide a runtime wasm blob with --runtime
a. If provided without --genesis-builder or with --genesis-builder=runtime, it will use the development preset of the WASM blob. This case breaks when used from polkadot-parachain, because in the CLI there we expect that a chain-spec is provided.
b. If provided with --genesis-builder=none, it will initialize with empty genesis
c. If provided with --genesis-builder=spec it will crash because no spec will be provided
We can provide a chain-spec with --chain
a. If provided without --genesis-builder=runtime, it will use the development preset of the WASM code that is included in the chainspec. This case is currently broken as the state we try to read from is not properly initialized here:
b. If provided with --genesis-builder=none, it will initialize with empty genesis
c. If provided with --genesis-builder=spec it will use the storage included in the chain-spec
There is also currently a difference between initialization form chain spec vs runtime preset. For runtime presets, we return OverlayedChanges, for chain-specs, we return Storage here:
The comment there says that this should be refactored to always return OverlayedChanges, but I propose we do the opposite and use Storage always. If we use OverlayedChanges read values will be invisible to the proof recorder, which will change the measured storage proof values. The real-world effect of this should be minimal since the measured values only come into effect when someone provides a custom --default-pov-mode, but I am not sure if anyone does that and what the use-case is. Still always using Storage should be the better solution.
TLDR: 1a and 2a are problematic and should be fixed. For the unification I already have some code prepared.
Based on my investigations and testing so far here, the OverlayedChanges and BenchmarkingState seem to cause problems. Therefore, I am in favor of not using them. However, there could still be a hidden bug related to OverlayedChanges, BenchmarkingState, or StateMachine.
With the introduction of the frame-omni-bencher binary we have the option to initialize genesis state with multiple methods.
The underlying implementation in benchmarking-cli provides options:
--runtime
a. If provided without
--genesis-builder
or with--genesis-builder=runtime
, it will use thedevelopment
preset of the WASM blob. This case breaks when used frompolkadot-parachain
, because in the CLI there we expect that a chain-spec is provided.b. If provided with
--genesis-builder=none
, it will initialize with empty genesisc. If provided with
--genesis-builder=spec
it will crash because no spec will be provided--chain
a. If provided without
--genesis-builder=runtime
, it will use thedevelopment
preset of the WASM code that is included in the chainspec. This case is currently broken as the state we try to read from is not properly initialized here:polkadot-sdk/substrate/utils/frame/benchmarking-cli/src/pallet/command.rs
Lines 601 to 606 in a34cc8d
b. If provided with
--genesis-builder=none
, it will initialize with empty genesisc. If provided with
--genesis-builder=spec
it will use the storage included in the chain-specThere is also currently a difference between initialization form chain spec vs runtime preset. For runtime presets, we return
OverlayedChanges
, for chain-specs, we returnStorage
here:polkadot-sdk/substrate/utils/frame/benchmarking-cli/src/pallet/command.rs
Lines 570 to 579 in a34cc8d
The comment there says that this should be refactored to always return
OverlayedChanges
, but I propose we do the opposite and useStorage
always. If we useOverlayedChanges
read values will be invisible to the proof recorder, which will change the measured storage proof values. The real-world effect of this should be minimal since the measured values only come into effect when someone provides a custom--default-pov-mode
, but I am not sure if anyone does that and what the use-case is. Still always usingStorage
should be the better solution.TLDR: 1a and 2a are problematic and should be fixed. For the unification I already have some code prepared.
cc @ggwpez
The text was updated successfully, but these errors were encountered: