State override support for eth_call and eth_estimateGas

[kostyamospan]

Currently, the next scenarios are impossible to implement using Viem:

• estimate gas for token transfer without a need to make an approval before
• simulate a state-changing function in cases, when from doesn't meet the contract`s requirements (like the user is not whitelisted, or the token balance is insufficient)
• extend the functionality of already deployed contracts to be able to get some necessary data for the frontend (like an array getter, or customs multi-call for data that depends on each other)

This is quite sad, because Ethers supports it, and in the case of Viem I needed to write a custom implementation of the provider.call() method just to be able to make a static call to function without making an approval before

That can be achieved by passing the state override parameter in eth_call and in eth_estimateGas RPC methods

https://geth.ethereum.org/docs/interacting-with-geth/rpc/ns-eth#eth-call

[jxom]

Can look at getting this into the first-class APIs (call, simulateContract, etc), but can you use a raw eth_call for now (ie. client.request({ method: 'eth_call', params: [{ ... }, 'latest', overrides] })?

[kostyamospan]

Parameters type for eth_call takes only 1 or 2 parameters (link to code)

It's possible to use it if we would cast the parameters array to any, like this client.request({ method: 'eth_call', params: [{ ... }, 'latest', overrides] as any}), but its just a workaround

[zerosnacks]

I've had to add a workaround in a project that needed state overrides in eth_call to optimistically apply approvals during simulation and would love to see out-of-the-box support.

Overrides would be an optional Object with an arbitrary key => value mapping.

  /**
   * @description Executes a new message call immediately without submitting a transaction to the network
   *
   * @example
   * provider.request({ method: 'eth_call', params: [{ to: '0x...', data: '0x...' }] })
   * // => '0x...'
   */
  {
    Method: 'eth_call'
    Parameters:
      | [transaction: Partial<TransactionRequest>]
      | [
          transaction: Partial<TransactionRequest>,
          block: BlockNumber | BlockTag | BlockIdentifier,
        ]
      | [
          transaction: Partial<TransactionRequest>,
          block: BlockNumber | BlockTag | BlockIdentifier,
          overrides: any,
      ]
    ReturnType: Hex
  },

We will possibly need to account for another case without block but with overrides.

One possible concern is that it is considered a non-standard feature of Geth, Erigon and Reth but an incredibly useful one, especially for frontends.

Happy to contribute / collaborate on a PR if there is interest in the feature.