Why assert getChainId & fetch latest block on every send transaction?

[itsmnthn]

Wen sending a raw transaction with account(privateKeyToAccount) and walletClient with chain and http and passing nonce, maxFeePerGas, gasLimit and maxPriorityFeePerGas

contract.write({args: [], ...aboveOptions}
sends three rpc calls before sending a transaction or raw transaction

1. eth_chainId - already passed in chain object and it's static why waste of resources
2. eth_getBlockByNumber
3. eth_estimateGas

Already feeding all the required information why do double work and increase the latency of sending tx by 4x

I can send gasLimit to avoid eth_estimateGas, but
is there a way to avoid eth_chainId & eth_getBlockByNumber

[jxom]

Hi!

1. eth_chainId – this request is also called when a chain is passed to ensure the consumer doesn't mistakenly pass the wrong chain ID. Viem does validation to assert that the chain ID passed by the consumer matches the chain ID of the RPC. If some bug occurs within the consumer, this could lead to catastrophic consequences (user loss of funds). This is mainly here to safeguard the consumer if a chain ID related bug occurs on their end. Maybe we can have a assertChain flag consumers can pass to sendTransaction/write, but an eth_chainId call is typically (or should be!) free and fast.
2. eth_getBlockNumber: this is used to infer the type of transaction, and any related block fees. We can probably skip this call if type, maxFeePerGas, and maxPriorityFeePerGas is passed to the transaction. I pushed up a fix for this here: refactor: minimize redundant requests in prepareTransactionRequest #2021
3. eth_estimateGas: this can be skipped by setting a gas value

Let me know your thoughts on 1!

[itsmnthn]

I can think of these ways to handle eth_chainId

• Instead of asserting chainId at every transaction why not assert at http/transport level(fetch on init) and cache it for future use
  • assert passed chainId and http/transport if does not match fetch fresh to confirm or raise error

If the RPC has multi-chain support than handle that with configuration or something. I have no idea of how multi-chain rpc works or does viem support it, I think wallet connect v2 uses it to allow sending tx on multi-chain without switching network but that should be handled by their SDK.

• Add configuration to http/transport to take and chainId as an argument and if this exists than don't assert at all. Add configuration with warning/note to be care full with this config.

These my thoughts

Why do any of this?
Low latency is specially useful for the people who writes bots to Arbitrage or Market Make and DApp which uses browser wallets to improve trading experience

In ethers I could override the provider class and proxy the getChainId call to return static id when using dev configured RPC with this I can send tx as low as in 29ms

[itsmnthn]

I feel the transaction type can be added to optional configuration of chain or http/transport if configured or passed to tx params no need to fetch the block to decide the type of tx.

[itsmnthn]

Wow, thanks for the quick update, really helpful and much appreciated

[jxom]

You can also override Viem's getChainId with .extend:

const client = createClient(...)
  .extend(() => ({
    async getChainId() {
      return 1
    }
  })
)

[itsmnthn]

tried using

const wallet = createWalletClient({ account, chain, transport }).extend(() => ({
      async getChainId() {
        return chain.id
      },
}))

const contract getContract({
      address: useContractConfig().settler,
      abi: SettlerAbi,
      client: { wallet },
    })
    
const tx = await contract.write.settleFunds({
    args: [settlements],
    chainId: wallet.chain.id,
    gas: BigInt(300000), // 300k gas
    nonce: handler.nonce,
    maxFeePerGas: BigInt(handler.maxFeePerGas),
    maxPriorityFeePerGas: BigInt('0'),
    type: 'eip1559',
  })

still it makes rpc call to get chainId

Thanks to your recent release, block is not fetched now

[itsmnthn]

Also wanted to know what if I want to override/write a wrapper around method to send transaction so that I can extend it's behavior

Say I want to write a nonce handling for the privateKeyToAccount so that wen tx fails due to incorrect nonce it can be sent again (retry x times with newly fetched nonce) without throwing error before trying at least given time or 3 times.

[itsmnthn]

Finally figured how to avoid eth_chainId call wen using static rpc

const wallet = createWalletClient({ account, chain, transport }).extend(() => ({
     async getChainId() {
       return chain.id
     },
}))

viem's createWalletClient extends walletActions before I extend with getChainId was causing all the walletActions to use client without getChainId hence the sendTransaction was fetching always eth_chainid

writing custom createWalletClient that extends the client before extending the walletActions

import type { Account, Address, Chain, Transport, WalletClientConfig } from 'viem'
import { createClient, walletActions } from 'viem'

export function createWalletCustomClient<accountOrAddress extends Account | Address>(
  parameters: WalletClientConfig<Transport, Chain, accountOrAddress>,
) {
  const { key = 'wallet', name = 'Wallet Client', transport } = parameters
  let client = createClient({
    ...parameters,
    key,
    name,
    transport,
    type: 'walletClient',
  })

  if (parameters.chain) {
    const chainId = parameters.chain.id
    client = client.extend(() => ({
      async getChainId() {
        return chainId
      },
    }))
  }

  return client.extend(walletActions)
}

[jxom]

A bit annoying. We can add an assertChain property to writeContract, etc.

[itsmnthn]

Supporting nuances like this through configuration is always better

I don't see assertChain solving the problem.

Yes, you can, idk how it will play out or the side effects will be, but yeah, you are the master

[itsmnthn]

TOL

idk the scale of this behavior but some user extends applied after default extends can lead to unused user extends and vice versa as described above, again no idea how many are there

Having a list that describes which extends needs to apply before and which are needed after and passing before required extends as params may be gud thing