Fork contracts (or networks) lazy

[mfornet]

I see currently there is a way to import a contract from a different network, but it tries to load all the state in one run, failing if the storage is too large. I suggest a mechanism that allows lazy forks. Instead of loading all the state in one run, the state is downloaded lazily on demand. When some key of the state is accessed it goes to the RPC and download such entry.

This will allow testing large contracts on live state!

[ruseinov]

Looking at the current implementation - that'd require changing the Contract struct to know about the source network it represents.

Also, I'm not exactly sure what can be done lazily here, the current approach does this:

1. Creates an account view (1 query)
2. Retrieves WASM contract code
3. Imports a bunch of data through view_state.

I'm assuming that the only thing we care about loading lazily here is the latter (3). But it also looks like calling view_state on the Contract would want to load all the data at once anyway to show it: https://github.com/near/workspaces-rs/blob/1591a38916c6b9c0aa6cee6a3d1eb8ac9aa77240/workspaces/src/worker/impls.rs#L78 .

[mfornet]

Correct, only 3) needs to be done lazy. The method view_state could be extended such that it receives a prefix, and only loads the state that starts with that prefix. The inner method being called accept the prefix.

https://github.com/near/workspaces-rs/blob/1591a38916c6b9c0aa6cee6a3d1eb8ac9aa77240/workspaces/src/rpc/query.rs#L314-L322

[frol]

The problem, however is that nearcore cannot really tell if fetching by prefix will yield reasonable number of keys and thus the current implementation applies 50kb limit no matter if prefix is specified or now. Yet, with the advances in flat storage, this might be less of an issue nowadays, also, pagination is needed, which might be another way to solve this issue on nearcore side - only allow up to 100 keys per view_state request.