Ack / Nack for cross-message execution

[aakoshh]

We agreed in #212 that we will make the sender of a cross-message pay for its execution in the target subnet.

For example if Alice wants to send a top-down message M from parent subnet P to child subnet C, first she has to fund an account in C with the same key and then send M. When M is executed in C, the gateway will charge the gas to Alice, and if she doesn't have enough balance, the execution of M will run out of gas and be reverted.

Note that who pays for the actual execution of the transaction that causes M to be executed varies depending on whether this is happening in Lotus or Fendermint:

• In Lotus, the checkpoint relayer has to be able to cover all the gas costs up front, but they will get reimbursed during execution from the senders.
• In Fendermint, the checkpoints are executed implicitly, and the payments go to the validators.

Nevertheless the fact that M can run out of gas presents a problem: if it fails, it cannot be retried. That's because each subnet has a single message queue, unlike in Cosmos IBC for example where channels exist independent of each other and can be retried until a relayer has enough gas to cover the costs. Because IPC moves on, if the execution of a message failed on the target, it might leave resources locked on the source subnet. There should be a way to unlock them and retry the operation.

One possibility to mitigate the risk is that instead of immediately executing messages, we could deliver them into a staging area (similar to channels) from which they can be triggered by someone willing to pay for the execution, and retried if it fails. This makes gas costs more predictable as only a message inclusion cost needs to be paid. An analogy is that the postman delivers the mail, but doesn't open and execute instructions in them; that needs to be done by the resident when they have time.

Another option, proposed in this issue, is to provide built-in feedback about the execution outcome in the form of an Ack (success) or Nack (failure) message delivered by the system to the sender. This would allow the sender to take action, for example by unlocking resources that failed to be minted on the target subnet.

We discussed Ack signals more than a year ago, but the question came up of what should happen if the Ack itself runs out of gas. It's still unclear, but:

• At least if the account is well funded, it can be notified about the outcomes. Note that it could use external observation to trigger actions, but they would not be part of consensus, so they could not be used easily for unlocking resources.
• Ostensibly we could make this optional by making the ack/nack itself available in the source system, but not trigger arbitrary execution immediately; the sender could simply tell the contract that sent the message to look up the outcome in IPC and do whatever the handling mechanism is supposed to do, whenever they have gas to cover the logic. This would make this part retriable, which could be used for example to re-send the message after the sender has been funded with extra tokens on the target subnet.