Ideas to improve the API to schedule a commit.

[thlorenz]

Avoid passing Seeds

In order to not require the user to pass seeds for the PDAs he wants to commit we would not rely on the PDAs being signer.
Instead we would check that the program that performed the CPI call of our instruction (to schedule a commit) is the owner of all the PDAs being committed.

This is less safe, but we could not come up with a reason why this could be exploited up to this point.

However the challenge is to determine the following about the instruction that invoked us via CPI.

1. Ensure that we did get invoked via CPI
2. Ensure that the invoking instruction is part of the program whose accounts we are committing.

So far I could not encounter a way to determine 2. and include the related docs below.

Declare Process Instruction

Light wrapper around solana_rbpf::declare_builtin_function! to unify built-in programs and
syscalls interface.

Macro Definition

• program-runtime/src/invoke_context.rs

// program-runtime/src/invoke_context.rs:46
macro_rules! declare_process_instruction {
  ($process_instruction:ident, $cu_to_consume:expr, |$invoke_context:ident| $inner:tt)
  // ...
}

Example Macro Use

declare_process_instruction!(
    Entrypoint,
    DEFAULT_COMPUTE_UNITS,
    |invoke_context| {
      // processing code
    }
)

calls solana_rbpf::declare_builtin_function

Declare Builtin Function

Generates an adapter for a BuiltinFunction between the Rust and the VM interface

• solana_rbpf/src/program.rs

// solana_rbpf-0.8.0/src/program.rs:290
macro_rules! declare_builtin_function {
  // ...
}

Invoke Context

Each processing function is passed an InvokeContext.

• InvokeContext struct

// program-runtime/src/invoke_context.rs:156
pub struct InvokeContext<'a> {
    pub transaction_context: &'a mut TransactionContext,
    sysvar_cache: &'a SysvarCache,
    log_collector: Option<Rc<RefCell<LogCollector>>>,
    compute_budget: ComputeBudget,
    current_compute_budget: ComputeBudget,
    compute_meter: RefCell<u64>,
    pub programs_loaded_for_tx_batch: &'a LoadedProgramsForTxBatch,
    pub programs_modified_by_tx: &'a mut LoadedProgramsForTxBatch,
    pub feature_set: Arc<FeatureSet>,
    pub timings: ExecuteDetailsTimings,
    pub blockhash: Hash,
    pub lamports_per_signature: u64,
    pub syscall_context: Vec<Option<SyscallContext>>,
    traces: Vec<Vec<[u64; 12]>>,
}

LoadedProgramsForTxBatch are not interesting here as they just provide information about the
programs in general, but not related to our transaction.

pub struct LoadedProgram {
    /// The program of this entry
    pub program: LoadedProgramType,
    /// Size of account that stores the program and program data
    pub account_size: usize,
    /// Slot in which the program was (re)deployed
    pub deployment_slot: Slot,
    /// Slot in which this entry will become active (can be in the future)
    pub effective_slot: Slot,
    /// How often this entry was used by a transaction
    pub tx_usage_counter: AtomicU64,
    /// How often this entry was used by an instruction
    pub ix_usage_counter: AtomicU64,
    /// Latest slot in which the entry was used
    pub latest_access_slot: AtomicU64,
}

The only interesting bit is thus the TransactionContext.

Transaction Context

• TransactionContext struct

// sdk/src/transaction_context.rs:136
pub struct TransactionContext {
    account_keys: Pin<Box<[Pubkey]>>,
    accounts: Rc<TransactionAccounts>,
    instruction_stack_capacity: usize,
    instruction_trace_capacity: usize,
    instruction_stack: Vec<usize>,
    instruction_trace: Vec<InstructionContext>,
    return_data: TransactionReturnData,
    accounts_resize_delta: RefCell<i64>,
    #[cfg(not(target_os = "solana"))]
    rent: Rent,
    /// Useful for debugging to filter by or to look it up on the explorer
    #[cfg(all(not(target_os = "solana"), debug_assertions))]
    signature: Signature,
}

The TransactionAccounts don't provide any indicator as to what program invoked us as they
look like this.

pub struct TransactionAccounts {
    accounts: Vec<RefCell<AccountSharedData>>,
    touched_flags: RefCell<Box<[bool]>>,
}

• AccountSharedData has the following fields not interesting in this context:
• data, owner, lamports, rent_epoch, executable

The InstructionContext is the interesting part of the TransactionContext.

Instruction Context

/// Loaded instruction shared between runtime and programs.
///
/// This context is valid for the entire duration of a (possibly cross program) instruction being processed.
#[derive(Debug, Clone, Default, Eq, PartialEq)]
pub struct InstructionContext {
    nesting_level: usize,
    instruction_accounts_lamport_sum: u128,
    program_accounts: Vec<IndexOfAccount>,
    instruction_accounts: Vec<InstructionAccount>,
    instruction_data: Vec<u8>,
}
type IndexOfAccount = u16;

• the nesting level combined with the index inside the
  instruction_trace: Vec<InstructionContext> should allow us to determine
  who is our parent
• IX at currentIndex - 1 with nesting currentNesting - 1)
• afaik this is what specific helper methods use that allow us to refer to instructions
  relative to ours, i.e. sibling before/after, etc.
• the program_accounts list all program account indexes, i.e. we don't know which of them was the
  program executing the instrucion
• instruction_accounts provide information about all accounts in an instruction

Instruction Account

• InstructionAccount struct

// sdk/src/transaction_context.rs:39

/// Contains account meta data which varies between instruction.
pub struct InstructionAccount {
    /// Points to the account and its key in the `TransactionContext`
    pub index_in_transaction: IndexOfAccount,
    /// Points to the first occurrence in the parent `InstructionContext`
    ///
    /// This excludes the program accounts.
    pub index_in_caller: IndexOfAccount,
    /// Points to the first occurrence in the current `InstructionContext`
    ///
    /// This excludes the program accounts.
    pub index_in_callee: IndexOfAccount,
    /// Is this account supposed to sign
    pub is_signer: bool,
    /// Is this account allowed to become writable
    pub is_writable: bool,
}

• I'm not sure what the index_in_caller of a program account would be
• if the invoked program somehow would have a specific index assigned then this could help us
  pinpoint which one of the program accounts it is
• nothing in the code seems to suggest any specifity here, but we could experiment

[thlorenz]

List of Things we need to address

List related issues here instead of creating one for each.

Scheduled Commits should be ignored if Transaction Fails

• High Priority

Problem Example: Transaction includes two Instructions

• first instruction schedules commit and passes
• second instruction fails and thus transaction fails
• commits remain scheduled and are processes as if the transaction succeeded

What should happen here is the following:

• when scheduling a commit we record the transaction signature (it is available inside the instruction)
• then we verify first that the transaction succeeded before realizing a scheduled commit