Validator and Fee Economics
Deep Dive into Solana's Mechanics, Comparative Analysis and Long-Term Outlook
Let's take a joyride through the bustling world of the Solana network!
Picture this: transactions whizzing through the digital expressways, validators standing tall like futuristic guardians, all powering the sustainability engine.
Now, imagine you, the fearless explorer, delving into the vast wonders of the Solana blockchain. Your mission? To shoot tokens across the globe to a buddy. Little did you suspect the rollercoaster ride waiting for you backstage!
As you step into this techno-realm, your brain starts doing the cha-cha with questions: How in the world do these validators keep the network grooving with such finesse? And what's the scoop on transaction fees? How do they grease the wheels and keep this gear spinning? 🎢✨
But here’s the puzzle - In a world where trust is at a premium and decentralization is the name of the game, how do Solana’s validators strike the prefect balance between security and speed, ensuring a seamless experience for users like us?
In the world of blockchain, validators are the guardians of trust, ensuring the integrity of transactions and the stability of the network. Their economics anchor sustainable decentralization, where every block forged is a testament to the power of distributed consensus.
In this article, we will dive into the core components that form the backbone of Solana’s blockchain ecosystem, unravelling the intricacies of validator incentives, fee structures and the sustainable future of the network.
Throughout our expedition, we will encounter four main areas of focus:
Understanding Solana Consensus Mechanism
In-Depth Analysis of Solana Validators:
Role and significance of validators in the ecosystem
Client Diversity
Challenges faced by validators on Solana and potential solutions
Case studies
Exploration of Fee Economics and Spam Reduction:
Structure and distribution of fees within the Solana network and their role in validator economics
Impact of fee economics on network performance, user experience, and validator incentives
Comparative analysis of fee economics between Solana and other major blockchains (ETH, BTC, Avalanche, Cardano)
Potential for negative commission rates
Sustainability and Future Outlook:
Current state of validator incentives, fees
Long-term economic viability of validators
Explore innovative models for sustainability
Discuss evolving roles of fees and incentives
Understanding Solana - Network Design
Solana is a blockchain platform announced in 2017 and the first block in the ledger was created in March 2020. Solana uses consensus mechanism called PoH (Proof of History), along with PoS (Proof of Stake) which makes the network structure and the consensus mechanism simpler than competing platforms such as Ethereum. This enables to process transactions in a fast and scalable manner without compromising on security.
Solana’s consensus mechanism, comprising Proof of History (PoH) and Tower BFT, revolutionizes decentralized network performance and scalability. At its core, Solana introduces a unique approach to consensus, providing a robust infrastructure capable of handling high throughput and maintaining global read consistency.
Complex words? Let’s break it down —
What is Proof of History (PoH)?
PoH operates as a sequence of cryptographic computation, diligently recorded and verified to ensure accurate timestamping of events. By cryptographically linking each event to the previous one, PoH enables nodes to synchronize their clocks without the need for continuous communication. This innovative approach not only enhances network efficiency but also supports horizontal scaling, allowing multiple nodes to collaborate seamlessly.
Validators take turn acting as the leader (PoH Generator) to generate PoH sequence.
This rotation ensures that no single validator has centralized control over the PoH generation process, promoting decentralization and network security.
This video can help explain much better, have a look:
Solana validators leverage the information embedded within the ledger itself to autonomously determine the validity of transactions, eliminating the need to await from other nodes. This efficiency stems from the predictability enabled by PoH, which eradicates delays associated with validator consensus. Instead, validators operate within a structured “leader rotation” framework, where leadership privileges are predetermined and distributed based on each validator’s stake in the network.
This enables fairness in the system, as validators are granted leadership roles proportional to their stake, although the specific timing remains randomized.
For eg. if you have 10% of all stake, you will be the leader 10% of the time, but you wont know which 10% of the time.
Do check out the leader rotation live on Solana Beach.
What is Tower BFT?
Tower BFT is Solana’s custom implementation of the Practical Byzantine Fault Tolerance (PBFT) consensus algorithm. It is specifically optimized to leverage the synchronized clocks provided by Proof of History (PoH), Solana’s innovative timekeeping mechanism. This optimization helps reducing messaging overhead and latency, enhancing the network’s overall performance.
Tower BFT prioritizes liveness over consistency, aiming to maximize the period during which a sufficient number of non-fault replicas are in agreement.
It uses PoH as the network clock, enabling replicas to compute and enforce, exponentially increasing timeouts without relying on external communication.
Integrating with PoH —
Solana’s implementation of PBFT integrates seamlessly with PoH, leveraging it as the network’s time source.
Proof of History operates as a Verifiable Delay Function, providing a cryptographically secure way to verify the passage of time between events.
By using PoH, Solana ensures that all nodes in the network compute the exact same result without the need for peer-to-peer communication.
Transaction Flow in Solana’s Network
Transaction initiation: Users initiate transactions by submitting them to the network. These transactions could be token transfers, smart contract execution or decentralized application (dApp) interactions.
Proof of History Timestamping: Post submission, transactions are timestamped using the PoH mechanism. It ensures accurate sequencing and timestamps for events, providing a verifiable passage of time without the need for continuous communication.
Validation by Validators: Validators, selected through the PoS mechanism, validate and process transactions. They verify the authenticity of each transaction, ensuring compliance with network rules and consensus protocols.
Tower Byzantine Fault Tolerance (Tower BFT) Consensus: It is optimised to leverage PoH’s synchronized clocks, ensuring transactions are processed efficiently and securely, maximizing throughput while maintaining integrity.
Confirmation and Inclusion in the Ledger: Validated transactions are confirmed and included in the blockchain ledger. This immutable record of transactions serves as the source of truth within the Solana network.
Broadcasting and Replication: The confirmed ledger is broadcasted to all nodes in the network for replication. This ensures that every node maintains a record (an up-to-date copy of the blockchain), promoting decentralization and redundancy.
Finality and Settlement: Once a transaction is included in a block and added to the blockchain, it achieves finality. This means that the transaction is irreversible, recorded and settled, contributing to the ongoing operation and security of the network.
Note: Solana has two types of transactions — voting and non-voting. In simple terms, voting transactions are specially designed for validators to participate in consensus mechanism, whereas non-voting transactions encompass other type of transactions that occur (asset transfers, smart contract interactions etc).
What is Proof of Stake (PoS)?
Solana’s consensus mechanism combines PoH and PoS to create a robust and efficient network structure. While PoH serves as the backbone of the network’s timekeeping mechanism, PoS plays a crucial role in determining the validators responsible for confirming transactions and maintaining consensus.
Proof of Stake (PoS) is designed for quick confirmation of the current sequence produced by the Proof of History generator and for punishing any misbehaving validators. Validators in Solana’s PoS system commit (lockup) a certain amount of SOL (Solana token) as collateral, known as bonds to validate transactions. These bonds act as a security measure, ensuring that validators have a stake in the network’s integrity. Moreover, Solana implements slashing as a mechanism to deter validators from confirming conflicting transactions. Validators risk having their bonds destroyed if they vote for different branches, discouraging dishonest behaviour and maintaining the network’s security.
Achieving a supermajority consensus among validators is crucial for the integrity and security of the network. A supermajority indicates widespread agreement among validators, making it difficult for malicious actors to manipulate the network. Solana’s PoS system ensures the economic cost of launching an attack against the blockchain is significant, as the least one-third of the network’s validators would need to vote maliciously for a branch to be considered invalid.
CAP theorem (named after Brewer’s theorem) states that, a distributed system can only guarantee two out of three properties (consistency, availability, partition tolerance) at any given time. Solana has chosen consistency since it has objective measure of time for availability.
In situations where network partitions occur, Solana’s PoS system dynamically adjusts by un-staking validators who become unavailable. This approach ensures the network’s consistency while maintaining availability in the face of partitions. However, the speed of un-staking depends on the number of validators, impacting their ability to participate in consensus and influence their stake in the network.
Overall, Solana’s integration of PoS alongside PoH and Tower BFT enables the network to achieve high throughput, scalability and security while maintaining decentralization and economic efficiency.
In-Depth Analysis of Solana Validators
The Role of Validators
Validators play a crucial role in the Solana network by validating transactions, maintaining consensus and securing the blockchain. Operating a Solana validator involves two primary types of expenses: (1) infrastructure/hardware and (2) labor. For a modest operation, this might involve a single node setup that's economically viable yet capable of running the Solana software, managed by an enthusiast dedicating a few hours weekly.
A mid-sized validator set-up would typically escalate to dual nodes featuring improved hardware and higher bandwidth capacities, supported by a part-time dedicated team for system reliability, roughly equivalent to a quarter of a full-time employee's attention solely on Solana operations.
Click the link to check out official recommendations. Go to Solana Validator Cost estimator via this link to explore relevant variables, their interactions and correlations.
These roles are crucial, as validators are the backbone of the network, ensuring transaction processing, consensus, and overall blockchain integrity.
Validators participate in the key functions of the network:
Transaction Validation - Validators verify the authenticity of transactions submitted to the network. They verify if the transaction comply with the network rules and consensus protocols before including them into the ledger/blockchain.
Consensus Maintenance - As mentioned earlier, validators participate in the consensus mechanism, which involves reaching an agreement on the order and validity of transactions. All validators collaborate to achieve consensus, ensuring that all nodes in the network agree on the state of the ledger.
Block Production - Validators take turns acting as leaders (PoH generators) to produce blocks of transactions. They are responsible for creating new blocks, appending them to the blockchain, and propagating them to other nodes in the network.
Network Security - By validating transactions and participating in the consensus process, they help prevent double-spending, Sybil attacks and other malicious activities.
Decentralization - They contribute by distributing the responsibility f or transaction validation and block production among multiple nodes.
Validators ensure smooth operation, security, and decentralization of the network. Their active participation is essential for maintaining the integrity and trustworthiness of the network. But have you wondered how the process works?
Client Diversity
Before getting into this topic, it’s essential to consider the underlying hardware requirements because the client software interacts closely with the hardware infrastructure on which it operates. Here’s why hardware is relevant when discussing clients:
Performance Optimization: High-performance hardware can execute computational tasks more efficiently, leading to faster transaction processing and improved network responsiveness.
Resource Utilization: Understanding hardware requirements like CPU utilization, memory usage and disk I/O helps ensure that the underlying infrastructure can support the resource demands of client software (Solana in this case).
Scalability Consideration: The hardware infrastructure supporting the blockchain clients must be scalable to accommodate increasing demands without compromising on performance or reliability.
Fault Tolerance and Redundancy: Redundant hardware set-ups like backup servers or failover mechanisms are essential for maintaining to mitigate the risk of downtime or data loss.
Security Implications: To enhance security posture of the network, hardware-based encryption and tamper-resistant components play a crucial role.
Therefore, by aligning the client software with suitable hardware infrastructure, blockchain networks can operate efficiently and reliably, meeting the demands of users and applications effectively.
Bitcoin and Ethereum are two of the most well established and widely used blockchain networks, each with its own approach to node operation and hardware requirements.
Bitcoin, being the first and most renowned cryptocurrency, has relatively straightforward hardware requirements for running a node. Bitcoin node primarily requires computational power in the form of specialized hardware known as ASIC (Application-Specific Integrated Circuit) miners. These ASIC miners are purpose-built for performing cryptographic calculations necessary for mining BTC. However, the hardware requirements for running a node are generally considered to be within the reach of individual users, especially given the wide adoption of ASIC market.
In Ethereum’s PoS model, validators are chosen to create new blocks and validate transactions based on the amount of cryptocurrency they hold and are willing to “stake” as collateral. The hardware requirements for participating in the Ethereum network is very low. If interested, check out hardware details here. Validators can operate using standard consumer-grade hardware, such as standard personal computer, without the need of specialized equipment. The goals of Ethereum nd Bitcoin is to enable maximum number of people to be able to verify transactions on their nodes.
In contrast, Solana’s approach to hardware requirements differs, influenced by the backgrounds of its founders in the mobile industry, prioritizing software efficiency over universal accessibility. The emphasis on hardware adaptability (no fixed cap), reminiscent of Moore’s Law, depicts Solana’s commitment to continuous innovation and performance optimization. 😮
Alright now coming back to clients — think of them as an operator who runs a piece of software that allows a computer to function as a blockchain node, to validate transactions and maintain copy of the blockchain ledger. This is possible with necessary hardware demands.
Client diversity emerges as a critical consideration within the blockchain ecosystem, driven by its role in mitigating software bugs and ensuring network liveness. But why right? Why does it matter? Consider an analogy — If you are a decentralized network, you want all aspects of your functions to be relatively decentralized. If 66% of the network uses a single node client and node issues a faulty update or synchronizes the blocks in wrong order, it affects the functioning of the blockchain. This would be a consensus issue.
While Ethereum and Bitcoin actively cultivates diversity to safeguard against the failure of any single client, Solana unlike them grapples with achieving the same with its multi-threaded execution approach (more on this later). The network’s reliance on a single dominant client developed by Solana Labs underscores the need for broader diversity to enhance network resilience and reduce susceptibility to potential software vulnerabilities. Solana had a bad history with 100% uptime, unlike Ethereum which guarantees 100% uptime. You can learn more on Solana’s early history in this piece.
However, Solana had continuously achieved 100% uptime in 2023 and maintained 100% uptime during the recent $JUP airdrop too.
Currently, Solana has two functional clients: (1) developed by Solana Labs and other, (2) Jito-Solana, utilized by remaining network validators. Despite offering some diversity, Jito-Solana's status as an extension of Solana Labs' client falls short of providing complete redundancy, leaving room for improvement in achieving a more balanced client distribution among validators. Network outages and performance degradation in the past underscore the urgency of addressing these challenges to uphold the network's reliability and security.
As of October 2023 Validator Health Report, 68.5% of the network’s validators run Solana Labs’ client whereas the 31.45% of validators run by Jito Labs client.
Efforts to enhance Solana's client diversity are evident in ongoing initiatives such as the development of Firedancer client, aimed at bolstering validators' resilience and reducing network latency. Firedancer's distinct architecture, developed independently of Solana Labs' client, offers the potential to mitigate systemic bugs and enhance overall network stability. As Solana continues its journey toward greater client diversity, the emergence of new clients like Firedancer signals progress toward a more resilient and decentralized network infrastructure.
Looking ahead, Solana anticipates reduced dependency on Solana Labs' clients and a more equitable distribution of clients among validators with the adoption of initiatives like Firedancer and Sig.
Additionally, TinyDancer, a light client for Solana, is in active development. Light clients do not function like producing blocks and participating in consensus, however it makes easier for users to verify the state of a blockchain without running full node themselves.
These developments mark significant strides in fortifying Solana's network resilience and decentralization, aligning with its overarching goal of providing a high performing and secure blockchain ecosystem.
Challenges Faced by Validators
After exploring the foundational components of Solana’s blockchain ecosystem, it’s evident that validators play a pivotal role in ensuring the network’s integrity and functionality. As guardians of trust, validators face a myriad of challenges in maintaining consensus, processing transactions, and safeguarding against malicious activities. Let’s dig deeper into the challenges and examine how validators navigate them to uphold the reliability and security of the Solana network —
Solana had faced three major outages, along with several instances of degraded performance and network instability majorly in 2022 and early 2023. These disruptions largely stemmed from consensus issues as outlined by Jump in this article.
One of the key contributions to network stalling has been the absence of effective congestion control mechanisms and delays in network processing. However, Solana has undertaken several network upgrades to bolster validators’ resilience against transaction floods, thereby, enhancing congestion control. To remind you, with a 400ms block time, Solana aims to maintain efficient transaction processing.
Validators play a crucial role in maintaining consensus by independently verifying and acknowledging proposed blocks. However, consensus messages can be lost when validators experience packet processing delays. Validators process these packets to reach consensus on the state of the blockchain. If validators experience delays in processing these packets, it can result in synchronization issues and disrupt the consensus process. Firedancer, through its innovative messaging framework, addresses this issue bypassing certain network hubs, thereby reducing network latency. Considering this, Firedancer can offer advantages in mitigating shared bugs and enhancing network reliability.
This trend of primary and secondary clients by validators can further enhance network resilience with secondary clients serving as failsafes.
Another significant challenge faced by Solana validators stems from the operational complexities associated with RPC (Remote Control Call) nodes. Remote Procedure Call (RPC) is a software communication protocol which allows a program (client) to request services from remote program (the server), without needing details about the server’s network.
In the context of Solana, RPC nodes serve as critical components of the Solana network infrastructure, facilitating communication between dApps and the blockchains. These nodes are responsible for processing requests from dApps, retrieving blockchain data, and providing essential services to support the functional of Solana dApps.
In the decentralized ecosystem, RPC serve their role by enabling dApps to interact with the blockchain without needing to run their own full nodes. The challenge in here is any disruptions or inefficiencies in RPC node functionality can have ripple effects across the network, affecting transaction processing, data retrieval, and overall user experience. Therefore, performance of RPC nodes can directly impact validator operations, as it can hinder critical tasks like block propagation and transaction verification. With various players like Helius, Triton, Syndica, Ankr, Quicknode and others, validators must monitor and navigate RPC node services effectively.
Solana is a pioneer for low transaction fees and that’s good for users. However, the byproduct of it is transaction flooding or a distributed denial of service (DDoS) attack. DDoS attack aims to flood the network with a massive volume of transaction requests, rendering it unable to process legitimate transactions effectively. Typically, these attacks involve a large number of compromised computers or devices, collectively known as botnet. Solana suffered with two major DDoS attacks in 2021, one of them is at the time of Grape protocol’s IDO.
To prevent these spams and incentivizing validators, Solana designed a fee structure to maintain the network’s performance while balancing non-uniform shocks in supply and demand. Some of these fees are dynamically programmed based on network conditions, allowing to adjust fees dynamically which helps in pricing demand appropriately at a given time. Additionally, validators earn through inflation commission by participating in the consensus and through block rewards. However, validators need to carefully manage their economic incentives and operational costs. This includes factors like staking requirements, transaction fees, and potential rewards or penalties for validating transactions accurately. In short-term, Solana is relying on inflationary rewards but the alignment of economic incentives is another challenge in the long-term to compensate validators as it looks to sustain network security with just transaction fees (more on this later).
Therefore, to summarize key challenges by validators:
Consensus Issues: Validators must navigate consensus-related challenges, such as ensuring all nodes agree (effective communication between nodes) on the order and validity of transactions. If consensus fails, network will face stalls.
Network Congestions: Solana had faced outages and degraded performance with no guarantee on 100% uptime. If DeFi to thrive in any blockchain, it has to maintain stability.
Transaction Flooding: Low transactions make it cheaper for malicious attacks to flood (spam) the network with transactions.
Packet Processing Delays: It can disturb synchronization among validators, leading to consensus failures.
Client Diversity: Due to the lack of diverse clients, it is prone to software bugs and vulnerabilities, forcing validators to depend on couple of clients.
Specific Hardware Requirements: Validators need to ensure their hardware infra meets the network’s upgrades and performance.
RPC Nodes: Inefficiencies in RPC node functionality can directly effect validators’ operations.
Economic Considerations: A key consideration for validators as the supply of SOL will stabilize, where the rate of token issuance matches the rate of token removal, resulting in a stable and predictable inflation rate.
Case Studies of Historical Outages/Challenges
On September 14, 2021, the launch of a decentralized social networking protocol on the Raydium platform triggered an influx of transactions, many automated through scripts by users, leading to a "memory overflow" issue. This caused a validator node to crash, which, in turn, led to the network being unable to produce blocks. The disruption lasted for approximately 17 hours, during which the network was effectively down. Check out via this link, on how Solana tackled the situation
Around January 21, 2022, significant market volatility led to an overwhelming surge of transactions, primarily from arbitrage bots, causing the network to experience high congestion and a downtime of up to 30 hours. Although officially labelled as "Degraded Performance," this event prompted the Solana community to upgrade the Mainnet to version 1.8.14 as part of efforts to enhance network stability and performance.
Close to May 1, 2022, the launch of a new NFT project generated a flood of bot transactions, disrupting consensus among the primary network nodes and resulting in a 7-hour halt in block production.
On February 6, 2024, the BPF (Berkley Packet Filter) loader failed and was down for 4 hours and 46 minutes.
The founders and the core team of Solana have always been proactive whenever the network had faced issues. This show their commitment towards the sustainability and the machine. Validators must always choose diverse clients to reduce inefficiencies and network outages within the Solana ecosystem. The importance of choosing diverse clients can further enhance solving some of the challenges Solana had faced historically. Apart from these, validators must choose best practices as recommended by Solana in their official documentation.
Also do check out this article for tips and tricks that validators follow!
Exploration of Fee Economics and Spam Reduction
In any blockchain, transaction fees are imperative to incentivize validators, sustaining network operations, and mitigating the risk of spam and malicious attacks. As we explore the fee model within the Solana ecosystem, we’ll uncover how transaction fees are structured, their impact on network performance, and the innovative strategies employed to reduce spam and ensure a seamless user experience.
Structure and Distribution of Fees
Fee market is important for a blockchain to flourish mainly, for three reasons:
Spam resistance
Validator compensation
Long-term economic stability
Transaction fee on Solana is very small. When a transaction is confirmed as a part of state, the fee is paid to support the economic design of Solana. Solana’s fee system consists of two components:
Base Fee
Priority Fee
Solana burns fixed portion (50%) of each transaction, with rest sent to validators. Solana burns fees to fortify the value of SOL while discouraging malicious validators from censoring transactions.
The base fee is set at 5000 Lamports (0.000005 SOL) per signature (per transaction).
(1 SOL = 10^9 Lamports)
To understand better, it’s like paying a toll for using the network’s resources. Users pay it upfront when initiating a transaction (regardless of the transaction is successfully executed or not). Solana transactions request a specified number of compute units (CUs) upfront. Compute units represent the computational resources to execute the transaction. If the specified number of CU is exceeded during transaction execution, the transaction fails. Think of it as the amount of processing power required to execute the transactions. Since the base fee is fixed, and does not depend on the actual resources used during transaction execution, developers may not prioritize efficiency in their applications.
Transactions also incur a priority fee, where users have the option to pay a priority fee in addition to the base fee to expedite their transactions’ processing. This priority fee increases the likelihood of their transactions being included in the next block. However, it’s important to note that paying a priority fee does not guarantee inclusion, as it’s a non-deterministic process.
Validators collected 50% of the priority fee as a revenue when including transactions in the block, while other 50% is burned, contributing to the long-term economic stability of the network.
The above image illustrates the fee distribution on Solana blockchain. “Vote Fees” in the context refers to the fees validators earn from voting transactions. In Solana, validators must vote on the state of the ledger to confirm transactions, and they earn fees for this necessary service.
Figures above show that voting transactions makeup majority of the total transactions, therefore fees earned from these transactions amount to the same number.
Priority Fee Indeterminism and Multi-Threaded Execution - Priority Fee in Practice
The current scheduler implementation in Solana operates within a multi-threaded execution framework, where transactions are processed simultaneously by multiple execution cores, each operating independently. This approach is designed to enhance transaction throughput and network scalability by distributing transaction processing across multiple threads, allowing for parallel execution of transactions.
However, the decentralized nature of multi-threaded execution also introduces challenges in transaction prioritization and coordination. Unlike traditional single-threaded execution models, where a single thread manages the entire transaction queue and prioritizes transactions based on predetermined criteria, Solana's multi-threaded execution involves multiple threads operating independently, each managing its own queue of transactions.
As a result, there is no centralized coordination between threads regarding transaction prioritization. Transactions within each thread's queue may be prioritized based on factors such as arrival time, priority fees, or computational complexity. However, there is no mechanism for cross-thread communication or coordination to ensure consistent transaction prioritization across all threads.
This lack of coordination can lead to variability or "jitter" in transaction prioritization and execution, where transactions with higher priority fees may not always be included in a given block, despite their intended priority. Since each thread operates autonomously, there is no guarantee that transactions with higher priority fees will be processed more quickly or given precedence over other transactions in the queue.
Furthermore, the decentralized nature of multi-threaded execution means that transactions processed by different threads may not be synchronized in their execution order, leading to potential inconsistencies in transaction processing and block validation. Transactions processed by one thread may be included in a block before transactions processed by another thread, even if the latter has a higher priority fee.
Overall, while multi-threaded execution offers significant advantages in terms of transaction throughput and network scalability, it also introduces challenges in transaction prioritization and coordination. Addressing these challenges will be crucial for ensuring the reliability and predictability of transaction processing on the Solana network, particularly as transaction volumes continue to grow and network demand increases.
Effect of Parallel Execution on the Validator
Parallel execution can have multiple effects on validator incentives by enhancing throughput, scalability and network’s performance. Key points to note:
Increased Transaction Throughput: This increases throughput can lead to higher revenue for validators, as they earn fees for validating and including transactions in blocks.
Improved Network Scalability: The ability to handle a larger number of transactions in parallel attracts more users and developers to the platform, which will impact increased demand for validators’ services.
Optimized Resource Utilization: This can lead to cost savings for validators by minimizing infrastructure costs and maximizing the return on investment in hardware and computational resources.
Incentives for Network Participation: As the network grows and becomes more decentralized, validators may benefit from a more competitive market environment and increased opportunities for revenue generation.
Comparative Analysis
Bitcoin’s fee economics are driven by a competitive auction system where users bid for block space since each block has a finite capacity for transactions. Users attach a fee to incentivize miners to include their transaction in the next block, with those offering higher fees typically being prioritized, especially during periods of network congestion. This results in a fluctuating fee market that responds to demand. Additionally, miners are rewarded with new bitcoins for each block mined, known as block rewards, which halve approximately every four years. The block reward is set to halve from 6.25 BTC to 3.125 BTC per block in 2024. Over time, as these rewards diminish, transaction fees are expected to constitute a larger portion of miner revenue. Fees in the Bitcoin network are based on the transaction size rather than its value, and wallets often provide fee estimators to help users decide how much to pay.
In contrast, Ethereum's fee economics operate on a gas system where each transaction requires gas to process, with the amount of gas needed reflecting the computational effort. Users specify a gas price in gwei per unit of gas, and a gas limit for their transaction. The Ethereum Improvement Proposal 1559 introduced a base fee that is adjusted by the protocol and burned, reducing the overall supply of Ether, along with an optional tip for stakeholders as a priority fee. This base fee helps stabilize the fee market, aiming for a target per-block gas usage. Ethereum's fees can be notably volatile due to the computational complexity of smart contracts and dynamic network activity.
In the cases of Cardano, the fee structure is deterministic and is calculated using a formula (fee = a + b * size) that includes the size of the transaction in bytes and fixed per-transaction cost. The fees are intended to prevent spam without creating fee market like Ethereum’s. Cardano operates on a PoS protocol called Ouroboros, which is designed to be energy-efficient and scalable. The determinism in fee structure means there is predictability factor by users they would know how much they will pay for a transaction without having to outbid others for block space.
When it comes to Avalanche, it has fee structure that aims for predictability and low costs. However it employs a different consensus mechanism called Avalanche consensus. This enables rapid transactions finality and high throughput. Fees on Avalanche are used to prevent spam but also serve as a small source of revenue for validators. The network has a base fee with an additional fee determined by the complexity of the transaction. Unlike Ethereum's gas fees, which can fluctuate widely with network activity, Avalanche's fees are generally stable, and the network is designed to scale without significant increases in transaction costs.
In comparison, Solana's fees are generally lower than Cardano's and Avalanche's due to its greater throughput capabilities and the fact that it processes a larger number of transactions at a lower individual cost. Cardano and Avalanche offer greater predictability in fees, which can be appealing for users who need budget for transaction costs.
Local Fee Markets on Solana
Solana's fee market dynamics are distinguished by its unique approach to managing transaction fees through localized fee markets. Unlike Ethereum, Solana adopts a multi-threaded execution model, allowing transactions to be processed in parallel. These threads operate independently, processing transactions concurrently. However, only when assigned to different threads local to the leader are they arranged by priority fees, with transactions offering higher fees receiving priority.
Recent developments in Solana's fee model include the introduction of priority fees. Transactions on Solana must declare dependencies beforehand, a feature that gave birth to Solana's localized fee markets. Unlike Ethereum, where transaction validation begins before determining state interaction, Solana transactions must indicate the specific state they intend to interact with, including the program, accounts/addresses, and actions involved.
As the above picture depicts, in Ethereum, validators pick transactions from the mempool to include the next block. The ordering of transactions is primarily based on the fees offered by the transactions. with higher fees typically leading to a higher priority for processing.
Whereas on Solana, when validators receive transactions, they distribute across multiple threads. With this approach, it helps in distributing the load evenly across the network and prevents any single thread from becoming a bottleneck.
This proactive state management allows Solana to identify potential hotspots, where sudden surges in activity occur. Each block on Solana accounts for how transactions affect the network's state, ensuring efficient resource allocation. Solana imposes a cap on the total number of compute units (CU) used by any hotspot, limiting it to 25% of the available blockspace, preventing any single application from monopolizing. Hotspots represent specific smart contracts or accounts experiencing high traffic volumes.
This localized approach to fee management ensures that fee spikes are contained within specific areas of activity, mitigating the risk of network-wide congestion and fee escalation. The design of local fee market is great!!
It comes with few issues like:
Uniform Base Fee: As transactions incur base fee regardless of their complexity or resources they consume, which is not idea. It’s better for fees to correlate with the computational units (CU) consumed, which will reflect true cost of blockspace usage.
Absence of a Mempool: Solana lacks a traditional mempool where transactions can queue up, resulting in a situation where paying a higher fee does not necessarily guarantee that a transaction will be included in a block.
Transaction Ordering by Validators: Validators order transactions by fees after allocation to threads, which could lead to higher-fee transactions failing due to the absence of a priority system.
Spamming for MEV: Due to cheap transaction costs, it's feasible to spam the network with duplicate transactions to increase the odds of capturing Maximum Extractable Value (MEV), leading to inefficiencies.
Wasted Compute Power: A significant portion of compute power may be wasted on processing failed transactions, particularly in arbitrage scenarios, where only one transaction succeeds and the rest fail.
MEV on Solana
The concept of Maximum Extractable Value (MEV) has become a focal point in the discourse on blockchain efficiency and validator economics, particularly within the Solana ecosystem. Originating from Ethereum, MEV encompasses the total value that can be extracted from block production beyond the standard block rewards and gas fees, usually through transaction order manipulation, inclusion, or exclusion.
On the Solana blockchain, MEV strategies manifest distinctively compared to Ethereum, owing to its unique architecture and design choices. Strategies such as atomic arbitrage, which exploits price discrepancies across decentralized exchanges, and liquidations, which capitalize on under-collateralized loans, are prevalent.
The above examples is a typical arbitrage situation that arises in DeFi where there is a price discrepancy between the same assets on different exchanges or Automated Market Makers (AMMs).
So, in the above situation, the person has identified an arbitrage opportunity due to a discrepancy in the SOL/USDC exchange rate between two decentralized platforms, Orca and Phoenix. Orca's quotes are outdated and haven't adjusted to the latest market movements, presenting a lower price for SOL compared to the more current and higher price listed on Phoenix. Seizing this chance, the trader uses atomic swaps to execute a risk-free trade, purchasing SOL at Orca's lower rate with USDC and instantaneously selling it at Phoenix's higher rate, thereby locking in a guaranteed profit. The profit in this instance is minor, a mere 0.0001 SOL, equating to roughly $0.002, but it's achieved without the trader having to bear the risk of holding the asset in a volatile market. The only potential loss they face is the transaction fee if the trade fails to process on the blockchain. This transaction, as shown in the image provided, has been completed successfully and reflects the intricate balance and rapid transactions typical in the DeFi ecosystem, where validators play a crucial role by confirming transactions and, in turn, bolster their earnings through collected fees.
Validators play a critical role in these strategies as they are responsible for ordering and processing transactions within blocks. The revenue from MEV could provide additional incentives for validators, enhancing their profitability and potentially leading to more robust network security.
Transaction Inclusion and MEV Searching
In DeFi landscape, the pursuit of maximized earnings through extractable value (MEV) has become a sophisticated and competitive endeavor. The continuous block building and propagation intrinsic to Solana's architecture necessitate that traders, or MEV searchers, maintain an updated view of the network's state to identify and capitalize on profitable trades in near real-time. These traders often run their own Solana nodes, leveraging the most current network state to swiftly detect and execute competitive trades, a strategy that is critical given the non-first-come-first-serve nature of Solana's transaction scheduler.
Solana's Turbine, a transaction propagation mechanism, plays a pivotal role in disseminating state updates. Since state is initially propagated via partial blocks from the leader to a stake-weighted shuffled set of validators, having control over a significant stake, or aligning with a validator that does, provides an upper hand. This is due to the fact that a stake-heavy validator is more likely to receive state updates sooner, allowing for faster trade execution.
The above picture illustrates the path a transaction takes from being created by a searcher, sent to the current leader validator, processed into a block, and then resulting state updates are communicated back to the network and the searcher, closing the loop. The RPC server and Turbine are part of the infrastructure that supports this process by providing data access and efficient block propagation.
Despite the advanced infrastructure, the process of landing a trade on the network remains fraught with challenges and inefficiencies. The crude method of spamming transactions, although simple, leads to network congestion and the proliferation of failed transactions, which is suboptimal for both the network and its participants. Furthermore, this spamming strategy fails to make efficient use of block space or to provide fair compensation to validators for the block space they control.
The introduction of priority fees was intended to mitigate some of these issues by increasing the odds of transaction inclusion. However, the reality is that while priority fees can be beneficial, they do not offer a guarantee for earlier inclusion within a block. This underscores a crucial point: while priority fees may be an effective tool for pricing general blockspace, they are less effective for pricing specific blockspace, which is particularly important for MEV-related transactions.
Let’s talk about Jito —
Jito-Solana offers an innovative solution to this conundrum through its bundle auctions, which resemble Ethereum's bundle auctions. By allowing searchers to send transaction bundles along with bids, Jito bundle auctions facilitate a more efficient MEV extraction process, where competition is based on price rather than speed. This system also reduces spam by ensuring that unsuccessful bundles do not consume precious block space.
Optimistic transactions represent another strategic approach, wherein transactions are sent with the expectation that opportunities will materialize. This on-chain searching logic, exemplified by smart contracts that execute swaps only if profitable, significantly cuts down on unnecessary transactions that otherwise clutter the blockchain.
Despite these advancements, the current MEV landscape on Solana is predominantly dominated by searchers, with validators capturing a smaller portion of the MEV due to the limitations of non-deterministic mechanisms like spam and priority fees. Notably, the native Solana client burns half of the fees, setting a ceiling on the validators' earnings from MEV.
The advent of Jito-Solana has the potential to revolutionize this dynamic. With Jito bundle auctions, validators can capture MEV more effectively by compelling searchers to compete on price. The entire amount of the bundle tips is directed to the validator and their stakeholders, ensuring a fair distribution of the MEV generated.
The overall trends as per the above graph depicts that the tip in SOL appears relatively stable with slight increments over time, the tip in USD demonstrates higher volatility with more pronounced spikes. This could provide key insights like:
The large spike in USD tips without a corresponding increase in SOL tips could imply a significant increase in value of SOL around that time.
The variability in tips is a key observation that could reflect demand for transaction processing, with high tips possible indicating higher demand or competition for validator services.
A very recent example of Solana MEV capture. A trader tries to swap $8.6M worth of SOL for $WIF in a low liquidity environment. The price had jumped from $0.14 to $3.99, where that trader captured this arbitrage using Jito’s block engine, profiting $1.8M and tipping $89k to validators in the process.
What if profits from MEV become too high?
As the system becomes more efficient at capturing MEV, and as validators earn more from MEV, there could be a scenario where the network fees and MEV revenue are high enough that validators could offer negative commission rates to attract more stake. This would mean that they pay stakeholders rather than charging them, essentially sharing some of the MEV profits directly with stakeholders as an incentive.
However, it is also essential to consider the sustainability of such a model. While negative commissions might be attractive in the short term, they must be balanced against the cost of running a validator node and the long-term security and robustness of the network. Validators might only choose to offer negative commissions during times of high MEV earnings, which are not constant due to the volatility in trading activities and cryptocurrency valuations.
Moreover, if MEV becomes too high, it could lead to concerns about the fairness and openness of the network, as it might incentivize certain validators to prioritize their own transactions or those of their partners. This could create centralization pressures, where a few validators with high stakes could dominate the MEV market, potentially leading to a less secure and less decentralized network.
Outlook on MEV
In conclusion, the Solana blockchain presents a complex and evolving environment for MEV extraction, where the interplay between updated network states, transaction propagation mechanisms, and the strategic placement of trades determines the profitability and efficiency of the process.
On Solana, MEV is in its nascent stages. The increasing activity on the network suggests that MEV opportunities will grow, inciting a more competitive extraction environment. Validators on Solana could potentially dominate MEV extraction, paralleling the current situation on Ethereum, where validators capture the majority of MEV. This could have far-reaching consequences for the network's decentralization.
Centralization Risks: A majority of Solana validators currently operate unmodified versions of the Solana client or Jito-Solana, but the potential for validators to extract MEV directly is a looming possibility. Validators, during their leadership slots, could maximize MEV extraction by manipulating transaction ordering. This approach, which diverges from continuous block production, allows them to monopolize MEV opportunities.
The centralization risk stems from the fact that MEV-extracting validators can offer more attractive staking rewards, thereby attracting more stake and consolidating power. This poses a threat to the network's decentralization ethos.
Democratizing MEV: Solana's out-of-protocol blockspace auctions aim to democratize MEV access. By leveling the playing field between sophisticated validators and those using more accessible systems like Jito-Solana, these auctions mitigate some centralization risks. They enable any participant to become a searcher, and any validator to opt into the MEV auction ecosystem.
Colocation and Integration: Latency is a crucial factor for searchers on Solana, influencing their ability to access and exploit state changes rapidly. The trend towards colocation — placing searcher infrastructure in proximity to validators — and the vertical integration of the MEV supply chain are centralizing forces. They benefit entities with the resources to invest in such setups, potentially marginalizing smaller players.
Geographic Decentralization at Risk: The importance of quick state reading not only promotes colocation with high-stake validators but also encourages a geographical concentration of network power. This could be exacerbated if validators choose to co-locate near centralized exchanges, leveraging off-chain price movements to extract additional MEV.
The Impact of Vote Delays: The intentional delay of votes by validators, to strategically support the most profitable forks, introduces the risk of chain reorganizations (reorgs). This tactic, while permissible within consensus rules, can lead to network instability, as observed in Ethereum's challenges with block and attestation delays.
Solana vs. Ethereum: Distinct MEV Landscapes
MEV on Solana is distinct from Ethereum due to several factors:
Continuous Block Production: Solana's model necessitates rapid state reading for seizing MEV opportunities, unlike Ethereum's discrete block intervals.
Optimistic MEV Transactions: Solana's low cost for failed transactions encourages a "spray-and-pray" approach, creating spam but reducing dependence on latency.
Latency Criticality: The high frequency of state updates on Solana elevates the importance of low latency for searchers.
Blockspace Auctions: The continuous block production on Solana complicates the implementation of out-of-protocol blockspace auctions.
Priority Fee Distribution: Unlike Ethereum, where priority fees are fully allocated to validators, Solana burns half, necessitating alternative blockspace markets.
Inflationary Rewards and Economic Sustainability
In addition to transaction fees, Solana employs inflationary rewards as a mechanism to incentivize network participants and ensure long-term economic stability. These rewards, often referred to as inflation commission, serve as a crucial component of the network's economic model and play a vital role in maintaining network security and resilience.
Validators participating in the Solana network consensus mechanism receive block rewards in SOL tokens as a commission on inflation. These rewards are distributed at the end of each Solana epoch and are calculated based on various factors, including the global inflation rate, stake percentage, commission rate, and validator participation.
The global inflation rate is determined by Solana's predetermined formula, which follows a pre-set disinflationary issuance schedule. This rate incentivizes early network participation while ensuring monetary stability and security. Stake percentage, representing the fraction of total SOL staked compared to the circulating supply, directly impacts the potential rewards for validators. Additionally, validator participation, including uptime and successful voting percentage, influences their overall earnings.
Solana's inflation mechanism is designed to reduce over time, transitioning from an initial rate of 7-9% to a long-term rate of 1-2%. This schedule aims to balance early network growth with long-term stability and sustainability.
The current inflation rate of 5.451% is designed to distribute new SOL to validators and stakers as a reward for securing the network. The total SOL staked is significant and the high staking ration can imply as network security posture.
50% of the transaction fees are burned, which serves as a counterbalance to the inflationary pressure from the new issuance of SOL. The burn rate of SOL will become increasingly important as the inflation rate continues to decrease over time.
Only with increased fee volumes, it could offset the decreases in staking rewards due to deflationary period. The above chart can give us a snippet of understanding on validator revenue and estimating staking APY (Annual Percentage Yield). This can helps us understand the trends in profitability of validators on the network.
The above chart shows the rewards earned by validators, which includes both inflationary rewards and transaction fee earnings. Some key takeaways are:
The total staking rewards in SOL have been relatively constant over the time period, with some variability.
The % of total rewards coming from fees spiked dramatically towards the end of the graph, indicating a significant increase in transaction fees as a portion of total rewards during that time.
The % of rewards from issuance has decreased over time, which could indicate a decrease in new SOL being distributed as staking rewards or an increase in other forms of validator revenue that are diluting the % of issuance.
The composition of validator revenue in the Solana network has changed over time, with a notable increase in the portion of revenue coming from transaction fees in the later epochs.
Impact of Fee Economics
Scalability and Throughput: Fee structures directly impact a network's scalability and throughput. Solana, utilizes a hybrid fee model to manage congestion and maintain its high transaction throughput efficiently.
Resource Allocation: By prioritizing transactions based on fee levels, networks ensure that validators are compensated for processing higher-value transactions, thereby optimizing computational resources.
Transaction Costs: The primary impact of fee economics on users is transaction cost. Solana's predictable base fee and optional priority fees balance cost-effectiveness with the option for faster processing, catering to diverse user needs.
Network Accessibility: Exorbitant fees can alienate small-scale users and dApp developers. By maintaining reasonable fee levels, networks like Solana remains accessible to a broader user base, fostering adoption and ecosystem diversity.
Revenue Streams: Validators earn revenue through transaction fees and, in some cases, block rewards. Fees structures with competitive fee models are essential to attract and retain validators, who secure the network.
Sustainability and Participation: The Solana's approach to gradually reducing inflation while relying on transaction fees as a revenue source exemplifies this balance.
Sustainability and Future Outlook
Long-term economic viability of validators
The current fee economics play a central role in incentivizing validators and ensuring the security and efficiency of blockchain networks. Transaction fees serve as a source of revenue for validators, compensating them for their efforts in processing and validating transactions. In addition to transaction fees, validators may also receive block rewards or inflationary rewards, depending on the network's consensus mechanism.
Despite the importance of validators and fee incentives, sustainability challenges remain a concern for blockchain networks. As transaction volumes increase and network complexity grows, validators may face scalability issues and rising operational costs. Moreover, fluctuations in token prices and network demand can impact the profitability of validators, posing risks to their long-term viability. To mitigate these overtime, exploration of new fee models, optimizing network efficiency, and diversifying revenue streams beyond transaction fees should be deployed.
The short-term incentive structure with block rewards, priority fees and MEV commission rates would be viable for validators. Taking long-term into consideration and with token deflationary mechanism, to continuously enhance validators incentives, Solana should look out for innovative fee models that enhance equal opportunity (democratically) by maintaining network security, and scalability.
Explore innovative models for sustainability
As the Solana network evolves, it's crucial to explore mechanisms that not only enhance sustainability but also optimize network efficiency and user experience. One such proposal is the implementation of a consensus-enforced, predictable base fee for state access.
Consensus-Enforced, Predictable Base Fee: A consensus-enforced, predictable base fee for state access, based on historical contention, could improve efficiency and user experience for accessing highly contested state. By increasing the cost of spam, this measure would disincentivize non-essential transactions and encourage users to lock only the minimal amount of state necessary for their operations. While this does not tackle the fundamental origins of spam—stemming from the need for continuous block building and the associated latency and jitter—it represents a strategic approach to mitigate its impact.
Predictability of Costs: Taking findings from a research paper on Developing Cost-Effective Blockchain-Powered Applications, the concept of predicting transactions cost is a important aspect to delve further. Developers on Solana could benefit from understanding the patterns of transaction cost, especially for applications that require high throughput.
Protocol-Level MEV Distribution: Implementing a system where MEV rewards are distributed across all validators, not just the one proposing the block, could reduce the incentive to seek MEV through co-location.
Randomized Validator Assignments: Solana can adopt the concept of sharding, where it could randomize validator assignments as part of its security ands scalability measures. This would involve changes to the protocol to introduce a random assignment mechanism.
EOS - CPU, NET and RAM Resource Model: EOS uses a resource model where users stake EOS tokens to access network resources (CPU, NET) and buy RAM. This model aims to eliminate transaction fees, as users essentially pay through staking rather than per transaction. What if Solana adopts a resource-based model for transaction processing and network usage? This model could bring more stable income stream, reducing direct cost of transactions for users and providing more predictable revenue streams for validators.
This can increase stake on the network, potentially enabling launching attacks to be more expensive due to the increased SOL stake scenario.
Validators could potentially offer additional services related to resource management, like automated resource allocation or optimization services for users.
This could introduce volatility in the earnings, as earnings from staking for resources could be more closely tied to the overall demand for the blockchain’s CU and storge capacities.
Network Outages: Solana developers have rolled out a few changes in their v1.10 update on the Testnet network:
Moving from the current data transfer protocol, UDP (User Datagram Protocol), to QUIC (Quick UDP Internet Connection) which offers asynchronous communication and reduced latency. Click on the link for progress on this.
Integrating stake-weighted transaction processing, which is a rudimentary implementation of QoS (Quality of Service) that would prevent unstaked or staked bots from consuming large amounts of bandwidth.
Integrating fee-based transaction priority, where users can optionally submit transactions with additional fees to put their transaction at the front of the queue.
Evolving roles of fees and incentives
As blockchain networks evolve, fee models are also evolving to address the changing needs and dynamics of the ecosystem. Solana, for example, employs a hybrid fee model that includes both base fees and priority fees, offering users flexibility and choice in transaction processing. Other networks may adopt different fee structures based on their specific requirements and objectives. The key challenge is to strike a balance between affordability for users and sustainability for validators, ensuring that fee models remain economically viable in the long term.
If you have reached till here, Bravo!! Thank you for reading. Your comments/thoughts and feedback is greatly appreciated. If you would like to connect with me to discuss about Solana or the fee market, please reach out on X - @abhijith_psr
References and Further Readings
https://solana.com/solana-whitepaper.pdf
https://www.helius.dev/blog/solana-fees-in-theory-and-practice
https://www.helius.dev/blog/solana-validator-economics-a-primer
https://www.alchemy.com/overviews/solana-rpc
https://www.helius.dev/blog/the-solana-programming-model-an-introduction-to-developing-on-solana#what-are-transactions
https://jito-labs.gitbook.io/mev/searcher-services/mempoolstream
https://www.helius.dev/blog/priority-fees-understanding-solanas-transaction-fee-mechanics
https://www.umbraresearch.xyz/writings/mev-on-solana#value-capture
https://medium.com/solana-labs/tower-bft-solanas-high-performance-implementation-of-pbft-464725911e79
https://docs.solanalabs.com/implemented-proposals/tower-bft
https://en.wikipedia.org/wiki/Network_partition
https://www.businessresearchinsights.com/market-reports/application-specific-integrated-circuit-asic-market-110462#:~:text=APPLICATION
https://solana.com/news/solana-validators-v1-14-upgrade
https://jumpcrypto.com/firedancer/
https://blog.syndica.io/introducing-sig-by-syndica-an-rps-focused-solana-validator-client-written-in-zig/
https://docs.tinydancer.io/
https://stackoverflow.com/questions/72952040/what-is-an-epoch-in-solana
https://solana.com/news/validator-health-report-october-2023
https://docs.solanalabs.com/consensus/leader-rotation
https://status.solana.com/history
https://solana.blog/solana-network-upgrades-quic-stake-weight-qos-fee-markets
https://jumpcrypto.com/writing/firedancer-reliability/
https://zebpay.com/in/blog/what-is-crypto-ddos-attack-and-how-to-prevent-it
https://cointelegraph.com/news/solana-attributes-major-outage-to-denial-of-service-attack-targeting-dex-offering
https://twitter.com/7LayerMagik/status/1615569374647287808
https://www.umbraresearch.xyz/writings/solana-fees-part-1
https://docs.solana.com/cluster/turbine-block-propagation
https://dl.acm.org/doi/10.1145/3431726
https://eos.io/eos-public-blockchain/powerup-model/