Expand description
Atomically-committed sequences of instructions.
While Instructions are the basic unit of computation in Solana, they are
submitted by clients in Transactions containing one or more
instructions, and signed by one or more Signers. Solana executes the
instructions in a transaction in order, and only commits any changes if all
instructions terminate without producing an error or exception.
Transactions do not directly contain their instructions but instead include
a Message, a precompiled representation of a sequence of instructions.
Message’s constructors handle the complex task of reordering the
individual lists of accounts required by each instruction into a single flat
list of deduplicated accounts required by the Solana runtime. The
Transaction type has constructors that build the Message so that clients
don’t need to interact with them directly.
Prior to submission to the network, transactions must be signed by one or
more keypairs, and this signing is typically performed by an abstract
Signer, which may be a Keypair but may also be other types of
signers including remote wallets, such as Ledger devices, as represented by
the RemoteKeypair type in the solana-remote-wallet crate.
Every transaction must be signed by a fee-paying account, the account from which the cost of executing the transaction is withdrawn. Other required signatures are determined by the requirements of the programs being executed by each instruction, and are conventionally specified by that program’s documentation.
When signing a transaction, a recent blockhash must be provided (which can
be retrieved with RpcClient::get_latest_blockhash). This allows
validators to drop old but unexecuted transactions; and to distinguish
between accidentally duplicated transactions and intentionally duplicated
transactions — any identical transactions will not be executed more
than once, so updating the blockhash between submitting otherwise identical
transactions makes them unique. If a client must sign a transaction long
before submitting it to the network, then it can use the durable
transaction nonce mechanism instead of a recent blockhash to ensure unique
transactions.
§Examples
This example uses the solana_rpc_client and anyhow crates.
use anyhow::Result;
use borsh::{BorshSerialize, BorshDeserialize};
use solana_instruction::Instruction;
use solana_keypair::Keypair;
use solana_message::Message;
use solana_pubkey::Pubkey;
use solana_rpc_client::rpc_client::RpcClient;
use solana_signer::Signer;
use solana_transaction::Transaction;
// A custom program instruction. This would typically be defined in
// another crate so it can be shared between the on-chain program and
// the client.
#[derive(BorshSerialize, BorshDeserialize)]
enum BankInstruction {
Initialize,
Deposit { lamports: u64 },
Withdraw { lamports: u64 },
}
fn send_initialize_tx(
client: &RpcClient,
program_id: Pubkey,
payer: &Keypair
) -> Result<()> {
let bank_instruction = BankInstruction::Initialize;
let instruction = Instruction::new_with_borsh(
program_id,
&bank_instruction,
vec![],
);
let blockhash = client.get_latest_blockhash()?;
let mut tx = Transaction::new_signed_with_payer(
&[instruction],
Some(&payer.pubkey()),
&[payer],
blockhash,
);
client.send_and_confirm_transaction(&tx)?;
Ok(())
}Modules§
- containers
wincode - This module provides specialized implementations of standard library collection types that
provide control over the length encoding (see
SeqLen), as well as special case opt-in raw-copy overrides (seePod). - sanitized
- simple_
vote_ transaction_ checker - versioned
- Defines a transaction which supports multiple versions of messages.
Structs§
- Account
Meta - Describes a single account read or written by a program during instruction execution.
- Address
- The address of a Solana account.
- Compiled
Instruction - A compact encoding of an instruction.
- Hash
wincode - A hash; the 32-byte output of a hashing algorithm.
- Instruction
- A directive for a single invocation of a Solana program.
- Message
- A Solana transaction message (legacy).
- Short
U16 wincode - Same as u16, but serialized with 1 to 3 bytes. If the value is above 0x7f, the top bit is set and the remaining value is stored in the next bytes. Each byte follows the same pattern until the 3rd byte. The 3rd byte may only have the 2 least-significant bits set, otherwise the encoded value will overflow the u16.
- Signature
- Transaction
- An atomically-committed sequence of instructions.
Enums§
- Instruction
Error - Reasons the runtime might have rejected an instruction.
- Signer
Error wincode - Transaction
Error - Reasons a transaction might be rejected.
- Transaction
Verification Mode - Versioned
Message - Either a legacy message, v0 or a v1 message.
Traits§
- Schema
Read wincode - Types that can be read (deserialized) from a
Reader. - Schema
Write wincode - Types that can be written (serialized) to a
Writer. - Signers
wincode - Convenience trait for working with mixed collections of
Signers
Functions§
- uses_
durable_ nonce - Returns true if transaction begins with an advance nonce instruction.
Type Aliases§
Derive Macros§
- Schema
Read wincode - Implement
SchemaReadfor a struct or enum. - Schema
Write wincode - Implement
SchemaWritefor a struct or enum.