feature: ProviderCall

[prestwich]

Closes #736

Motivation

Allow providers to get outputs from arbitrary sources, including synchronous

Solution

• Add a ProviderCall future that wraps 4 data sources (rpc, batch rpc, other future, ready)
• change provider return types
• change inner type of eth call and with_block

drive-by:

• generalize into_owned_params
• alphabetize some mod defs
• improve mapping internal to rpccall
• add map to waiter

PR Checklist

• Added Tests
• Added Documentation
• Breaking changes

[mattsse]

makes sense,

this is still easy to follow imo

[prestwich]

the main problem right now is figuring out how to integrate it into WithBlock and EthCall 🤔

[yash-atreya]

hey @prestwich

Taking this over, need it for #954

[yash-atreya]

hey @prestwich

Taking this over, need it for #954

Would appreciate it if you have any pointers on how to move forward from here.

I think only integrating ProviderCall with RpcWithBlock and EthCall remains?

[klkvr]

I think we can now unify Caller impls for WithBlock and EthCall? or maybe just do impl Caller for WeakClient<T>?

[yash-atreya]

I think we can now unify Caller impls for WithBlock and EthCall? or maybe just do impl Caller for WeakClient<T>?

impl Caller for WeakClient<T> makes sense

[klkvr]

@yash-atreya one thing I find a bit confusing here is that by design of Caller it does not receive more context than a RequestPacket we are working with when overriding transport layers.

I think one valid usecase for this PR is for example changing Provider implementation to reading storage slots from some other source for get_storage_at requests. Currently this would require implementing a custom Caller which would manually deserialize eth_getStorageAt params to determine address, slot and block which adds an additional fallible step which wasn't required earlier when those methods returned just TransportResult

I think what we want for WithBlock is something that can produce a ProviderCall given a block_id: BlockId, and also is able to capture context such as Params. This is essentially fn(BlockId) -> ProviderCall, though we'd likely need more concrete type here to handle lifetimes in cases of borrowed rpc call params

[yash-atreya]

@mattsse I believe this can be merged now

[mattsse]

I think this should work now,

mind giving this another close look @klkvr ?

[klkvr]

@yash-atreya wondering how do we decide which Provider methods return ProviderCall vs do async fn -> TransportResult<...>?

[yash-atreya]

@yash-atreya wondering how do we decide which Provider methods return ProviderCall vs do async fn -> TransportResult<...>?

Sorry for the delayed response.

TransportResult is also overridable like ProviderCall.

I believe subscribe/watch methods should be TransportResult since they return PollerBuilder, similar logic applies to send_tx_* methods.

Also, any RPC method where we accept a parameter by reference, should be TransportResult since replacing it with ProviderCall will introduce lifetimes. eg. get_fee_history

Rest can be made to return ProviderCall.

Should extension traits such as AdminApi, TraceApi etc. be moved to ProviderCall as well?

@mattsse wdyt?

[klkvr]

Also, any RPC method where we accept a parameter by reference, should be TransportResult since replacing it with ProviderCall will introduce lifetimes. eg. get_fee_history

Lifetimes should be fine, we already have them in e.g. estimate_gas

Should extension traits such as AdminApi, TraceApi etc. be moved to ProviderCall as well?

We are already using RpcWithBlock in TraceApi, so I wouldn't say that those aren't tied to provider already. Though I can see how changing their returns types to ProviderCall might break usecases unrelated to provider

[yash-atreya]

Lifetimes should be fine, we already have them in e.g. estimate_gas

We want to avoid introducing lifetimes in the trait as much as possible, eth_call and estimate_gas are exceptions since the addition of EthCall.

how changing their returns types to ProviderCall might break usecases unrelated to provider

+1

[klkvr]

given we're now wonly using this for EthCall, I think we should make it more call-specific, eg make it accept TransactionRequest, block and overrides directly to allow implementations to directly call underlying evm with them.

[klkvr]

lgtm overall, just a note on Caller trait, we can address this in a follow-up