EEI: add metering of memory

[axic]

No description provided.

[axic]

Actually this could be implemented in the metering process by

(call $useGas
  (i64.mul
    (i64.const <instruction gas>)
    (i64.mul (i64.const <memory cost per page>) (current_memory))))

Though the two muls could be precomputed into one. I'd say this wouldn't have any lower overhead then doing it in the interface, but does remove possibility to adjust memory cost after metering.

[chfast]

1. Shouldn't it just charge for "added" memory pages instead of charging for all of them each time?
2. In the comment you have <instruction gas> * <memory cost>. Shouldn't it be +?

[axic]

The idea here is to charge for memory pages for the given time those are alive. The time dimension is metered by instruction gas (eg how many cycles it takes). In every block the entire available memory is charged for the duration it is required.

This is an idea @wanderer and I discussed and removes the need for the quadratic memory cost rule.

[chfast]

Yes, I noticed it will be some-way quadratic.

[chfast]

1. Shouldn't it just charge for "added" memory pages instead of charging for all of them each time?
2. In the comment you have <instruction gas> * <memory cost>. Shouldn't it be +?

[chfast]

Is the "gas left counter" kept outside of the WASM?

[axic]

It is kept in the VM.

[chfast]

I see here one problem, the takeGas function does not provide any reference to the current VM execution context. How would a VM handle this in concurrent environment?

[axic]

There are no references in any of the methods. Each contract has its own instance, it is an implementation detail in VM how to add the context to the methods.

[chfast]

How is Hera doing it?

[axic]

There's an instance of the methods for each execution (follows the sample way binaryen gives). It can be optimised though, but shouldn't affect the interface.

[axic]

A relevant old issue: ewasm/wasm-metering-old#1

[poemm]

I think that useGas for memory should be injected in two places: i) at the beginning of the main function to charge for pre-allocated memory in the memory section, and ii) before each memory.grow Wasm opcode. The cost for each memory page should reflect zeroing-out a 64kB page. memory.grow should be more expensive since it is done at run-time.

To prevent resource exhaustion, we can have either i) a sentinel validation rule that the memory section must have a max e.g. 1024 memory pages, or ii) an algebraically or exponentially growing memory gas cost. The second option makes gas cost known only at run-time, which is undesirable.

Any other options or ideas?

[lrettig]

s/with/by/

or

"the amount by which to reduce the remaining gas counter"