You are reading an excerpt from our free but shortened abridged report! While still packed with incredible research and data, for just $40/month you can upgrade to our FULL library of 60+ reports (including this one) and complete industry-leading analysis on the top crypto assets. 

Becoming a Premium member means enjoying all the perks of a Basic membership PLUS:

• Full-length CORE Reports: More technical, in-depth research, actionable insights, and potential market alpha for serious crypto users
• Early access to future CORE ratings: Being early is sometimes just as important as being right!
• Premium Member CORE+ Reports: Coverage on the top issues pertaining to crypto users like bridge security, layer two solutions, DeFi plays, and more
• CORE report Audio playback: Don’t want to read? No problem! Listen on the go.

Ethereum Transaction Life Cycle

1. Starting a Transaction: A transaction begins when a user or a smart contract owner creates a signed request. This request includes the recipient's address, the amount of Ether to send (if any), and other details like gas limit.
2. Checking the Digital Signature: The Ethereum network checks the digital signature to make sure the transaction is real and hasn't been altered.
3. Nonce Verification: The network verifies the sender's account nonce. The nonce is a number that increases with each transaction, helping to ensure the transactions are in order and preventing duplicate transactions.
4. Calculating Gas Fees: Gas is like fuel for transactions and smart contracts on Ethereum. The sender sets a gas limit, which is the maximum amount of gas they're willing to use. Gas fees, paid in Ether, cover the cost of computation and storage.
5. Broadcasting the Transaction: After passing initial checks, the transaction is shared with all nodes in the Ethereum network. These nodes start the process of including the transaction in a block.
6. Creating a Block: Validators, who are part of Ethereum's Proof of Stake (PoS) system, validate and propose new blocks that contain multiple validated transactions, including the new one.
7. Validating the Block: Other nodes check the transactions in the block to make sure everything is correct, including verifying signatures and ensuring funds are available.
8. Updating the State: Once a block is confirmed, each node updates its copy of the Ethereum blockchain. This includes updating account balances and contract data. Ethereum uses a Merkle tree structure to keep track of all these changes efficiently.
9. Transaction Confirmation: When a transaction is included in a block and that block is added to the blockchain, the transaction is considered confirmed and can't be reversed.
10. Executing Smart Contracts: If the transaction involves a smart contract, the contract's code runs based on the input data. This might update the contract's data, create events, or trigger other transactions.
11. Generating a Transaction Receipt: A receipt is created for the transaction, showing details like the amount of gas used and the block number where the transaction was included. This receipt can be checked to verify the transaction's completion and other details.

Source

Solana Transaction Life Cycle 

The lifecycle of a transaction on a non-mempool blockchain like Solana is as follows:

1. Transaction Creation and Submission: Users initiate transactions via wallets or dapps. These transactions are sent to RPC nodes through the JSON RPC API. Solana's RPC nodes primarily serve as non-voting validators to access on-chain data, unlike Ethereum's dual-purpose RPC nodes.
2. Leader Selection: Leaders, responsible for block production, are chosen based on the proof-of-stake mechanism. Validators take turns as leaders according to their stake.
3. Packet Ingress and QUIC: The RPC node connects to the leader node's Transaction Processing Unit (TPU) using QUIC, a protocol ensuring fast and secure data transfer, minimizing delays, and enhancing network performance.
4. Transaction Processing Unit (TPU):
5. Fetch Stage: Groups transactions into batches for efficient handling.
6. SigVerify Stage: Validates transaction signatures and removes duplicates.
7. Banking Stage: Executes transactions in parallel, ensuring efficiency.
8. Broadcast Stage: Broadcasts processed transactions to the network.
9. Gulf Stream Protocol: Solana's Gulf Stream Protocol preemptively forwards transactions to future leaders, avoiding traditional mempool congestion and ensuring high throughput and low latency.
10. Proof of History (PoH) and Commit: PoH timestamps transactions, maintaining order without traditional synchronization. Verified transactions are then committed to the ledger and broadcasted across the network.
11. Cluster Synchronization: Validators within Solana clusters synchronize their states to maintain a coherent and updated ledger, ensuring all validators have a consistent view of the blockchain.
12. Finalization and Confirmation: Once a supermajority of validators confirms the block, the transaction is finalized and permanently recorded on the blockchain, ensuring swift and reliable handling.

Source

Moreover, Solana's default validator implementation emphasizes continuous block production, in contrast to Ethereum's 12-second block intervals. This means that priority fees on Solana do not guarantee inclusion within a block.

This continuous process allows for faster transaction pre-confirmation, offering a significant advantage in terms of speed. However, this approach does not come without its challenges. The continuous nature of block-building in Solana's system can result in a lack of predictability and certain inefficiencies, particularly regarding the inclusion and prioritization of transactions.

The blockchain operates on a multi-threaded mechanism, allowing for the parallel processing of transactions. This structure aims to enhance the network's throughput and efficiency. Nonetheless, the decision-making behind the allocation of threads and compute units appears to be somewhat arbitrary, raising questions about the system's optimization and scalability.

Source

One of the most notable features of Solana's design is the concept of local fee markets. These markets are intended to operate independently for different types of transactions, such as NFT mints or DeFi operations. Theoretically, this structure should prevent a high-demand transaction type from disproportionately inflating fees across the network. However, in practice, the realization of local fee markets in Solana has been less than ideal.

The current mechanism for processing transactions in Solana is predominantly a first-price, greedy system. This setup does not provide clear guidance to users on the priority fee required for timely inclusion of their transactions, leading to inefficiencies. Particularly during periods of high network demand, users and protocols may increase their transaction fees in an uncoordinated and empirical manner, leading to an overall inefficient system.

This situation contrasts with Ethereum's implementation of EIP 1559, which introduced a more predictable base fee that adjusts with block saturation, offering a clearer and more efficient way for users to gauge the required transaction fees.

Finally, Solana transactions come with a fixed network fee per signature, typically one signature per transaction, amounting to 0.000005 SOL, approximately $0.0001 at the time of writing. Additionally, users have the option to include a priority fee, measured in the fee paid per requested compute unit, to gain higher priority within the Solana scheduler. It's important to note that Solana's block size limit is determined by compute units used, akin to Ethereum's gas target. Interestingly, Solana's fee structure allocates half of the network fees to burning while the remaining half is awarded to the leader.