[TASK] Investigate why we call `eth_getTransactionByHash` RPC so many times

[shekohex]

Overview

Using Infura Stats, we noticed that we call eth_getTransactionByHash a lot, which is indication that there is a room left here to improve the number of RPCs we send.

Task Checklist

• [ ] Explore a way to get metrics from ethers-rs (using the tracing logs for example)
• [ ] Propose a way to lower the number of RPCs
• [ ] Add tests (if required)

[salman01zp]

While processing the EVM Tx queue here every send_transaction method calls get_transaction to obtain the pending state of the transaction using a polling mechanism with some interval For more details on PendingTransaction refer here.

 async fn get_transaction<T: Send + Sync + Into<TxHash>>(
        &self,
        transaction_hash: T,
    ) -> Result<Option<Transaction>, ProviderError> {
        let hash = transaction_hash.into();
        self.request("eth_getTransactionByHash", [hash]).await
    }

Maybe we can try increasing polling interval here Will try running some tests

[salman01zp]

@shekohex can you share the count log for the eth_getTransactionByHash method for each chain? I think this count is related to block-producing time.

The default polling interval is 7 sec, we can set it to block_time/2

let mut provider = Provider::new(retry_client);
// Todo set interval to `block time / 2`
provider.set_interval(Duration::from_secs(interval));

[shekohex]

It's configured to be 7s. What happens if we used websockets?

[salman01zp]

Yeah, using WebSockets does reduce RPC usage. We can use ws-provider just for tx-queue but there will be cons if the connection is closed and subscriptions are dropped.

pub enum WebbProviders {
    Http(Provider<Http>),
    Ws(Provider<Ws>)
}

[shekohex]

Yeah, using WebSockets does reduce RPC usage. We can use ws-provider just for tx-queue but there will be cons if the connection is closed and subscriptions are dropped.

The connection should be restored if we did return an error in the tx queue, since the queue is running in a retry task. Also, I do assume we can wrap the client in a retry client, so it will retry to reconnect for example.