articleJul 31, 2022
Solana transactions
How Solana transactions bundle instructions, list accounts up front for parallel execution, and charge deterministic fees with a recent blockhash.
Transactions
A client calls a program by submitting a transaction to the cluster. One transaction can hold multiple instructions, each aimed at its own program. The Solana runtime processes those instructions atomically in order. If any instruction fails, the whole transaction fails.
Each instruction carries:
- program_id of the target program
- all arrays of read and write accounts
- an instruction_data byte array specific to the target programA transaction itself bundles:
- any array accounts you want to read or write to
- one or more instructions
- recently updated blockhash
- One or more signaturesTransactions are capped at 1232 bytes. Both the instruction and the transaction must declare every account they will read or write. That advance declaration is what lets the runtime parallelize execution across transactions.
For each instruction, the receiving program interprets the data array and operates on the listed accounts. It either returns success or an error code. On error, the transaction stops immediately.
Any withdrawal or data change needs the account holder's signature. Accounts that will change are marked writable. You can deposit into an account without the owner's signature as long as the fee payer covers rent and fees.
Every transaction must cite a recent blockhash. The blockhash blocks duplicates and drops stale transactions. A blockhash stays usable for at most about 150 blocks.
Fees
Solana charges two fee types:
- Transaction fees (gas)
- Rent
Transaction fees are deterministic. There is no fee market where paying more improves inclusion odds. Cost is driven by the number of required signatures, and the hard 1232-byte transaction cap still applies.
Every transaction needs at least one writable account to sign. The first serialized writable signer becomes the fee payer. That account pays whether the transaction succeeds or fails. If the fee payer cannot cover the fee, the transaction is rejected.