Alex Crichton (Nov 30 2025 at 00:34): Alex Crichton (Nov 30 2025 at 00:34):unsure! I'd recommend reading func_environ.rs in wasmtime to get a better idea for how fuel is translated
Aarav Dayal (Nov 30 2025 at 00:48):@Alex Crichton Thank you so much! You were right!
Aarav Dayal (Nov 30 2025 at 00:52):I had another feature suggestion though. Why not track the fuel inside of the wasm binary itself as a global variable? It would be faster than doing host calls every then and now which will be usually slower (right?).
I saw I think wasmer doing this optimization.
Aarav Dayal (Nov 30 2025 at 01:12):Sent you an email as well. @Alex Crichton
Till Schneidereit (Dec 01 2025 at 13:17):if it's tracked inside the guest, then that means the guest can freely modify it, making it unreliable, no?
Aarav Dayal (Dec 01 2025 at 16:10):Till Schneidereit said:
if it's tracked inside the guest, then that means the guest can freely modify it, making it unreliable, no?
I think finding a non-colliding memory region that the program does not touch would work. Maybe a local variable somewhere.
Is there a way a program can walk through all of its local variables without knowing the name of the variable or not? If not then this should be fine.
Till Schneidereit (Dec 01 2025 at 16:44):what do you mean by "a local variable"? Apart from the stack, everything inside the guest can be fully inspected by the guest. The wasm specification establishes a sandbox where everything inside of it is meant to be accessible by the guest, and absolutely shouldn't be treated as trustworthy
Chris Fallin (Dec 01 2025 at 17:13):@Aarav Dayal what do you mean by
It would be faster than doing host calls every then and now which will be usually slower (right?).
I am not sure if you are imagining that Wasmtime's fuel metering does hostcalls to increment fuel, but it actually doesn't: fuel is a field in a VM-internal data structure that is directly accessed by the compiled code. We do a hostcall only when fuel runs out.
Aarav Dayal (Dec 01 2025 at 17:20):(I realised after reading Chris's message that my suggestion is not needed, please feel free to ignore this message)
Okay so from what I asked ChatGPT and understood from it atleast is that a wasm program will not compile if it tries to access a global variable that does not exist.
For example:
(module
(global $counter (mut i32) (i32.const 5))
(func $getCounter (result i32)
(global.get $counter)
)
(export "getCounter" (func $getCounter))
)
Now if I run a static analyzer and find a non colliding name / index for the global variable and use that as the fuel counter variable for a smart contract VM then it should be safe right?
This is with the assumption that the WAT / WASM does not import anything that the compiling host is not aware of. This is kind of the idea of a smart contract blockchain VM (it knows what is strictly available to the tenant).
Aarav Dayal (Dec 01 2025 at 17:21):Chris Fallin said:
Aarav Dayal what do you mean by
It would be faster than doing host calls every then and now which will be usually slower (right?).
I am not sure if you are imagining that Wasmtime's fuel metering does hostcalls to increment fuel, but it actually doesn't: fuel is a field in a VM-internal data structure that is directly accessed by the compiled code. We do a hostcall only when fuel runs out.
Oh yeah I literally looked at this yesterday! You are right sorry.
But can we make it faster by reserving a register for fuel metering instead? Would it actually worsen the performance of certain workloads as that workload could've benefitted more from an additional register or is the tradeoff just right enough?
Credits to -> https://github.com/bytecodealliance/wasmtime/issues/4109
Chris Fallin (Dec 01 2025 at 17:41):But can we make it faster by reserving a register for fuel metering instead?
The fuel variable is already register-allocated along with every other local value in the IR that we compile.
You're getting to the point of detailed suggestions that it would be a good idea for you to actually study the implementation in detail, look at the compiled machine code, and come to us with concrete suggestions based on what you see. I'd recommend not resorting to ChatGPT to fill you in on details here: our experience is that folks using LLMs to understand Wasmtime either come to us with bafflingly wrong (or "not even wrong") understandings or just get very basic suggestions that have already been considered and rejected.
Aarav Dayal (Dec 01 2025 at 17:46):Chris Fallin said:
But can we make it faster by reserving a register for fuel metering instead?
The fuel variable is already register-allocated along with every other local value in the IR that we compile.
You're getting to the point of detailed suggestions that it would be a good idea for you to actually study the implementation in detail, look at the compiled machine code, and come to us with concrete suggestions based on what you see. I'd recommend not resorting to ChatGPT to fill you in on details here: our experience is that folks using LLMs to understand Wasmtime either come to us with bafflingly wrong (or "not even wrong") understandings or just get very basic suggestions that have already been considered and rejected.
I am sorry for not providing helpful suggestions. I had to resort this time to ChatGPT as I am not a Rust developer.
I will personally go ahead and watch videos and content to actually understand the underlying architecture.
As of now I am committing to wasmtime as my underlying VM runtime as it seems to be the best choice for my tradeoff range.
Will come back to you asap if I have any good suggestions.
Sorry for wasting time of the contributors.
Chris Fallin (Dec 01 2025 at 17:53):No need to apologize! Trying to guide you toward productive paths if you want to contribute but there's nothing wrong with starting at a basic level. Best of luck
Aarav Dayal (Dec 01 2025 at 17:56):Thank you so much Chris.
Last updated: Dec 06 2025 at 06:05 UTC