Currently Wasmi support fuel metering of its internal Wasmi bytecode.
The fuel is metered to the Wasmi bytecode that is resulting after the entire translation process with all the optimizations.
This means that Wasmi's fuel usage usually is less than the fuel usage of a hypothetical Wasm VM that executes Wasm bytecode directly because a single Wasmi bytecode instruction may represent multiple Wasm bytecode instructions and the Wasmi optimizer might even remove whole blocks of Wasm bytecode entirely.
Some users face problems with this approach: namely when wanting to switch to a new Wasmi version and having the requirement that code executed with the new Wasmi version runs out of fuel at the same time as the older version. This is not guaranteed with the current fuel metering approach since even a single new Wasmi bytecode optimization might change the big picture.
Solution
To resolve this issue for users we might want to introduce a new fuel metering approach that we call "stable fuel metering" because it guarantees a stable fuel consumption throughout Wasmi versions. The trick is to apply fuel usage to the input Wasm bytecode instead of the resulting Wasmi bytecode. This might lead to more fuel consumption but should always consume the same amount of fuel for the same Wasm binary and execution independent of the Wasmi version used.
Research
Research is needed to know when this "stable" fuel metering will still result in different fuel consumption with the same Wasm binary and different Wasmi versions so that we can either eliminate these situations or clearly document them.
Currently Wasmi support fuel metering of its internal Wasmi bytecode. The fuel is metered to the Wasmi bytecode that is resulting after the entire translation process with all the optimizations. This means that Wasmi's fuel usage usually is less than the fuel usage of a hypothetical Wasm VM that executes Wasm bytecode directly because a single Wasmi bytecode instruction may represent multiple Wasm bytecode instructions and the Wasmi optimizer might even remove whole blocks of Wasm bytecode entirely.
Some users face problems with this approach: namely when wanting to switch to a new Wasmi version and having the requirement that code executed with the new Wasmi version runs out of fuel at the same time as the older version. This is not guaranteed with the current fuel metering approach since even a single new Wasmi bytecode optimization might change the big picture.
Solution
To resolve this issue for users we might want to introduce a new fuel metering approach that we call "stable fuel metering" because it guarantees a stable fuel consumption throughout Wasmi versions. The trick is to apply fuel usage to the input Wasm bytecode instead of the resulting Wasmi bytecode. This might lead to more fuel consumption but should always consume the same amount of fuel for the same Wasm binary and execution independent of the Wasmi version used.
Research
Research is needed to know when this "stable" fuel metering will still result in different fuel consumption with the same Wasm binary and different Wasmi versions so that we can either eliminate these situations or clearly document them.