Author: Pavel Paramonov Source: X, @paramonoww Translation: Golden Finance
In the past six months, I have read countless articles and documents about Solana's mechanism design and architecture. I have summarized the most important information in a long article. The content covers topics such as mechanism design, fee market, MEV, etc.
Here are the answers to all your questions:
Solana's consensus model:
‣ Solana's Proof of History (PoH) consensus model is essentially "Proof of Stake + Time Variable".
‣ PoH is essentially the network's clock that tracks events and their order (without requiring validators to reach a consensus on time).
‣ Solana has no mempool.
‣ Currently, most validators use the scheduler implementation in the Solana client provided by @solanalabs. However, validators can also choose to run different block construction algorithms.
‣ The time variable allows to assign leaders to each rotation, and these leaders will be responsible for producing blocks.
Detailed Mechanics:
When a validator is elected as a 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 produce a block. Slots are taken one after another in sequence.
Each slot is assigned a leader validator, who proposes new blocks, and other validators vote on the validity of the blocks and eventually confirm the blocks.
If a validator misses its assigned slot, the network will move on to the next slot.
Features and Process:
Solana uses a fork-based voting mechanism instead of voting on a single block. Validators continuously generate blocks and add valid votes in real time.
Validators and delegators can stake or unstake SOL tokens within an epoch.
Based on the amount of SOL staked, the participation of the validator in the consensus process will be determined at the beginning of the epoch.
Solana's Staking Model:
‣ Solana processes staking updates at the end of each epoch, each of which lasts approximately 2-3 days and consists of 432,000 blocks (slots).
‣ The validator schedule for the next epoch is determined based on the updated staking information.
There are three main sources of income for validators:
‣ Leaders receive a block reward consisting of 50% of the base fee and priority fee (the remaining 50% is burned).
‣ Longer block times may reduce annual rewards due to the reduction in the number of epochs, thus affecting the overall distribution of $SOL.
‣ Solana calculates the SOL reward pool generated by inflation for each epoch and distributes rewards to validators and stakers based on their voting and staking status in the previous epoch.
Solana’s Staking Model:
‣ Solana processes stake 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 epoch is determined based on the updated stake information.
Three main sources of income for validators:
‣ Leaders receive a block reward consisting of 50% of the base fee and priority fee (the remaining 50% is destroyed).
‣ Longer block times may reduce annual rewards due to a reduced number of epochs, thus affecting the overall distribution of $SOL.
‣ Solana calculates an inflation-generated SOL reward pool for each epoch and distributes rewards to validators and stakers based on their voting and staking status in the previous epoch.
Solana’s Voting Model:
‣ Solana does not have a strict minimum SOL requirement for validators, but a voting account is required to participate in consensus.
‣ Validators vote on slot leader proposals, which requires a voting account and pays transaction fees for each vote.
‣ Solana’s on-chain voting mechanism charges a transaction fee for each vote. Higher $SOL prices increase the operational cost of validator voting due to increased transaction fees.
Fee Details:
Each vote costs 0.000005 SOL, and validators spend about 2-3 SOL per cycle to vote.
A cycle lasts 2-3 days, costing about 300-350 SOL per year, which is about 1 SOL per day.
Solana's Fee Market:
‣ Solana's fee mechanism consists of two parts: base fees and priority fees.
‣ The fees are split into parts allocated to validators and burned, but the existing mechanism has some limitations:
‣ There is a fee to create a new account (rent exemption fee).
Limitations:
Base fee does not take into account actual computing unit (CU) usage -> leads to waste of resources
Priority fees are weak -> only work in times of congestion
Validators only get 50% of the fee -> insufficient incentive (relies on inflation subsidies)
Stake Weight Based Quality of Service (SWQoS):
‣ In the event of network congestion, the SWQoS mechanism can be used to prioritize certain types of transactions.
‣ SWQoS prioritizes network traffic based on the validator's stake amount, preventing low-stake validators from flooding the network with junk transactions.
Connection Type:
Open Connection: Public Use
Connection based on stake weight: Reserved for validators, RPC nodes can utilize validator connections through trust relationships.
Advantages:
Improve transaction performance for staked validators
Enhance network resilience
Increase resistance to Sybil attacks
Challenges:
Risk of staking centralization
Trust issues between validators and RPC nodes
Barriers to entry for small validators
‣ SWQoS prioritizes network access, while priority fees prioritize transaction ordering
About nodes and validators:
‣ All validators are nodes, but not all nodes are validators.
‣ Node types:
‣ Transactions specify writable accounts:
Solana's Liquid Staking:
‣ Solana uses Delegated PoS (DPoS).
‣ Users stake SOL into the validator pool and can obtain LST (liquid staking tokens).
‣ Staking rewards compete directly with lending yields:
Two types of LST tokens:
Reward tokens or rebasing tokens.
A user stakes 10 SOL to a staking pool and receives 10 LST tokens.
The staking pool distributes these SOLs to multiple validators, receiving vSOLs.
These vSOLs represent the validator’s staking rewards.
LST tokens are backed by these vSOLs.
Validator LST token (exclusive token).
Users stake 10 SOL to validator LST and receive v_lstSOL tokens, which represent their staked SOL.
Validators stake SOL in the staking pool to the Solana network and receive sSOL.
These sSOL represent the validator’s stake 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 through priority fees, but are not necessarily enforced.
‣ Negative impact of MEV on Solana:
‣ Solana has no public memory pool (mempool), and transactions are forwarded directly to the current and next leaders.
Differences between Ethereum MEV and Solana MEV:
Block production method:
Solana's default validators continuously produce blocks, smoothly process and include transactions.
Ethereum processes transactions in batches of 12 seconds.
Impact of MEV:
Ethereum:
Solana:
Searchers try to squeeze in transactions through spam transactions.
Failed transactions waste computing resources.
A small number of searchers get most of the profits.