Delegated execution and multicalls

[anorth]

Motivation

Many on-chain interactions require messages to be sent to more than one actor. One common example is approving a token allocation before then calling another contract to use TransferFrom to pull tokens from the caller’s balance. Sending these as two separate top-level messages is a poor user experience, and requires two signature verifications. A multicall is a name for a mechanism where a single top-level message can make multiple invocations to different actors with only a single signature verification.

Independently, some applications would benefit from delegation of execution, where one party submits (and pays gas for) a message on behalf of another. A motivating example is the proposed direction creation of datacap allocations by clients in #730. In the current flow, SPs submit deal proposals that are internally signed by the client. A similar flow could be achieved for datacap allocations if the SP could submit an allocation message signed by the client. In some blockchains, the account abstraction mechanism is powerful enough to achieve that, but current plans for Filecoin (#388) are simpler. Filecoin can achieve a similar result with a standardised delegated execution method.

These two needs can be solved together, because delegated execution would also benefit from multicalls.

Proposal

Standardise a method for delegated execution and implement it in the built-in account actor. The same method may be implemented by smart-contract wallets in the future.

Edit 2023-06-26: added Value to Call.

// Specifies a single actor invocation.
struct Call {
    Receiver: Address
    Method: uint32
    Params: []byte
    Value: TokenAmount
}

// Specifies a sequence of actor invocations, and the behaviour
// if one call fails (exits with non-zero code).
struct CallSpec {
    Calls: Vec<Call>
    Failure: ABORT = 1 | STOP = 2 | CONTINUE = 3
}

// A specification of a sequence of calls, 
// and optional signature over that specification.
struct ExecuteParams {
    Calls: CallSpec
    Signature: Option<[]byte>
}

struct ExecuteReturn {
    Results: Vec<{Code: ExitCode, Value: []byte}>
}

EXECUTE_METHOD = FRC42_hash("Execute")

The Execute method makes zero or more invocations to other actors.

• If the caller is the receiver (e.g. an account sending to itself), does not require a signature. This permits multicalls.
• Otherwise, requires a signature over the CBOR-serialized call specification. This permits delegated execution: one party can submit and pay gas for a message that is executed by another.
  • Update 2023-06-26: we will need some kind of nonce to avoid replay of the signed callspec

The specified calls are executed in order. If one exits with a non-zero exit code, actor must either:

• ABORT: abort and propagate the non-zero exit code
• STOP: don’t abort, but do not invoke any subsequent calls, returning OK
• CONTINUE: don’t abort, and continue to invoke subsequent calls, returning OK

Note that Execute always exits with a status code of OK unless the failure handling is ABORT and a call fails.

The return value from Execute includes the exit code and return value from all calls that were executed. For calls that were not executed due to STOP failure semantics, the exit code must be FRC42_hash('ExecuteStop').

Discussion

Multicalls and delegated execution could be implemented as separate methods. Unless multicalls were also built-in to the delegated execution method (i.e. this proposal), a delegated multicall would require two levels of indirection: Delegate → Execute → Calls. If multicalls are built in to the delegated execution, a distinct multicall method is redundant.

For the cited use case of datacap allocations, an alternative to delegated execution is to build something directly into the verified registry actor whereby an SP could submit a signed voucher for an allocation that is checked explicitly by the verified registry. The proposed standard delegated execution method is a general pattern that could solve this problem for other, future use cases, without requiring explicit foresight and implementation for each one.

We need to decide whether to implement this method in the built-in multisig and EVMAccount actors too.

[Stebalien]

General feedback:

• I think users will likely want the ability to perform value transfers (native tokens). However, for top-level accounts, we should probably limit the total "value transferred" to the "value" listed in the top-level message (at least for now).
• I'd make sure to include codecs along with values.

[anorth]

Value transfer

Thanks for pointing out value transfer - that was an unintentional omission. I'll edit the OP to add it in.

I don't really see how limiting value transfer can be very helpful though. For delegated execution, it doesn't seem workable to have any requirement that the top-level message will make a value transfer to the delegate. The delegate has signed a message indicating a value to transfer - that's enough!

However, this does also highlight the need for nonces in such signed messages in order to avoid replay. This is a more serious omission and might be awkward to include.

For non-delegated multicalls, while I can see how a send-to-self with value could be used to redundantly specify a maximum value to transfer from the subcalls, it adds complications and doesn't seem that beneficial. It's only applicable to the native token. UI software will have to calculate that value transfer. It requires the actor to have such balance in the first place (where their call sequence might have otherwise caused them to receive a balance before sending it away). We might alternatively include an explicit TotalValue field in CallSpec, but it similarly doesn't seem well justified.

If "at least for now" was hinting that such guardrails might be lifted after some observation that users understand what's going on, I don't think that situation would ever be met because new users will constantly arrive. I don't think such hand-holding is warranted to begin with.

Codecs

I'm guessing this is related to #722 but I must admit I don't fully grok the problem here. Actors can return values, and callers must know how to decode them to use them. Knowing a codec but nothing else about the semantics of the value doesn't seem like it would help much, but if a caller does know the semantics, knowing the codec too seems easy.

Is this a specific instance of a more general policy or proposal that's written up somewhere?

[Stebalien]

I'd consider allowing failure decisions at every step instead of requiring a global one. This would enable patterns like:

1. Pre-check (abort on failure).
2. Fire off notifications (continue).
3. Post-check (abort on failure).

[anorth]

Hmm. Adding any control over failure handling is already teetering on the edge of too much complexity, to me. The game of adding a little more complexity to the call spec to enable new patterns can be played many times. E.g. what about conditionals? what about plumbing return values into subsequent parameters? The game bottoms out at a fully-fledged scripting language, but at that point I think we should just support submitting WASM code to be compiled and executed on the fly. Or, of course, deploying an actor to embody the logic.

I'm more inclined to remove the Failure param (i.e. ABORT only) than begin down this path. Deploying a new actor is a good alternative to anything more than "batch these calls".

[aakoshh]

This reminds me of the Cosmos transaction model which also consists of multiple messages. As far as I can tell from the lifecycle they do not allow different abortion behaviour per message, though.

[anorth]

Further thought on this revealed that handling replay and nonces is complicated and undermines the utility quite a bit. I'm putting this aside for now, since I don't see an easy implementation.