How should Account multicall work?

[martriay]

Signed list vs List of signatures

Should this function take a list of signed transactions ([(Signature, Message)]) or a signed list of transactions ((Signature, [Message]))? Probably the former is easier to implement, but the latter guarantees order and atomicity. Otherwise, a sequencer or some man-in-the-middle could partially send a subset of the intended list of transactions. More over, it could reorder/sandwich some of those calls to exploit it somehow, e.g. for MEV extraction.

Single execute function?

Should we have two different functions for single and multiple calls or should we have a single execute function supporting them both? Haven't thought about this one yet.

Reference implementation

Here's the reference Solidity implementation from Multicall.sol:

// SPDX-License-Identifier: MIT
// OpenZeppelin Contracts v4.3.2 (utils/Multicall.sol)

pragma solidity ^0.8.0;

import "./Address.sol";

/**
 * @dev Provides a function to batch together multiple calls in a single external call.
 *
 * _Available since v4.1._
 */
abstract contract Multicall {
    /**
     * @dev Receives and executes a batch of function calls on this contract.
     */
    function multicall(bytes[] calldata data) external returns (bytes[] memory results) {
        results = new bytes[](data.length);
        for (uint256 i = 0; i < data.length; i++) {
            results[i] = Address.functionDelegateCall(address(this), data[i]);
        }
        return results;
    }
}

[frangio]

I definitely vote for a signed list of transactions.

Do you see downsides to having two separate entry points? Is it more complicated to build a signed list of transactions, than a single transaction?

[janek26]

I do prefer the signed list of transactions for the reasons you mentioned, especially atomicity, as order can still be guaranteed by signing the nonce, but atomicity can not. Given that, I think having two different entry points would be cleaner :)

[martriay]

I was thinking of having a single entry point that takes a list of transactions, whose length can also be 1. I think this is easier to: implement, reason about, and integrate with. I'm biased towards simplifying the contract's API and codebase as much as possible.

[juniset]

I prefer as well a signed list of transactions for the reasons mentioned above. It also makes more sense with the get_tx_signature() introduced in Cairo 0.5.

I also like the idea of having 1 generic entry point accepting an array of transactions.

[bbrandtom]

Agree with the above. Also, note that breaking atomicity deviates from the Solidity implementation and behaves differently.