[English] In-depth analysis of Solana mechanism design and architecture

avatar
Chainfeeds
a day ago
This article is machine translated
Show original

Chainfeeds Summary:

Crypto researcher Pavel Paramonov, after reading countless articles and documents on Solana's mechanism design and architecture, has compiled this comprehensive article covering Solana's mechanism design, fee market, MEV, and more.

Source:

https://x.com/paramonoww/status/1859574291337183282

Author:

Pavel Paramonov


Perspective:

Pavel Paramonov: Solana's Proof of History (PoH) consensus model combines Proof of Stake and a time variable. PoH is essentially the network's clock, recording events and their order, avoiding the need for validators to reach consensus on time. Solana does not have a public transaction pool (mempool). Most validators use the scheduling implementation provided by Solana Labs, but they can also choose other block building algorithms. The time variable is used to allocate leaders, who are responsible for generating blocks during each rotation period. Validators take turns being the leader at fixed time intervals, called Slots. Each Slot lasts 400 milliseconds, during which the designated leader generates a block, and other validators vote to verify its validity. If the leader misses a Slot, the network will move on to the next Slot. Solana uses a fork-based voting mechanism, with validators continuously generating blocks and incrementally adding valid votes in real-time. Solana's Stake updates are processed at the end of each Epoch, which lasts about 2-3 days and contains 432,000 Slots. The validator set for the next Epoch is determined based on the updated Stake information. The main sources of revenue for validators are: transaction fees, protocol rewards (inflation), maximum extractable value (MEV), and block rewards, including 50% of the base fee and priority fee (the other 50% is burned). Longer block times will reduce annual rewards, as fewer Epochs will affect the total SOL distribution. Solana's fee mechanism has two components: Base Fee: a fixed fee unrelated to the actual usage of compute units. Priority Fee: effective during network congestion, but the overall incentive mechanism is relatively weak. All Solana validators are nodes, but not all nodes are validators. Nodes can be signing and voting validators, or RPC providers processing wallet and DEX requests. Transactions specify writable accounts, and transactions involving the same account are processed sequentially, while non-conflicting transactions can be processed in parallel. In Solana's MEV, the current block leader has complete control over block production and scheduling. The priority fee incentivizes the leader to prioritize transactions, but including transactions is not mandatory. Solana's MEV can lead to over 50% of compute resources being wasted on failed arbitrage attempts.

Source

https://chainfeeds.substack.com

Source
Disclaimer: The content above is only the author's opinion which does not represent any position of Followin, and is not intended as, and shall not be understood or construed as, investment advice from Followin.
Like
Add to Favorites
Comments