feat(provider): multicall

[yash-atreya]

Motivation

Implementing a Multicall3 builder type

Solution

Uses a tuple based approach to add numerous (different) calls to the builder with type inference.

sol! {
     #[sol(rpc)]
     #[derive(Debug)]
     interface ERC20 {
         function totalSupply() external view returns (uint256 totalSupply);
         function balanceOf(address owner) external view returns (uint256 balance);
     }
}

let weth = address!("C02aaA39b223FE8D0A0e5C4F27eAD9083C756Cc2");
let provider = ProviderBuilder::new().on_anvil_with_config(|a| a.fork(FORK_URL));

let erc20 = ERC20::new(weth, &provider);
let owner = address!("d8dA6BF26964aF9D7eEd9e03E53415D37aA96045");
let multicall = provider.multicall().add(erc20.totalSupply()).add(erc20.balanceOf(owner));

let (total_supply, balance) = multicall.aggregate().await.unwrap();

• fix return type decoding - make it a flat tuple
• aggregate
• aggregate3
• aggregate3Value
• try* aggregate methods
• other util methods for fetching block context

PR Checklist

• Added Tests
• Added Documentation
• Breaking changes

[DaniPopes]

FYI alloy-rs/core#492 contains possibly useful stuff like TuplePush to flatten the tuple return type

[mattsse]

why does this need a standalone value arg?

[zerosnacks]

fyi: multicall3 does not support bubbling up of errors (or custom error forwarding for that matter) which will make it more difficult to debug

related: mds1/multicall#146

[mattsse]

lgtm, pending @DaniPopes and @klkvr

[mattsse]

hmm, this is the first time we do it like this and not use the client.

for mutlicall we def need the provider because we need its functions

[klkvr]

lgtm!

[DaniPopes]

should change the doctests to no_run so we make sure they compile

ah actually these would have a circular dep

[yash-atreya]

Yep! Won't compile