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

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

Here are the answers to all questions:

Solana’s consensus model:

‣ Solana’s Proof of History (PoH) consensus model is essentially “Proof of Stake” Stake) + time variable".

‣ PoH is essentially the clock of the network, used to track events and their order (no validators are required to agree on the time).

‣ Solana does not have a mempool.

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

‣ The time variable allows assigning leaders to each rotation, who will be responsible for producing blocks.

Detailed mechanism:

When a validator is elected as the leader, it is responsible for producing new blocks and proposing them to the network.

Leadership rotates between validators at fixed intervals (called slots).

Each slot lasts 400 milliseconds, during which time a validator can generate a block. The slots are performed one after the other in sequence.

Each slot is assigned a lead validator to propose new blocks. Other validators vote on the validity of the block and finally confirm the block.

If a validator misses its assigned slot, the network will continue processing the next slot.

Features and process:

Solana uses a fork-based voting mechanism instead of single block voting. Validators continuously generate blocks and add valid votes in real time.

Validators and delegators can pledge or un-pledge SOL tokens within an epoch.

Based on the amount of staked SOL, a validator’s participation in the consensus process will be determined at the beginning of the cycle.

Solana’s staking model:

‣ Solana handles staking updates at the end of each epoch, which lasts approximately 2-3 days and consists of 432,000 blocks (slots).

‣ The validator schedule for the next cycle is determined based on the updated staking information.

The three main sources of income for validators:

Transaction fees

Protocol rewards (inflation)

Maximum withdrawable value ( MEV)

‣ The block reward received by the leader consists of 50% of the base fee and priority fee (the remaining 50% is burned).

‣ Longer block times may reduce annual rewards due to the reduced number of epochs, thus affecting the overall distribution of $SOL.

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

Solana’s staking model:

‣ Solana handles staking updates at the end of each epoch, which lasts approximately 2-3 days and consists of 432,000 blocks (slots).

‣ The validator schedule for the next cycle is determined based on the updated staking information.

The three main sources of income for validators:

Transaction fees

Protocol rewards (inflation)

Maximum withdrawable value ( MEV)

‣ The block reward received by the leader consists of 50% of the base fee and priority fee (the remaining 50% is destroyed).

‣ Longer block times may reduce annual rewards due to the reduced number of epochs, thus affecting the overall distribution of $SOL.

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

Solana’s voting model:

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

‣ Validators vote on the slot leader’s proposals, which requires a voting account and pay transaction fees for each vote.

‣ Solana’s on-chain voting mechanism charges transaction fees for each vote. A higher $SOL price increases the operating costs of validator voting due to increased transaction fees.

Fees details:

The cost of each vote is 0.000005 SOL, and validators spend approximately 2-3 SOL to vote in each cycle.

A cycle lasts 2-3 days and costs approximately 300-350 SOL per year, equivalent to approximately 1 SOL per day.

Solana’s fee market:

‣ Solana’s fee mechanism consists of two parts: base fee and priority fee.

‣ Fees are split into parts allocated to validators and burned, but the existing mechanism has some limitations:

It fails to incentivize efficient use of resources or align incentives across parties .

‣ There is a fee to create a new account (Rent Waiver Fee).

Charges are based on a flat rate of 6.96 SOL per MB of storage.

The cost is allocated to the newIn the created account, if the account is deleted, it can be retrieved.

Limitations:

Base fee does not take into account actual Compute Unit (CU) usage -> leading to resource waste

Priority fee is weak -> only during congestion Effective

Verifiers only receive 50% of fees -> Insufficient incentives (relying on inflation subsidies)

Quality of Service (SWQoS) based on stake weight:

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

‣ SWQoS prioritizes network traffic based on a validator’s staked amount, preventing low-staking validators from flooding the network with spam transactions.

Connection type:

Open connection: public use

Stake weight-based connection: reserved for validators, RPC nodes can utilize validators through trust relationships connect.

Advantages:

Improve transaction performance of pledged validators

Enhance network resilience

Improve resistance to Sybil attacks

Challenges:

Stake centralization risk

Trust issues between validators and RPC nodes

Entry barriers for small validators

‣ SWQoS Prioritize network access while prioritizing fees over transaction ordering

About Nodes vs. Validators:

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

‣ Types of nodes:

Validation node: responsible for signing and voting

RPC node: processing wallet and DEX requests

‣ Transaction Writable accounts will be designated:

Transactions affecting the same account are processed sequentially;

Transactions affecting different accounts can be processed sequentially or in parallel.

Solana’s Liquid Staking:

‣ Solana uses Delegated PoS (DPoS).

‣ Users stake SOL to the validator pool and can obtain LST (liquid pledge tokens).

‣ Staking rewards directly compete with lending returns:

If lending returns are higher than staking rewards, validators may withdraw funds, which may have an impact on network security.

Two types of LST tokens:

Reward tokens or rebasing tokens.

The user pledges 10 SOL to the pledge pool and obtains 10 LST tokens.

The staking pool distributes these SOLs to multiple validators to obtain vSOLs.

These vSOLs represent validators’ staking rewards.

LST tokens are generated by these vSOLsupport.

Verifier LST token (exclusive token).

The user pledges 10 SOL to the verifier LST and obtains v_lstSOL tokens, which represents his or her interest in staking SOL.

The validator pledges the SOL in the pledge pool to the Solana network to obtain sSOL.

These sSOL represent the validator’s interest in the staked SOL and related rewards.

Solana’s MEV:

‣ The leader of the current block has full control over block production and scheduling.

‣ Leaders are incentivized to process transactions via priority fees, but not necessarily enforced.

‣ Negative impact of MEV on Solana:

Over 50% of computing resources are wasted on failed arbitrage attempts.

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

The difference between Ethereum MEV and Solana MEV:

Block production method:

Solana's default validator continuously produces blocks, smoothly processing and containing transactions.

Ethereum processes transactions in batches of 12 seconds.

Impact of MEV:

Ethereum:

High network fees

Reduced block space

Users Being flanked and jumped

Solana:

Searchers try to squeeze in trades by spamming them.

Failed transactions waste computing resources.

A small number of searchers get most of the profits.