In this report, we explore the lifecycle of a transaction on Solana. We analyze the fundamental concepts of a transaction, such as its structure, size, message header, and compact array format. Additionally, we highlight the execution process in the Solana runtime and explain why transaction costs on this blockchain are low.
A transaction on Solana is the transmission of data on the blockchain. Instructions cryptographically signed by accounts update the network when initiated. A Solana transaction consists of signatures, a set of signatures included in the transaction, and a message, which contains the list of transactions to be processed.
Solana maintains a maximum transmission unit (MTU) of 1280 bytes, ensuring fast and reliable transmission via UDP. A message on Solana is composed of a message header, account addresses, a recent blockhash, and instructions.
The message header defines the permissions of the accounts included in the transaction and specifies the number of required signatures. It also contains the number of read-only account addresses that require and do not require signatures.
The account addresses in the message include all those necessary for the transaction instructions. These addresses are ordered according to their privileges and are used to determine the number of accounts in each section.
The recent blockhash prevents duplication and obsolete transactions. Each transaction on Solana has a blockhash that expires after 150 blocks if not processed within the expected time.
Transaction instructions specify the program that will process the operations, the indices of account addresses, and the data required for execution.
The lifecycle of a transaction on Solana begins when the user signs it from their wallet or application. The transaction is then sent to a Solana RPC server, which acts as an entry point to the network. These servers forward the transaction to the current leader and the next two leaders for validation and ordering.
Transaction processing on Solana is efficient thanks to its parallel execution architecture. The leader validates and organizes transactions before scheduling them for execution. Solana uses an algorithm called Prio-Graph, which prioritizes transactions based on priority fees and avoids conflicts by processing in parallel those that do not affect the same state.
On Solana, unlike Ethereum, there is no global mempool. Instead, Gulfstream is used, a local ordering system in each execution thread that manages account locks individually.
Transactions are transmitted on the network through optimized connections using the QUIC protocol, ensuring fast and secure communication. During this process, signatures are verified, data is validated, and transactions are executed in parallel. Finally, confirmed transactions are broadcast to all network nodes and stored on the blockchain.
To ensure the blockchain state is up to date, network validators constantly synchronize their data. A transaction is considered finalized when it has been confirmed by a supermajority of validators. The transaction status can be monitored at all times through the connection to the RPC server.
At Q2BSTUDIO, we understand the importance of optimizing processes and leveraging the advantages of efficient architectures like Solana's. As experts in development and technology services, we work on advanced solutions to improve interaction with high-performance blockchains. Our experience allows us to offer innovative and cutting-edge tools so that companies and developers can make the most of these technologies.
In this analysis, we have covered the lifecycle of a transaction on Solana, from its origin to its validation on the network. We also explored how Solana executes and orders transactions and its technical structure, highlighting the benefits of its design to offer fast and cost-effective transactions.
