Program(s) Feature Request: add unsafe unchecked invoke call

[redmannequin]

Hey guys,
What are your thoughts on exposing an unsafe unchecked_invoke_signed call for program instructions?

I'm currently building a wrapper on top of the Pinocchio SDK to provide "compile time" access safety. An unchecked variant of the program calls would be beneficial as it could reduce the overhead of releasing and relocking the runtime guard.

[febo]

Does this one not work?

https://github.com/anza-xyz/pinocchio/blob/main/sdk/pinocchio/src/cpi.rs#L213

[redmannequin]

Yes, though what I had in mind was being able to call already defined System and Token instructions directly, e.g.:

pinocchio_token::instructions::Transfer {
    from,
    to,
    authority,
    amount: 10,
}.unchecked_invoke_signed([])?;

Happy to open a PR(s) if this approach makes sense.

[redmannequin]

Just had a little idea, mostly likely requires a separate issue. Defining Instructions traits like AccountData, InstructionData(#109), allowing for something akin to:

trait AccountData {
  const ACCOUNT_METAS: usize;
  ......

  fn account_metas(&self) -> [_; _];
  fn accounts(&self) -> [_; _];
  fn singers(&self) -> [_;_];
}

trait InstructionExt: AccountMetas + InstructionData {
  fn inkove(self) {
    let instruction = Instruction {
      program_id: &crate::ID,
      accounts: &self.account_metas(),
      data: &self.instruction_data(),
    };
    Self::unchecked_invoke_signed(&instruction, &self.accounts(), &self.signers())
  }

  fn unchecked_invoke_signed(....) {
    ......
  }
}

[febo]

Ah, got it. Yes, it would be nice to have the "parts" of an instruction as separate entities, so we can provide unchecked variants on the client.

[redmannequin]

Hey @febo, I've opened #130. LMK what you think.