Thread by @ShivanshuMadan

Lifecycle of a Solana transaction 🧵

1/11

TRANSACTION CREATION

Solana tx begins when a user connects to an app and intends to do a tx on that app.

For e.g. when you click 'Swap' on Jupiter

The app then verifies the user wallet balance and other metadata, and constructs the tx

Each tx includes:

a) Header: indicating which accounts must sign the tx
b) Instructions: the operations that must be performed during this tx
c) Hash of a Recent Block: to prevent stale txs
d) Access List: the accounts being read from or written to

The app then sends the tx to the user, who signs the tx with their private key (via a wallet), and sends it back to the app

2/11

SENDING TO RPC

The signed tx is sent to an RPC node (like @heliuslabs) that sanity checks the tx by verifying that the signatures are valid, tx format is correct, etc.

RPCs can be thought of as gateways to interact with and read data from the network.

They run the same software as full validators but with different settings, allowing them to accurately simulate txs and maintain an up-to-date view of the current state of the chain

3/11

GULFSTREAM & swQOS

The RPC node sends the tx through the Solana network’s gossip layer to the current leader validator (more on this later)

Note that this is different from most other networks like Ethereum where the tx is sent to a public mempool

In Solana, any validator who sees a pending tx, sends it via the gossip layer (called Gulfstream) to the leader validator

To ensure that no single node spams the network and that tx distribution remains fair, the leader prioritizes incoming txs from validators with higher stake (this is called swQOS - stake weighted Quality of Service)

swQOCs are like priority lanes that ensure high "quality of service"

4/11

LEADER SCHEDULE

The Solana chain is divided into epochs (lasts ~2 days), and each epoch is divided into 400ms slots.

Based on stake weighting, a leader schedule is produced before every epoch, and a leader is chosen for each slot. The leader is responsible for producing blocks from the incoming txs

Each leader is assigned 4 consecutive slots (1.6 seconds) before rotation to the next leader

5/11

BLOCK PRODUCTION

Upon receiving txs, leaders perform sanity checks (signature verification, validity, etc.) and send the txs to the 'Banking Stage'

This is Solana's block building stage where txs are processed in parallel and packaged into ledger “entries,” which are batches of 64 non-conflicting txs (decided by each tx's access lists)

Conflicting txs go into different entries and are executed sequentially, while non-conflicting txs are executed in parallel

There are 6 threads processing txs in parallel, with 4 dedicated to normal txs and 2 exclusively handling vote txs (more on vote txs later)

6/11

JITO CLIENT

Normally, the leader builds a block from a prioritized queue of txs it has collected

However, leaders running the Jito client can rely on MEV searchers to receive optimally ordered bundled of txs

Jito runs out-of-protocol auctions where searchers look at any txs that the leader is ingesting and pack them in profit maximizing bundles

These searchers then send these bundles to the leaders - who choose one or more of the bundles to be included in the block and receive the bids as MEV tips (Jito keeps a 5% cut)

7/11

PROOF OF HISTORY (PoH)

Once the txs have been ordered in these entries, the accounts these txs touch are locked, and block txs are ready for execution

Execution happens in the SVM (Sealevel Virtual Machine) which is Solana's runtime environment

The hashes of these entries are also sent to a 'Proof of History (PoH)' service

PoH acts as the time-stamping service for Solana.

For each block, PoH generates a hash using as inputs the previous block's hash + the hashes of the entries in the current block

This acts as a sort of 'proof of work' by the leader and helps maintain the order of events in the Solana blockchain

8/11

TURBINE

When the execution is complete, the locks on the accounts are lifted, and the leader updates the account states in their personal copy of the AccountDB

The leader then broadcasts the block to the rest of the network using Solana's block propogation engine 'Turbine'.

Turbine breaks the block tx data into smaller pieces called 'shreds' (up to 1280 bytes each)

These shreds are then streamed to other validators over Solana’s gossip network. Instead of sending one large file, the leader continuously emits these small shreds.

This allows validators to begin verifying and voting on blocks as they are being built, significantly reducing block propagation times and improving overall network performance.

Turbine implements a tree-based fanout: the leader sends shreds to a few validators, who forward them to more validators, and so on, ensuring fast, efficient block propagation

9/11

VOTING

Once a validator receives a new block from the leader via Turbine, they must validate all txs within each entry.

This involves replaying the entire block, validating the PoH hashes in parallel, recreating the txs in the sequence dictated by PoH, and updating they local bank.

Validators are also responsible for retransmitting the block to the downstream validators in the 'Turbine Tree'

If the validators believe the block is valid, they can attest to it by producing a 'vote transaction'.

These vote txs get recorded in subsequent slots in the ledger.

10/11

CONSENSUS

Solana’s consensus algorithm, Tower BFT, uses validator votes to lock in blocks.

If a supermajority (at least two-thirds of the total stake) of validators vote on top of a particular slot, that slot (and all its ancestors) becomes finalized.

Wallets and RPC services often report “commitment levels” such as:

• Processed: Included by the leader
• Confirmed: Voted by supermajority of validators
• Finalized: More than 31 blocks have been built on top of the tx's block

Finalized blocks are immutable and cannot be reversed.

11/11