MIMD-0022: pseudo-atomic execution

[taco-paco]

Continuing the idea of #965 presenting the pseudo-atomic execution workflow

Motivation

User wants to make an atomic transfer from account A to account B. The flow is

1. Deduct m lamports from A
2. Deposit m lamports to B

Ideally you would write this as

fn transfer(a: &mut Account, b: &mut Account, sum: u64) -> Result<(), MagicError>{
    deduct(a, sum)?;
    deposit(b, sum)?;
    Ok(())
}

or in a more general terms:

fn general(arg1: Arg1, arg2: Arg2) -> Result<(), MagicError> {
   do_a(arg1).then(|| do_b(arg2))
}

On blockchain User expects that in case any of this fails the state will not be affected/partial.

Problem

Unfortunately at the moment User's expectations aren't met. Partial state problem arises when, say account B isn't delegated to ER. In that case User needs to use action.

fn transfer(a: &mut Account, b: &mut Account, sum: u64) -> Result<(), MagicError>{
    deduct(a, sum)?;
    schedule_deposit(b, sum); // schedules deposit on Base chain. ISSUE: this doesn't throw
    Ok(())
}

fn general(arg1: Arg1, arg2: Arg2) -> Result<(), MagicError> {
   do_a(arg1).then(|| Ok(schedule_do_b(arg2)))
}

The problem with Actions as that they may fail on Base chain and in our examples the user would have partial state.

We can do better!

Wouldn't it be great if user could just write the following?

fn transfer(a: &mut Account, b: &mut Account, sum: u64) -> Result<(), MagicError>{
    deduct(a, sum)?;
    deposit(b, sum).await?;
    Ok(())
}

fn general(arg1: Arg1, arg2: Arg2) -> Result<(), MagicError> {
   do_a(arg1).then(|| do_b(arg2).await))
}

Solution

Promise(aka Callback/OnResult). To mimic the behavior the proposed API is:

fn transfer(a: &mut Account, b: &mut Account, sum: u64, ...) -> Result<(), MagicError>{
    deduct(a, sum)?;
    IntentBundleBuilder::new(payer, magic_context, magic_program)
        .action(CallHandler {
                data: anchor::InstructionData::data(&crate::instruction::Deposit{sum: sum}),
                ...
         )
        .on_result( 
                result_id: self.next_id(), // User defined ID
                discriminator: ..,
                compute_units
	        accounts
        );
    Ok(())
}

fn handle_deposit_result(ctx: Context<DepositResult>, result_id: u64, result: MagicResult) {
    // User can extract some context for continuing execution
    // In his case it could be `sum`
    let context = self.extract_context(result_id)?; // User defined logic
    match result {
        Ok(data) => {
            on_deposit_succeded(context.sum, accounts);
        }
        Err(PromiseError) => {
            on_deposit_failed(context.sum, accounts)
        }
    }
}

Callback input payload (prepended by validator):

• result_id/action_id - a user defined id that is used to map particular action to result
• solana_signature? - Can be provided to user, or can be just logged by us since there's not a lot the could do with signature in smart contract
• result: Ok(()) | Err(PromiseError), where PromiseError { Timeout, TransactionError, ..or other}

Same as in MIMD-0020:
Execution rules:
Callback is optional; existing behavior is unchanged when omitted.
Validator must enqueue callback execution as part of intent finalization.
If Solana status is unresolved after 60 seconds, validator must execute callback with failed timeout status.
Callback delivery is guaranteed (persisted + retried until success); callback handlers must be idempotent.

Execution rules

If single BaseAction fails - all of them fail. Hence, all of the callbacks receive Error
Callbacks are part of intent and are stored in it at the moment it will be a part of MagicContext

As result of such design all of the logic above is possible and can be defined by User's smart-contract

[GabrielePicco]

LGTM, with few considerations:

• MagicResult should also contains the signature and ideally transaction logs
• .on_result should also have data, which is gonna be passed to the callback handler
• ID could just be an auto-generate hash or at least we should have a default to make it more ergonomic for the user