rialo-s-transaction 0.2.0

Solana transaction-types
docs.rs failed to build rialo-s-transaction-0.2.0
Please check the build logs for more information.
See Builds for ideas on how to fix a failed build, or Metadata for how to configure docs.rs builds.
If you believe this is docs.rs' fault, open an issue.

Atomically-committed sequences of instructions.

While [Instruction]s are the basic unit of computation in Solana, they are submitted by clients in [Transaction]s 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, the the valid from field must be provided. 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 valid from field between submitting otherwise identical transactions makes them unique.

# use rialo_s_sdk::example_mocks::solana_rpc_client;
use anyhow::Result;
use std::time::{SystemTime, UNIX_EPOCH};
use borsh::{BorshSerialize, BorshDeserialize};
use rialo_s_instruction::Instruction;
use rialo_s_keypair::Keypair;
use rialo_s_message::Message;
use rialo_s_pubkey::Pubkey;
use solana_rpc_client::rpc_client::RpcClient;
use rialo_s_signer::Signer;
use rialo_s_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 { kelvins: u64 },
    Withdraw { kelvins: 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 valid_from = SystemTime::now().duration_since(UNIX_EPOCH)?.as_secs();
    let mut tx = Transaction::new_signed_with_payer(
        &[instruction],
        Some(&payer.pubkey()),
        &[payer],
        valid_from as i64,
    );
    client.send_and_confirm_transaction(&tx)?;

    Ok(())
}
#
# let client = RpcClient::new(String::new());
# let program_id = Pubkey::new_unique();
# let payer = Keypair::new();
# send_initialize_tx(&client, program_id, &payer)?;
#
# Ok::<(), anyhow::Error>(())