Reintroduce way to read data from the chain

[danielbate]

Previously we had both get and call methods when interacting with program types. Under the hood the only difference was that get would not fund the transaction. This made it appropriate for reading data from the chain without side effects.

In the [email protected] upgrade, a new transaction validation rule was added, requiring inputs to have at least one spendable input or message. This made get redundant as all transactions required funding to be considered valid, even if nothing was being spent. Therefore if a wallet without coins was attempting a transaction, even just to read data, it would throw a NoSpendableInput error. A current workaround is to call fundWithFakeUtxos on the request however this is rather hacky.

We should reintroduce a recommended approach for reading data from the chain.

[Dhaiwat10]

Don't you think anything we come up with to get around this problem is going to be hacky unless the client exposes an endpoint that ignores these new TX validation rules?

[xgreenx]

First of all, it is not the right pattern to dry-run transactions to get the internal state of the contract. It is not a production solution and only fits for testing purposes.

This issue is related to more general issue regarding all validity rules that fail the execution or validation of the transaction. But we don't have plans to work on it before mainnet since it may bring vulnerabilities.

Regarding the rule that each transaction should have at least one spendable input: The primary use case for a dry run is to validate the execution of the transaction before actually sending it to the blockchain. Since blockchain always charges users, there should always be an input that will pay a fee. If you have use cases when you don't know who the sender is or which input to use, it is okay to use a placeholder("fake") coin to pay for the transaction. It is the reason why the utxo_validation = false exists. This placeholder input will later be replaced with a real one.

So, from the API perspective, you should be able to provide a method that doesn't require the Wallet since you can create any coin with any fields in the place where you want to do a dry run to get the state.

[arboleya]

As discussed, we can re-add the get method and use fake utxos to ensure the transaction goes through.

We must document everything well to disambiguate the purpose of each method since this will leave us with four methods:

• get
• dryRun
• simulate
• call

Later on, we can try reducing these to get and call and have some optional argument flags in the latter, to change internal behavior while keeping a similar signature, i.e.:

/*
  Call - accepts optional flags
*/
call({ ..., dryRun: boolean, skipUtxoValidation: boolean })
// - Requires Wallet
// - Never use fake UTXOs

// valid calls
call({ ... }) // = default
call({ ..., dryRun: true }) // current simulate
call({ ..., dryRun: true, skipUtxoValidation: true }) // current dryRun

// invalid calls
call({ ..., skipUtxoValidation: true }) // throws error (requires dryRun=true)
call({ ..., dryRun: false, skipUtxoValidation: true }) // throws error (requires dryRun=true)

/*
  Get - requires no special flags
*/
get({ ... })
// - Do not require but can receive a Wallet
// - Always use fake UTXOs (accounts for lack of balance)