State-key simulation for calling a program

[richardpringle]

Currently, a HyperVM requires that all state-keys are specified in advance, even if the state-keys if state-keys for the same call can change between blocks.

I see a spectrum of solutions for this

1. Make the node (likely an API-node) do the simulation with an RPC-endpoint to perform the whole simulation
2. Where a full simulation isn't needed, a convention could be used such as:

#[public]
pub fn my_func(context: Context, args: Args) // ...

#[public]
pub fn my_func_state_keys(args: Args) -> Vec<StateKey> // ...

Where the my_func_state_keys function with the same argument signature could return the set of state-keys.

3. Make the client do the simulation work, providing the client the runtime that plugs into a node via rpc

There are trade-offs to each, will discuss in the comments below

Note:
Just to be clear, this is not necessarily directly related to #736. It could be affected by decisions made there, though.

[richardpringle]

1. Make the node (likely an API-node) do the simulation with an RPC-endpoint to perform the whole simulation

I don't love this because it seems so wasteful, and the HyperSDK is all about efficiency. I get that it's something we may want to do anyway, but I'm thinking that we don't want this for every single program interaction.

[richardpringle]

I think @joshua-kim mentioned offline that we could probably memoize the responses based on the inputs and the state. That would help with the efficiency a little.

[aaronbuchwald]

Short term, this seems like the simplest to get it working. Longer term, the cost of simulating a transaction seems reasonable to me for an individual user (this is a common flow for most Ethereum wallets and the good ones even show users the simulated result to make a better UI and potentially protect users from exploits before confirming the transaction).

The part I'd be more concerned about is the result differing from the simulation causing user txs to fail

[richardpringle]

2. Where a full simulation isn't needed, a convention could be used such as:

I also don't love this. I feel like it's not foolproof

[richardpringle]

3. Make the client do the simulation work, providing the client the runtime that plugs into a node via rpc

I find this solution to be the most... interesting?

We make an RPC endpoint for getting the state at any particular key, then have the client/end-user run the simulation to generate the keys. Build and sign the transaction once. We will probably want an endpoint like this anyway such that program-authors can just delegate to this endpoint instead of having to write getters themselves.

[aaronbuchwald]

Hmm, this also seems to place the most responsibility on the user

[richardpringle]

It does... but the flow doesn't necessarily need to change.

const { stateKeys } = await program.call({ ...transactionDetails });
transactionDetails.stateKeys = stateKeys;
const signedTransaction = wallet.sign(transactionDetails);

const { result } = await program.send(signedTransaction);

So this would probably be the flow for both (1) and (3), but the difference is what happens with that call method. If we ship client-code with a simulator baked-in, we could do it either way.