Recycle VM components in between host calls

[jayz22]

The VmInstantiation cost is by far the largest component in the host, due to the underlying cost of parsing the WASM contract and instantiating the VM. This will present bottleneck for contracts that make many cross-contract calls (e.g see #825 (comment)).

We could perform optimization such as caching parsed contracts between invocation/tx, or having the host own some shared VM components (e.g. Engine, maybe a version of Store) for all Vm instantiations to start from.

[jayz22]

I did a quick exploration on possibly sharing VM components between contracts to improve performance. There doesn't seems to be any low-hanging fruits there.

Even Engine can not be shared currently due to wasmi-labs/wasmi#631. The engine owns EngineResources for performance reasons and is locked when accessed from a Wasm contract. Calling another contract within a contract will attempt to access the same engine which results in a deadlock.

[jayz22]

Also, for the same reason caching parsed Wasmi module won't work either, because the module is coupled with the engine (which led to the creation of the wasmi-labs/wasmi#631).

[MonsieurNicolas]

Caching is probably doable in the context of a single transaction, but crossing transaction boundary is probably fairly challenging:
as cpuInstructionCount is a non refundable resource, we'd have to come up with some scheme that allows to reason at the tx set level (to also divide up fairly the cost of instantiation between transactions).

If we were to do it at the transaction level only, I am not sure the benefits would be there.

[graydon]

We got some feedback today that some contracts want to call other contracts repeatedly (eg. to inquire about the balance of multiple accounts) and so in this context a "first cross contract call to X is charged instantiation, subsequent calls are charged only a cheaper no-module-parsing / cached-instantiation" model makes sense (it's not sensitive to transaction order or anything).

[graydon]

Fwiw I think we should do this before final, but perhaps a little after we have instrumentation sufficient to quantify the win, so sometime over the summer. It'll be an XDR change (to add a new cost type for cached instantiations) but otherwise the only user visible effect should be things get cheaper.

[graydon]

(I've just set this to preview 10 and assigned to @jayz22 but that is just for the XDR change -- we can do the rest later)

[anupsdf]

FYI, the XDR change for a new ContractCostType::VmCachedInstantiation has been done. The remaining work in env is non-protocol breaking, so can be done after v20 stable release package is out.

[jayz22]

As per discussion today, we will be adding the necessary data structure for storing contract IDs and control flow for charging VmCachedInstantiation for calls to a known contract. This will give us freedom to implement the caching logic later, without breaking the protocol.
One of the main risks of this work is surprises from Wasmi side, e.g. not allowing certain things to be cached (see above). The risk of stale/polluted data is lower.

[jayz22]

Bumping prio to P0 for adding in the charging control flow. Once done will reduce it back for the actual caching implementation.

[namankumar]

What is our latest thinking on what to cache? Trying to determine the low hanging fruits while maximizing benefit to the user.

Got ecosystem feedback today:

Shared server cache for recently used contracts. So, for example, the first user pays a full fee of contract loading, while all subsequent calls from other users are much cheaper while the contract remains in cache (ideally, at least for several minutes).

[roman-karpovich]

It would be big improvement to cache contracts at least within single operation as first step. There are use-cases when we need to invoke reasonably limited amount of sub-contracts deployed using single wasm code.

[graydon]

concerning the deadlock above, I think the most likely-to-work (and not be horribly ugly) solution to this is to pre-parse all modules in the footprint of a given transaction, before we begin executing any. on the one hand it means there's a possibility of "charging someone for work they don't ultimately use" (eg. if they mention a module in their footprint but then, due to some conditional logic in the contract, ultimately never call that module); on the other hand it's a simple model to reason about, and I expect the great majority of cases will benefit from the caching and not be punished by the eager parse (i.e. they will only mention contracts in their footprint that they're actually going to call).

[graydon]

Fixed by #1359 and #1375