Solana Mechanism Design and Architecture Depth Analysis

Author: Pavel Paramonov Source: X, @paramonoww Translation: Golden Finance

In the past six months, I have read numerous articles and documents about the mechanism design and architecture of Solana. I have summarized the most important information in a long article. The content covers topics such as mechanism design, fee market, and MEV.

Here are the answers to all questions:

Solana's Consensus model:

‣ Solana's Proof of History (Proof of History, PoH) Consensus model is essentially "Proof of Stake (Proof of Stake) + time variable".

‣ PoH is essentially the clock of the network, used to track events and their order (Consensus on time is achieved without validators).

‣ Solana does not have a mempool (mempool).

‣ Currently, most validators use the scheduler in the Solana client provided by @solanalabs. However, validators can also choose to run a different Block construction Algorithm.

‣ Time variables allow leaders to be assigned for each rotation, who will be responsible for producing Block.

Detailed Mechanism:

When a validator is selected as a leader, it is responsible for producing new blocks and proposing them to the network.
The leadership rotates between validators at fixed intervals, called slots.
Each slot lasts for 400 milliseconds, during which validators can generate a Block. Slots are processed one after another in order.
Each slot is assigned a leader validators to propose a new Block, and other validators vote on the validity of the Block to finally confirm the Block.
If validators miss their assigned slot, the network will continue to process the next slot.

Features and Process:

Solana uses a fork-based voting mechanism instead of a single Block voting mechanism. Validators continuously generate Blocks and add valid votes in real time.
Validators and delegates can stake or unstake SOL Tokens within one epoch.
The degree of participation of validators in the Consensus process will be determined at the beginning of each cycle based on the stake amount of SOL.

Solana's stake model:

‣ Solana processes stake updates at the end of each epoch, which lasts approximately 2-3 days and consists of 432,000 blocks.

‣ The scheduling table of validators for the next cycle is determined based on the updated stake information.

The three main sources of income for validators are:

Trading fee
protocol rewards (inflation)
maximal extractable value（MEV）

‣ The leader's Block Reward includes 50% of the base fee and priority fee (the remaining 50% is destroyed).

‣ Longer block time may reduce annual rewards, as the number of cycles decreases, thus affecting the overall allocation of $SOL.

‣ Solana calculates the inflation-generated SOL reward pool for each epoch and allocates rewards to validators and stakers based on the voting and stake status of the previous epoch.

Solana's stake model:

‣ Solana processes stake updates at the end of each epoch, which lasts approximately 2-3 days and consists of 432,000 blocks.

‣ The scheduling table of validators for the next cycle is determined based on the updated stake information.

The three main sources of income for validators are:

Trading fee
protocol rewards (inflation)
maximal extractable value（MEV）

‣ The leader's Block Reward includes 50% of the base fee and priority fee (the remaining 50% is destroyed).

‣ Longer block time may reduce annual rewards, as the number of cycles decreases, thus affecting the overall allocation of $SOL.

‣ Solana calculates the inflation-generated SOL reward pool for each epoch and allocates rewards to validators and stakers based on the voting and stake status of the previous epoch.

Solana's voting model:

‣ Solana does not have a strict minimum SOL requirement for validators, but participating in Consensus requires a voting account.

‣ Validators vote on proposals from slot leaders, which requires a voting account and Money Laundering payment for each vote.

The on-chain voting mechanism of Solana charges Money Laundering for each vote. A higher $SOL price will increase the operating cost of validators due to the increased transaction fees.

Fee Details:

The cost of each vote is 0.000005 SOL, validators spend approximately 2-3 SOL per epoch for voting.
A cycle lasts for 2-3 days, costing approximately 300-350 SOL per year, equivalent to about 1 SOL per day.

Solana's fee market:

The fee mechanism of Solana includes two parts: base fee and priority fee.

‣ The cost is split into portions allocated to validators and destroyed, but there are some limitations in the existing mechanism:

It failed to incentivize efficient resource utilization or align incentives for all parties.

‣ Creating a new account requires payment of fees (rental exemption fee).

The cost is calculated at a fixed rate, and 6.96 SOL is required for each MB of storage.
This fee is allocated to the newly created account and can be retrieved if the account is deleted.

Limitations:

resulting in resource waste Only effective during congestion insufficient incentives (dependent on inflation subsidies)

Service Quality Based on Stake Weight (SWQoS):

‣ In the case of network congestion, the SWQoS mechanism can be used to prioritize the processing of certain types of transactions.

‣ SWQoS prioritizes network traffic based on the stake amount of validators, preventing low-stake validators from flooding the network with spam transactions.

Connection Type:

Open Connection: Public Use
Stake-weighted connection: Reserved for validators, RPC nodes can utilize validators connection through trust relationship.

Advantages:

Improve transaction performance with stake validators
Enhanced Network Resilience
Improve Sybil attack resistance

Challenge:

Stake Centralization Risk
Trust issue between validators and RPC Nodes
Barriers to entry for small validators

‣ SWQoS prioritizes network access over transaction ordering by prioritizing fees

About Node and validators:

‣ All validators are Nodes, but not all Nodes are validators.

‣ Types of Node:

Verify Node: responsible for signature and voting
RPC Node: Processing Wallet and DEX requests

‣ The trading venue will specify the writable account:

Transactions that affect the same account are processed in order;
The transactions of different accounts may be processed sequentially or in parallel.

Solana's liquid stake (Liquid Staking):

‣ Solana adopts Delegated Proof of Stake (DPoS) for attestation.

Users can stake SOL to the validators pool and receive LST (Liquid Stake Token).

‣ The stake rewards compete directly with the lending profits:

If the lending interest rate is higher than the stake reward, validators may withdraw funds, which may affect network security.

Two types of LST Token:

Reward Token or Base Token.

Users stake 10 SOL to the stake pool and receive 10 LST Tokens.
The staking pool allocates these SOL to multiple validators to obtain vSOL.
These vSOL represent stake rewards for validators.
LST Token is supported by these vSOL.

validators LST Token (exclusive Token).

Users stake 10 SOL to validators LST, and obtain v_lstSOL Token, representing their stake in SOL.
validators stake SOL in the stake pool to earn sSOL on the Solana network.
These sSOL represent the rights of validators to stake SOL and related rewards.

Solana's MEV:

‣ The current leader of the Block has complete control over Block production and scheduling.

Leaders are motivated to process transactions through priority fees, but it is not necessarily enforced.

‣ The negative impact of MEV on Solana:

More than 50% of computing resources are wasted on failed Arbitrage attempts.

Solana does not have a public mempool(memory pool), transactions are directly forwarded to the current and next leader.

The Difference Between Ethereum MEV and Solana MEV:

Block production method:

Solana's default validators continue to produce Blocks, handle transactions smoothly, and include them.
Ethereum processes transactions in batches of 12 seconds.

Impact of MEV: