solana_sdk

Module transaction

Source
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 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_rpc_client::rpc_client::RpcClient;
use solana_sdk::{
     instruction::Instruction,
     message::Message,
     pubkey::Pubkey,
     signature::{Keypair, Signer},
     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(())
}

Structs§

Enums§

Constants§

  • MAX_TX_ACCOUNT_LOCKS
    Maximum number of accounts that a transaction may lock. 128 was chosen because it is the minimum number of accounts needed for the Neon EVM implementation.

Traits§

Functions§

Type Aliases§