In this report, we focus on the Solana transaction lifecycle. We delve into the core concepts of a transaction, such as its size, message header, compact-array format, and so on. We also emphasize the Solana runtime process and explain why the transaction cost on Solana is low. What is a Solana transaction? Structure of a Solana transaction Structure of a Solana transaction Structure of a Solana transaction A transaction is the transmission of data across the blockchain. Cryptographically signed instructions from accounts update the network when initiated. A Solana transaction consists of signatures; an array of signatures is included in the transaction and message, the list of transactions to be processed. signatures; signatures; an array of signatures is included in the transaction message message The Solana network adheres to a maximum transmission unit (MTU) size of 1280 bytes, consistent with the IPV6 MTU size constraints to ensure fast and reliable transmission of a cluster of information over UDP. The message header is composed of three u8 integers, and when it’s accounted for (40 bytes for IPV6 and 8 bytes for the fragment header), it has an available packet data of 1232 bytes, for instance, serialized transactions, which is the total size of a transaction limited to a Solana transaction. In a Solana transaction, each signature requires 64 bytes and can vary based on the transaction requirements. On the other hand, the message includes instructions, accounts, and metadata, which vary with each account requiring 32 bytes. A transaction message in Solana is made up of a message header, account addresses, a recent blockhash, and instructions. a message header, account addresses, a recent blockhash, and instructions. a message header, account addresses, a recent blockhash, and instructions. Message Header A message header compromises and identifies the privileges of accounts included in a transaction’s account address array. It contains three u8 integers, as stated above, which collectively specifies; The number of required signatures for the transaction and message version number. The number of read-only account addresses that require signatures. The number of read-only account addresses that do not require signatures. The number of required signatures for the transaction and message version number. The number of read-only account addresses that require signatures. The number of read-only account addresses that do not require signatures. Account Address A message includes an array containing all the account addresses needed for the instructions within the transaction. This array starts with a compact-u16 encoding of the number of account addresses, followed by the addresses ordered by the privileges for the accounts. The metadata in the message header is used to determine the number of accounts in each section. compact-u16 compact-u16 Recent Blockhash In a Solana transaction, all transactions have a recent block hash that keeps track of the time a transaction was executed. The blockhash prevents duplications and stale transactions. Every transaction sent by a user is confirmed in a block; the maximum age of a transaction’s blockhash is 150 blocks (assuming the target slot time is 400ms). If a transaction's blockhash is 150 blocks older than the latest blockhash, it is considered expired. This means that transactions not processed within a specific timeframe will never be executed. Instructions A transaction message is composed of compact arrays of instructions that are yet to be processed. This compact array starts with a compact-u16 encoding of the number of instructions, followed by an array of instructions. Each instruction in the array specifies the following information: program ID, compact array of account address indexes, and compact array of opaque u8 data. compact-u16 compact-u16 program ID, compact array of account address indexes, and compact array of opaque u8 data. program ID, compact array of account address indexes, and compact array of opaque u8 data. A program ID identifies an on-chain program that will process the instruction. It is represented as an u8 index, which points to an account address within the array of account addresses. The instruction also includes a compact array of account address indexes, where each index corresponds to an entry in the account address array, representing the accounts required by the instruction. Additionally, a compact array of opaque u8 data is provided. This is a u8-byte array specific to the invoked program, containing the instruction details and any necessary data (such as function arguments) that the program requires to execute the instruction. program ID compact array of account address indexes compact array of opaque u8 data Lifecycle of a Solana Transaction A simple Solana transaction could be a trade on a DeFi protocol, an NFT mint, or a token transfer that happens on the Solana blockchain. On Solana, transactions tend to be fast and happen instantaneously, as Solana uses a hybrid structure where accounts can store both data and executable code. Therefore, Solana enables each account to function as a standalone state machine capable of performing various operations and interacting directly with smart contracts. Triggering the Transaction Immediately the user signs the transaction in their wallet, dapp, or any interface; the details of the signed transaction are sent to a Solana RPC server. These servers act as entry points for the transaction into the network as they help relay on-chain data. RPC servers in Solana are non-voting validators focused on accessing on-chain data. The RPC server forwards the transaction to the current leader and the following two leaders after verifying the leader schedule, which is set once each epoch and lasts roughly two days. The leader is given four slots in a row and is responsible for creating a block for the current position. Typically, slots last 400 milliseconds. Transaction Processing and Sequencing When the signed transactions reach the current leader, the leader first validates the signed transactions and then organizes the transactions before scheduling them for execution. The leader is only responsible for signed transactions within its designated slot. Solana validators use a block-building algorithm provided in the Solana client, which includes a transaction scheduler. This scheduler is crucial for block creation and the ordering of transactions for execution. While the default scheduler is single-threaded and uses an algorithm called Prio-Graph, validators have the option to implement other block-building algorithms. The Prio-Graph algorithm prioritizes transactions based on factors like priority fees and whether they are vote transactions. It also creates links between lower-priority transactions that conflict with higher-priority ones (such as those affecting the same account or state), preventing them from being executed in parallel. This enables non-conflicting transactions to run simultaneously. If a transaction is not included in a block, the user must resend it. Users can include a priority fee with their transactions, with the base fee remaining unchanged regardless of the compute units required. Half of the base fee is burned, and the other half is given to the validator building the block. The priority fee (which goes entirely to the validators after SIMD-0096) varies based on the requested compute units, which are determined by the program counter in the Berkeley Packet Filter (BPF) bytecode format. Prio-Graph Prio-Graph The RPC server establishes a fast and secure connection to the leader node’s Transaction Processing Unit (TPU) using Quick UDP Internet Connections (QUIC), a communication protocol designed for quick and reliable data transfer. This protocol ensures secure delivery of data packets, minimizing delays and enhancing overall network performance. The TPU processes transactions in multiple stages to ensure efficiency and security. In the fetch stage, transactions are grouped into batches of 128 packets for better management. During the SigVerify Stage, each transaction’s signature is validated to prevent tampering, and duplicates are removed to avoid redundant processing. The Banking Stage executes transactions in parallel, allowing multiple transactions to be processed simultaneously and ensuring necessary checks and updates are made to the involved accounts. Finally, in the broadcast stage, processed transactions are broadcast to the network, notifying all nodes of the new transactions. fetch stage SigVerify Stage Banking Stage broadcast stage Unlike in Ethereum, Solana has no mempool (uses Gulfstream), and as such, there is no global ordering of transactions queued for execution; there is just local ordering in each thread’s queue. Keep in mind that a transaction specifies which state must be read-locked and which must be write-locked to be executed. When a thread is ready to carry out a transaction, it tries to obtain the required account locks before carrying out the operation. Transactions that are unable to obtain the required lock are re-queued for a subsequent attempt. Solana achieves higher performance than other chains as transactions don’t need to touch the same state; they can be executed in parallel, which improves the throughput of the chain. Transaction Broadcasting and State Updates To maintain a stable and up-to-date ledger, validators inside clusters of the Solana network synchronize their states. These clusters, which are composed of groups of validators, cooperate to keep a consistent picture of the blockchain and guarantee that the ledgers of every node are current and in agreement with the network's current state. When the leader executes a transaction, it is instantly disseminated throughout the network and noted on the validator's copy of the ledger. The transaction is completed and entered into the blockchain permanently once the block has been confirmed by a supermajority of validators. This procedure is streamlined for dependability and quickness. When 31 or more verified blocks have been constructed onto a block, it is deemed finished. To enable the user to monitor the progress of their transaction, these phases are relayed back to the front end over the RPC. A large portion of the underlying technology operates flawlessly in the background to make the process dependable and efficient, while Solana's consensus and block propagation algorithms guarantee quick and secure transaction finalization. Conclusion In this report, we examined the lifecycle of a Solana transaction, from a user-submitted wallet transaction to its confirmation by the Solana network. We also examined how Solana executes and orders transactions and the structure of a Solana transaction.
