pub struct Instruction {
pub program_id: Pubkey,
pub accounts: Vec<AccountMeta>,
pub data: Vec<u8>,
}
Expand description
A directive for a single invocation of a Solana program.
An instruction specifies which program it is calling, which accounts it may read or modify, and additional data that serves as input to the program. One or more instructions are included in transactions submitted by Solana clients. Instructions are also used to describe cross-program invocations.
During execution, a program will receive a list of account data as one of
its arguments, in the same order as specified during Instruction
construction.
While Solana is agnostic to the format of the instruction data, it has
built-in support for serialization via borsh
and bincode
.
§Specifying account metadata
When constructing an Instruction
, a list of all accounts that may be
read or written during the execution of that instruction must be supplied as
AccountMeta
values.
Any account whose data may be mutated by the program during execution must be specified as writable. During execution, writing to an account that was not specified as writable will cause the transaction to fail. Writing to an account that is not owned by the program will cause the transaction to fail.
Any account whose lamport balance may be mutated by the program during execution must be specified as writable. During execution, mutating the lamports of an account that was not specified as writable will cause the transaction to fail. While subtracting lamports from an account not owned by the program will cause the transaction to fail, adding lamports to any account is allowed, as long is it is mutable.
Accounts that are not read or written by the program may still be specified
in an Instruction
’s account list. These will affect scheduling of program
execution by the runtime, but will otherwise be ignored.
When building a transaction, the Solana runtime coalesces all accounts used
by all instructions in that transaction, along with accounts and permissions
required by the runtime, into a single account list. Some accounts and
account permissions required by the runtime to process a transaction are
not required to be included in an Instruction
s account list. These
include:
- The program ID — it is a separate field of
Instruction
- The transaction’s fee-paying account — it is added during
Message
construction. A program may still require the fee payer as part of the account list if it directly references it.
Programs may require signatures from some accounts, in which case they
should be specified as signers during Instruction
construction. The
program must still validate during execution that the account is a signer.
Fields§
§program_id: Pubkey
Pubkey of the program that executes this instruction.
accounts: Vec<AccountMeta>
Metadata describing accounts that should be passed to the program.
data: Vec<u8>
Opaque data passed to the program for its own interpretation.
Implementations§
Source§impl Instruction
impl Instruction
Sourcepub fn new_with_borsh<T>(
program_id: Pubkey,
data: &T,
accounts: Vec<AccountMeta>,
) -> Instructionwhere
T: BorshSerialize,
pub fn new_with_borsh<T>(
program_id: Pubkey,
data: &T,
accounts: Vec<AccountMeta>,
) -> Instructionwhere
T: BorshSerialize,
Create a new instruction from a value, encoded with borsh
.
program_id
is the address of the program that will execute the instruction.
accounts
contains a description of all accounts that may be accessed by the program.
Borsh serialization is often preferred over bincode as it has a stable specification and an implementation in JavaScript, neither of which are true of bincode.
§Examples
#[derive(BorshSerialize, BorshDeserialize)]
pub struct MyInstruction {
pub lamports: u64,
}
pub fn create_instruction(
program_id: &Pubkey,
from: &Pubkey,
to: &Pubkey,
lamports: u64,
) -> Instruction {
let instr = MyInstruction { lamports };
Instruction::new_with_borsh(
*program_id,
&instr,
vec![
AccountMeta::new(*from, true),
AccountMeta::new(*to, false),
],
)
}
Sourcepub fn new_with_bincode<T>(
program_id: Pubkey,
data: &T,
accounts: Vec<AccountMeta>,
) -> Instructionwhere
T: Serialize,
pub fn new_with_bincode<T>(
program_id: Pubkey,
data: &T,
accounts: Vec<AccountMeta>,
) -> Instructionwhere
T: Serialize,
Create a new instruction from a value, encoded with bincode
.
program_id
is the address of the program that will execute the instruction.
accounts
contains a description of all accounts that may be accessed by the program.
§Examples
#[derive(Serialize, Deserialize)]
pub struct MyInstruction {
pub lamports: u64,
}
pub fn create_instruction(
program_id: &Pubkey,
from: &Pubkey,
to: &Pubkey,
lamports: u64,
) -> Instruction {
let instr = MyInstruction { lamports };
Instruction::new_with_bincode(
*program_id,
&instr,
vec![
AccountMeta::new(*from, true),
AccountMeta::new(*to, false),
],
)
}
Sourcepub fn new_with_bytes(
program_id: Pubkey,
data: &[u8],
accounts: Vec<AccountMeta>,
) -> Instruction
pub fn new_with_bytes( program_id: Pubkey, data: &[u8], accounts: Vec<AccountMeta>, ) -> Instruction
Create a new instruction from a byte slice.
program_id
is the address of the program that will execute the instruction.
accounts
contains a description of all accounts that may be accessed by the program.
The caller is responsible for ensuring the correct encoding of data
as expected
by the callee program.
§Examples
#[derive(BorshSerialize, BorshDeserialize)]
pub struct MyInstruction {
pub lamports: u64,
}
pub fn create_instruction(
program_id: &Pubkey,
from: &Pubkey,
to: &Pubkey,
lamports: u64,
) -> Result<Instruction, Error> {
let instr = MyInstruction { lamports };
let mut instr_in_bytes: Vec<u8> = Vec::new();
instr.serialize(&mut instr_in_bytes)?;
Ok(Instruction::new_with_bytes(
*program_id,
&instr_in_bytes,
vec![
AccountMeta::new(*from, true),
AccountMeta::new(*to, false),
],
))
}
Trait Implementations§
Source§impl Clone for Instruction
impl Clone for Instruction
Source§fn clone(&self) -> Instruction
fn clone(&self) -> Instruction
1.0.0 · Source§fn clone_from(&mut self, source: &Self)
fn clone_from(&mut self, source: &Self)
source
. Read more