Solana mechanism design and architecture in-depth analysis

Author: Pavel Paramonov Source: X, @paramonoww Translation: Bitchain Vision

Over the past six months, I have read countless articles and documents on Solana mechanism design and architecture.I’ll summarize the most important information in a long article.The content covers topics such as mechanism design, cost market, and MEV.

Here are the answers to all questions:

Solana’s consensus model:

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

‣ PoH is essentially the clock of the network, used to track events and their order (verifiers do not require consensus on time).

‣ Solana has no memory pool (mempool).

‣ Currently, most validators use schedulers in the Solana client provided by @solanalabs.However, validators can also choose to run different block building algorithms.

‣ Time variables allow the assignment of leaders for each rotation, which will be responsible for the production blocks.

Detailed mechanism:

When a validator is selected 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 the validator can generate a block.The slots are carried out one after another in sequence.
Each slot will be assigned a leader validator to propose a new block, and other validators vote on the validity of the block and finally confirm the block.
If the validator misses its allocated slot, the network will continue to process the next slot.

Features and procedures:

Solana uses a fork-based voting mechanism, rather than a single block voting.Validators will generate blocks continuously and add valid votes in real time.
Verifiers and delegators can pledge or revoke staked SOL tokens within one cycle (epoch).
Depending on the number of SOLs pledged, the 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 cycle (epoch), each cycle lasts approximately 2-3 days and consists of 432,000 blocks (slots).

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

The three main sources of income for validators:

Transaction fee
Agreement Reward (Inflation)
Maximum Extractable Value (MEV)

‣ The block rewards received by the leader include 50% of the base and priority fees (the remaining 50% are destroyed).

‣ Longer block times may reduce annual rewards because the number of cycles is reduced, which affects the overall allocation of $SOL.

‣ Solana calculates the SOL reward pool generated by inflation for each cycle and allocates rewards to validators and stakers based on the vote and stake state of the previous cycle.

Solana’s staking model:

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

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

The three main sources of income for validators:

Transaction fee
Agreement Reward (Inflation)
Maximum Extractable Value (MEV)

‣ The block rewards received by the leader include 50% of the base and priority fees (the remaining 50% are destroyed).

‣ Longer block times may reduce annual rewards because the number of cycles is reduced, which affects the overall allocation of $SOL.

‣ Solana calculates the SOL reward pool generated by inflation for each cycle and allocates rewards to validators and stakers based on the vote and stake state of the previous cycle.

Solana’s voting model:

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

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

‣ Solana’s on-chain voting mechanism charges transaction fees for each vote.Higher $SOL prices increase the operating costs of validator voting due to increased transaction fees.

Cost details:

The cost per vote is 0.000005 SOL, and the validator spends approximately 2-3 SOL per cycle to vote.
A cycle lasts for 2-3 days, and costs about 300-350 SOL per year, equivalent to about 1 SOL per day.

Solana’s Cost Market:

‣ Solana’s fee mechanism includes two parts: basic fee and priority fee.

‣ The fees are split into the parts allocated to validators and destroyed, but the existing mechanism has some limitations:

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

‣ A fee is required to create a new account (the rent waiver is free).

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

limitation:

The basic expenses are not considered for the use of the actual computing unit (CU) -> resulting in waste of resources
Weak priority fees -> Only effective in congestion
Verifiers only receive 50% of the fee -> Inadequate incentives (rely on inflation subsidies)

Quality of Service (SWQoS) based on staking weights:

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

‣ SWQoS prioritizes network traffic based on the number of stakes of verifiers to prevent low-stakes from flooding the network through spam transactions.

Connection type:

Open connection: public use
Stake weight-based connection: reserved for validators, and RPC nodes can utilize validator connections through trust relationships.

Advantages:

Improve transaction performance of staking verifiers
Enhance network resilience
Improve Sybil attack resistance

challenge:

Risk of centralized pledge
Trust issues between validators and RPC nodes
The barriers to entry for small validators

‣ SWQoS prioritizes network access, while priority fees prioritizes transaction sorting

About Nodes and Verifiers:

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

‣ The type of node:

Verification Node: Responsible for signature and voting
RPC Node: Process wallet and DEX requests

‣ The transaction will specify a writable account:

Transactions affecting the same account are processed in sequence;
Transactions affecting different accounts can be processed sequentially or in parallel.

Liquid staking for Solana:

‣ Solana uses Delegated PoS (DPoS).

‣ The user stakes SOL to the validator pool and can obtain LST (liquid staked tokens).

‣ Pledge rewards directly compete with loan income:

If the borrowing income is higher than the pledge reward, the verifier may withdraw funds, which may have an impact on cybersecurity.

Two types of LST tokens:

Reward tokens or base tokens.

The user stakes 10 SOL to the stake pool and obtains 10 LST tokens.
The staking pool assigns these SOLs to multiple validators to obtain vSOLs.
These vSOLs represent staking rewards for validators.
LST tokens are supported by these vSOLs.

Verifier LST Token (Exclusive Token).

The user stakes 10 SOL to the verifier LST and obtains the v_lstSOL token, representing his or her staked SOL.
The verifier stakes the SOL in the staking pool to the Solana network to obtain sSOL.
These sSOLs represent validators’ interest in the staking SOL and related rewards.

Solana’s MEV:

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

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

‣ The negative impact of MEV on Solana:

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

‣ Solana has no 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, processes and includes transactions smoothly.
Ethereum processes transactions in batches in 12 seconds.

Impact of MEV: