near-runner needs a simple interface for grabbing contracts (and their state) from testnet as a starting point for sandbox tests/runs. Maybe this could look like:
[ ] grab the wasm bytes from the contract and deploy them to the local account, then use viewState on the testnet contract and use patchState locally to initialize the contract with that state.
[ ] throw intelligible error if contract state too large to be loaded in one viewState call
Edge case: contracts with state that can't all be fetched in one viewState call
1. [ ] Allow specifying block height at which to viewState so that contract developers can use the contract state as it was early in the contract's life – this is the fastest implementation, but it is unclear how usable this would be for contract developers.
2. Work with the JSON RPC team to add pagination to the viewState call.
3. Use off-chain indexer of some sort (indexer as a service?) .
4. Build some sort of mini-indexer into near-runner (get contract state for block height at which contract was deployed, then query RPC through all blocks from there to current, getting contract state changes and updating local Sandbox node with each).
5. Create an RPC testnet node which is used by default in near-runner and which sets the viewState limit (trie_viewer_state_size_limit) to something like 5MB. This might also be a fast implementation, but: 1. the node would be easy to DDoS, purposely or accidentally, and 2. people may want to customize their RPC node, leading to unexpected behavior.
6. When we have RPC-as-a-Service, we allow people to set the viewState limit to something much larger. The error thrown by near-runner provides instructions on how to use [RPCaaS](https://docs.google.com/document/d/1WNMhup_2ZQki10hGcleuRNsmyRAvYZIX3ohQAjs-xlY/edit) instead of the free default RPC endpoint.
near-runner needs a simple interface for grabbing contracts (and their state) from testnet as a starting point for sandbox tests/runs. Maybe this could look like:
Behind the scenes, this can
viewStateon the testnet contract and usepatchStatelocally to initialize the contract with that state.viewStatecallviewStatecallDue to gas limit, the maximum view call [can fetch 50 KB](https://docs.near.org/docs/api/rpc/contracts#view-contract-state). Many production contracts will have state larger than this. Current Ref Finance state size on testnet [is 2.8MB](https://explorer.testnet.near.org/accounts/ref-finance.testnet) and on mainnet [is 2.6MB](https://explorer.mainnet.near.org/accounts/v2.ref-finance.near).
What to do in this case? Options:
1. [ ] Allow specifying block height at which to
viewStateso that contract developers can use the contract state as it was early in the contract's life – this is the fastest implementation, but it is unclear how usable this would be for contract developers. 2. Work with the JSON RPC team to add pagination to theviewStatecall. 3. Use off-chain indexer of some sort (indexer as a service?) . 4. Build some sort of mini-indexer into near-runner (get contract state for block height at which contract was deployed, then query RPC through all blocks from there to current, getting contract state changes and updating local Sandbox node with each). 5. Create an RPC testnet node which is used by default in near-runner and which sets theviewStatelimit (trie_viewer_state_size_limit) to something like 5MB. This might also be a fast implementation, but: 1. the node would be easy to DDoS, purposely or accidentally, and 2. people may want to customize their RPC node, leading to unexpected behavior. 6. When we have RPC-as-a-Service, we allow people to set theviewStatelimit to something much larger. The error thrown by near-runner provides instructions on how to use [RPCaaS](https://docs.google.com/document/d/1WNMhup_2ZQki10hGcleuRNsmyRAvYZIX3ohQAjs-xlY/edit) instead of the free default RPC endpoint.