[Discussion] New FIP: Multicall as a Built-In Actor

[xBalbinus]

This is a proposal to add multicall as a built-in actor on the FEVM.

Motivation

In a nutshell, multicall enables calling multiple methods in a single call to the contract.

An example use case might be, you might need to gather synchronized data from the blockchain. A good example is querying token prices from Uniswap. You don't want to have the price for one token from block x and a price for another token at block y. Your data is thus guaranteed to be from one block.

Additionally, this reduces the number of separate JSON RPC requests that need to be sent over the network if using a remote node, and provides the guarantee that all values returned are from the same block. The latest block number is also returned along with the aggregated results.

Proposal

Multicall has the following key functionality, which accepts an input array of calls and simply iterates through these calls, reverting the whole batch call on any call that fails. The following Solidity snippet should be considered as a goal for what we want to have.

    struct Call {
        address target;
        bytes callData;
    }

    struct Result {
        bool success;
        bytes returnData;
    }

...

    function aggregate(Call[] memory calls) public returns (uint256 blockNumber, bytes[] memory returnData) {
        blockNumber = block.number;
        returnData = new bytes[](calls.length);
        for(uint256 i = 0; i < calls.length; i++) {
            (bool success, bytes memory ret) = calls[i].target.call(calls[i].callData);
            require(success, "Multicall aggregate: call failed");
            returnData[i] = ret;
        }
    }

Discussion

[scotthconner]

For public view, or pure functions - does the FEVM take a potential block height as an argument? Obviously for write calls you wouldn't be able to specify a block height other than the current tipset, but I'm wondering if, instead of doing the looping/scaling execution cost on a node that happened to get a multi-call, we simply allow the caller to provide a tip-set height that the read-only request is run at.

This has a few benefits:

• Clients can grab the current block height from the network, or specify an arbitrary block at a point in time potentially even in the past. This provides more control and flexibility than always running at the current block height (which may be different between nodes). In this way, there is some determinism as well as the block number would be known at call time and not required as a return value.
• If I needed to get, say, the Uniswap prices of 10 assets, I could make 10 asynchronous calls that could return/fail on their own merits. In the proposed implementation scenario, a single revert/call failure would fail the entire batch.
• Node operators (and thus the network) would have a more consistent read/memory/CPU load on their nodes which won't be dependent on the size and frequency of multi-calls they service.
• Node implementations wouldn't have to increase multi-threading logic to maintain low latency responses, or make requests run longer and keeping connections open more for serialized calls and additional potential for connections to be closed early.

I might be missing something in the proposal that invalidates the above. Willing to understand more how we are solving this problem (either for contract actors or clients).

[anorth]

I don't quite understand the motivations cited here, but I do think multicall would be really valuable (especially in combination with #388 - see the Discussion section). In brief, my proposal would be

1. Write and FRC defining an Execute(Call[]) method for generic execution of messages, and then
2. Via FIP, implement this method on the built-in Account actor

Then everyone gets multicalls, with a standard that wallet software can build to.

This is unrelated to anything about off-chain queries, JSON-RPC etc, for which I think the problem is already sufficiently solved or solveable.

[xBalbinus]

Right, I agree - minimizing RPC requests is more of a less significant side benefit to having a generic Execute(Call[]) method. The primary benefit here is for the UX of being able to do multiple things without waiting for each individual thing's block inclusion. The overhead of broadcasting a message would also be reduced the more things you tack onto the array of calls being executed, so that rather than doing things individually for each separate transaction, you do them all in one atomic function call.

[xBalbinus]

I was able to take a read through #388 and I also really like the proposal - this method should just be an addition to the Account actor

[laudiacay]

When do you think #388 is going to have work on it start?

[anorth]

We don't need to wait for it, but it's in the FVM team's scope since it couples VM with validation.

[laudiacay]

Strongly backing the @anorth suggestion... there's also an easy/totally separate Lotus API lift of supporting JSON-RPC batch- currently, I don't think lotus supports this. @amiller68 IIRC you ran into this, could you confirm?

@scotthconner that sounds sort of like Flashbots bundles- in Ethereum that's done at the block preparer level, I think that kind of feature might be the right move for Filecoin too once the ecosystem reaches MEV-tier maturity.