Pricing strategy for Host Functions and Storage #359
Assignees
Labels
type:enhancement
Issues concerning code or feature improvement (performance, refactoring, etc)
Comments
HDauven
added
the
type:enhancement
ureeves
added a commit
that referenced
this issue
May 15, 2024
Each byte stored in the WebAssembly linear memory of a contract is made to cost 4 units of fuel - in the units that wasmtime uses. This makes storing a single byte as expensive as, for example, multiplying or subtracting two numbers. The `MemoryGrow` instruction is purposefully left with the default price - just like any other instruction, due the fact that expanding the size of the linear memory doesn't actually cost a lot of resources, owing to the fact that a page that is never written to is never written to disk. A single contract's compiled bytecode will contain a header, encoding within it information about the cost per WebAssembly instruction. If these don't match the costs configured for the current `VM` instantiation, the contract will be recompiled, just as what happens if the native instruction set doesn't match. See-also: #359
ureeves
added a commit
that referenced
this issue
May 16, 2024
Host queries are modified to be able to specify their price. The calling of a such a query proceeds in two stages - deserializing and pricing, and then execution. In between the two stages, `piecrust` is able to make the choice of whether to continue with execution or not, based on the gas remaining for the execution. To achieve this, the `HostQuery` trait is modified by adding two functions - `deserialize_and_price` and `execute` - and by removing the `Fn(&mut [u8], u32) -> u32` bound. This structure allows the implementer to price queries fairly, as well as prevent double deserialization by leveraging `Box<dyn Any>` to pass data between the two functions. `HostQuery` remains implemented for all `Fn(&mut [u8], u32) -> u32` that are also `Send` and `Sync`, so this is not a breaking change. See-also: #359
Merged
Merged
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Summary
Currently, host functions do not have a "fair" price attached to them. Storage is priced solely based on the computation of memory allocation.
This approach is most likely not optimal as it does not account for the actual resource usage and the economic impact of host functions computational load and underpriced storage.
Possible solution design or implementation
To address this, we should figure out the computational complexity of host functions (Accounting for network load and implicit storage as well?) and figure out an optimum of storage versus computational cost. Ideas like expiration and rent can be considered, but would be out of scope for now.
The text was updated successfully, but these errors were encountered: