In webassembly spec, memory.grow has no immediate number parameter, only consume the i32 element in stack top as the page size to grow. Currently in wasm-metering, memory.grow is treated as a "branch" instruction, and charged only by its appeared times, not including its page-size params. I understand it's impossible to get the run-time stack info when statically analysing a wasm file. But is there a more reasonable way to keep the "memory.grow" monster into the cage ?
I have a proposal, if we set the max-size of the memory's page size as a must value and a concrete value(take 1000 for example) before the metering work, is it more reasonable when we only count the appeared times of "memory.grow" ? In detail, in the wasm file's memory section, if max is not set, we set it to 1000, if max is larger than 1000, then failed it as a unqualified contract, if it's smaller than 1000, then we do nothing.
In webassembly spec, memory.grow has no immediate number parameter, only consume the i32 element in stack top as the page size to grow. Currently in wasm-metering, memory.grow is treated as a "branch" instruction, and charged only by its appeared times, not including its page-size params. I understand it's impossible to get the run-time stack info when statically analysing a wasm file. But is there a more reasonable way to keep the "memory.grow" monster into the cage ?
I have a proposal, if we set the max-size of the memory's page size as a must value and a concrete value(take 1000 for example) before the metering work, is it more reasonable when we only count the appeared times of "memory.grow" ? In detail, in the wasm file's memory section, if max is not set, we set it to 1000, if max is larger than 1000, then failed it as a unqualified contract, if it's smaller than 1000, then we do nothing.