MagicAction

[taco-paco]

Magic Action

To support custom actions post commit or post undelegation, or even standalone actions on behalf of actor PDA, we would need to modify: magicblock-program, ephemeral-rollup-sdk & validator.

Current implementation

First let’s recap on the way the current commit & undelegation is scheduled on smart-contract level.
At the moment SDK provides users with 2 convenient methods:

fn commit_accounts<'a, 'info>(
   payer: &'a AccountInfo<'info>,
   accounts_to_commit: Vec<&'a AccountInfo<'info>>,
   magic_context: &'a AccountInfo<'info>,
   magic_program: &'a AccountInfo<'info>,
) -> ProgramResult
fn commit_and_undelegate_accounts<'a, 'info>(
   payer: &'a AccountInfo<'info>,
   accounts_to_commit_and_undelegate: Vec<&'a AccountInfo<'info>>,
   magic_context: &'a AccountInfo<'info>,
   magic_program: &'a AccountInfo<'info>,
) -> ProgramResult

Those CPI into magiblock-program which does some checks and eventually adds an entry into the array of ScheduledCommits

#[derive(Debug, Default, Serialize, Deserialize)]
pub struct MagicContext {
   pub scheduled_commits: Vec<ScheduledCommit>,
}
#[derive(Debug, Clone, PartialEq, Eq, Serialize, Deserialize)]
pub struct ScheduledCommit {
   pub id: u64,
   pub slot: Slot,
   pub blockhash: Hash,
   pub accounts: Vec<CommittedAccount>, // accounts to commit
   pub payer: Pubkey,
   pub commit_sent_transaction: Transaction,
   pub request_undelegation: bool,
}

Problem

We want to support custom “actions”. Custom actions are defined as follows:

#[derive(Debug, Clone, PartialEq, Eq, BorshSerialize, BorshDeserialize)]
pub struct CallHandlerArgs {
   pub escrow_index: u8, // actor-pda is escrow(aka ephemeral balance)
   pub data: Vec<u8>, // arbitrary data that is passed to user’s program
}


struct CallHandler<'info> {
   pub args: CallHandlerArgs,
   pub destination_program: Pubkey, // user defined program
   pub accounts: Vec<AccountMeta>, // accounts needed for CPI
}

With custom actions now we have 7 combinations:
Standalone action, commit, commit with action, commit and undelegate, commit with action and undelegate, commit and undelegate with action, commit with action and undelegate with action

Supporting those in the existing ScheduledCommit struct would get out of hand pretty fast, and the SDK would be cumbersome.

#[derive(Debug, Clone, PartialEq, Eq, Serialize, Deserialize)]
pub struct ScheduledCommit {
   pub id: u64,
   pub slot: Slot,
   pub blockhash: Hash,
   pub accounts: Vec<CommittedAccount>,
   pub payer: Pubkey,
   pub commit_sent_transaction: Transaction,
   pub request_undelegation: bool,
   // New
   pub standalone_call_handler: Vec<CallHandler>,
   pub calls_handler_commit: Vec<CallHandler>,
   pub calls_handler_undelegate: Vec<CallHandler>,
}

Proposal

The proposal is to evolve ScheduledCommit -> ScheduledAction to more explicitly support possible combinations.

pub struct ScheduledAction {
   // Inherited fields
   pub id: u64,
   pub slot: Slot,
   pub blockhash: Hash,
   pub action_sent_transaction: Transaction, // same as commit_sent_tx 
   pub payer: Pubkey,
   // New “scheduled action”
   pub action: Action,
}

pub enum Action {
   /// Actions without commitment or undelegation
   CallHandler(Vec<CallHandler>),
   Commit(CommitType),
   CommitAndUndelegate {
       commit_action: CommitType,
       undelegate_action: UndelegateType, // only with commit
   }
}

pub enum CommitType {
   /// Regular commit without actions
   Standalone(Vec<CommittedAccount>), // accounts to commit
   /// Commits accounts and runs actions
   WithHandler {
       commited_accounts: Vec<CommittedAccount>,
       call_handlers: Vec<CallHandler>
   }
}


/// No CommitedAccounts since it is only used with CommitAction.
pub enum UndelegateType {
   Standalone,
   WithHandler(Vec<CallHandler>)
}

Now the structure is more explicit and evolution friendly, while cases would to some extent have to be supported individually it is easier to do so and without cumbersome preprocessing, less error-prone since no invalid combinations are discarded by compiler and enum structure itself. No way to have “action-commit-with-action”

SDK

How would this look for a user? The modified ephemeral-sdk would be constructor-like(It would also support old methods).

The idea as follows:

pub struct MagicInstructionBuilder<'info> {
   pub magic_context: AccountInfo<'info>,
   pub magic_program: AccountInfo<'info>,
   pub magic_action: MagicAction<'info>
}


impl<'info> MagicInstructionBuilder<'info> {
   pub fn build(&self) -> Instruction {
       todo!();
   }
   pub fn build_and_invoke(self) -> Instruction {
       todo!();
   }
}

pub enum MagicAction<'info> {
   L1Action(Vec<CallHandler<'info>>),
   Commit(CommitType<'info>),
   CommitAndUndelegate(CommitAndUndelegate<'info>)
}

User would have to all users would have to do is to create an instance of MagicInstructionBuilder, call build_and_invoke and SDK handles all for them

magicblock-program

To integrate feature we would need to change magicblock-program:
For backwards compatibility adapt existing method process_schedule_commit to create proper ScheduledAction instances
Add new entrypoint which would look like this

ScheduleAction(ScheduleActionArgs),

And corresponding process_schedule_action

It would contain all necessary descriptions of scheduled action by user and push entry into modified

#[derive(Debug, Default, Serialize, Deserialize)]
pub struct MagicContext {
   pub scheduled_commits: Vec<ScheduledAction>,
}

[GabrielePicco]

Thanks @taco-paco. LGTM!

For the SDK API I would propose use a builder pattern and it could look something like:

let builder = MagicBuilder::new_bundle()
    .payer(&ctx.accounts.payer)
    .accounts(&[ctx.accounts.counter.to_account_info()])
    .commit()
    .undelegate()
    .add_instruction(
        system_instruction::transfer(
            &ctx.accounts.payer.key(),
            &ctx.accounts.counter.key(),
            1_000_000,
        )
    )
    .add_instruction(
        increment_counter_instruction(ctx.accounts.counter.key())
    );

builder.build_and_send()?;