Balancing Validator Returns and Network Health: The Critical Trade-off in Proof-of-Stake Networks
The Validator's Dilemma
Validators in proof-of-stake networks serve dual roles: they secure the network through consensus participation and earn rewards for their service, while also proposing new blocks and earning block rewards. However, the pursuit of maximum returns can sometimes conflict with network health, creating a classic conflict where short-term profits may undermine long-term ecosystem value. This has become increasingly complex as sophisticated MEV strategies emerge, particularly in high-throughput networks like Solana. Recent events on Solana illustrate why respecting network guidelines isn't just about ethics, it's about long-term sustainability and ecosystem health which Blockdaemon has been the main supporter to xxxxx
Case Study 1: The Timing Games Problem
Timing games represent a subtle but significant threat to network health. In these scenarios, validators delay their participation in consensus to gain informational advantages or manipulate block times to increase transaction throughput. While this might seem like a minor optimization, it can have cascading effects on network performance and user experience.On Solana, timing games manifest in several ways:
Vote Timing Manipulation:
Validators might strategically time their votes to maximize their influence on network decisions or to benefit from information asymmetries. This undermines the randomness and fairness that underpins proof-of-stake security.
The Solana Foundation has responded to these challenges by implementing Timely Vote Credits (TVC) in November 2024, which reward validators for voting quickly and consistently. This mechanism directly addresses timing games by incentivizing prompt participation rather than strategic delays.
Stats on BD TVC vs. competitors
Block Production Delays: Some validators may delay block production to gather more profitable transactions or to better position themselves for MEV opportunities. While this increases MEV rewards, it creates latency issues and can degrade user experience across the network.
More stats and links on current Block Production Delays
Case Study 2: The Sandwich Attack Epidemic
Perhaps no MEV strategy has generated more controversy than sandwich attacks, where validators or searchers place transactions before and after a user's trade to profit from the resulting price movements. On Solana, these attacks have reached unprecedented scale. However, this short-term gain comes at the expense of user experience and network credibility.
Something on Maridane Finance and their dominance in sandwiching
The Network Response: The Solana ecosystem has taken decisive action against excessive sandwich attacks. The Solana Foundation Delegation Program aims to support validators by delegating SOL tokens to them, allowing operation without holding a substantial amount of tokens. Validators are selected based on performance merits, and the foundation has begun removing delegation from validators engaging in harmful MEV practices.
Closing remarks on Sandwhicing
The Long-term Perspective: Blockdaemon’s Approach
Written points for sales:
- In early June, BTCS reported lower rewards compared to competitors, particularly Kiln and Galaxy Digital, prompting a comprehensive analysis of our validator performance.
- Our investigation confirmed that BTCS validators were operating within normal parameters and delivering consistent voting rewards. However, our competitors experienced unusual spikes in fee and MEV rewards during this period.
- Further analysis revealed that certain competitors were implementing timing manipulation strategies that significantly impact network performance and user experience.
- Solana's architecture requires 400ms block times to maintain its high-performance standards and optimal user experience. This timing is critical to Solana's value proposition as a fast, efficient blockchain.
- Some competitors deliberately delay block production to capture additional transactions, with Kiln's blocks frequently exceeding 1000ms—more than double Solana's intended 400ms standard.
- While similar practices occur on Ethereum, the impact is minimal due to Ethereum's 12-second slot structure. However, on Solana's high-frequency network, these delays create substantial performance degradation.
- At BD, we are committed to maintaining a balance between optimizing profits and operating a healthy, fair validator that upholds the integrity of the network.
- The Solana community has responded strongly to these practices, with widespread calls to avoid validators engaging in timing manipulation, particularly targeting Kiln and Galaxy Digital for their network-degrading behavior.
- BD continues investing heavily in infrastructure and hardware optimization to increase rewards without sacrificing network efficiency. For instance, we will be moving to Firedancer client on mainnet very soon, and we’re testing multiple protocols on our testnet.
Source to look at:
For BTCS
Written points:
- The validator is functioning as expected - shown through the vote rewards
- (show comparison to bd val, kiln val, BTCS val)
- The main difference in performance is focused in the MEV and Fee returns
- We are testing Firedancer on mainnet - this could lead to overall higher performance through MEV and Fee production through higher CUs
- We are able to schedule the BTCS whitelabel validator to move to this client before we fully complete testing on mainnet
- Show CU performance from testnet Hosam Abdelaal to get info from Chuck)
- Kiln was an early adopter of Firedancer,
- We wanted to ensure that it would not lower
- We have already alerted and investigating what Kiln has changed in their setup
Additional Questions to answer:
- What is our risk associated with implementing Firedancer on Mainnet?
- How fast can we roll out the upgrade?
- How much missing rewards are we expecting because of the upgrade?
- Can we get a statement from Solana Foundation and/or Community on their views on timing games?
Additional points to only speak to in a call:
- Kiln looks to be delaying block production/signing (“timing games”) to increase their Fees + MEV earnings, which is harmful for the network
- Firedancer 0.6 has timing games in a more chain-safe way potentially that we will be testing (not on your val) - to see if its a more sustainable option for maximizing blockspace
Firedancer v.0.6: Firedancer's block packing engine will ship a few moderately big improvements in the v0.6 release line, one of them is a new "revenue" block packing strategy. Basically, that strategy delays block packing right until the end of the block. Then, it uses massive parallelism (~10-20 bank threads) to execute all transactions and bundles at the last opportunity.
https://github.com/firedancer-io/firedancer/releases/tag/v0.603.20216
Other means to increase PRR : Avoid anything like "stake weight QoS". It drastically reduces the selection of transactions. Keep a close eye on QUIC TPU network metrics. If you have a very high connection count (>40k conn) or connections that frequently fail for reasons other than timeout, you are likely missing out on a lot of transaction volume. (A high conn count is caused by aggressive reconnecting because of clients thinking that the conn broke
Final Response - TO BE SENT Friday 27th June
Hi xx,
Just want to make it clear that the BTCS validator is performing above the network average overall so far in June, and continues to outperform in voting effectiveness as usual.And while MEV and fee earnings have been higher for some competitors recently, they have not been lower for BTCS.
Regarding what we sent on Tuesday, our latest feedback from core developers and engineering teams in the Solana ecosystem confirm that the community views block timing games negatively. Although they see this phenomena growing, and generally are aware of which operators participate in it, they also expect community backlash and anticipate attempts to mitigate these games.
That being said, we will be shortly testing Firedancer on mainnet, its a new solana client that promises better performance and therefore could lead to overall higher rewards through MEV and Fee production and through higher and optimised CUs. We have been testing it on testnet for a while now. We are able to schedule the BTCS whitelabel validator to move to this client before we fully complete testing on mainnet if you would like.
Firedancer's upcoming version includes a new "revenue" block packing strategy. Basically, that strategy delays block packing right until the end of the block. Then, it uses massive parallelism (~10-20 bank threads) to execute all transactions and bundles at the last opportunity. This kind of gets the same results as block timing games without manipulating the network.
Happy to jump on a call to discuss it further or answer any of your questions.
Kiln SOL Outperformance - SENT Tuesday 24th June
We’ve reviewed the BTCS APR and can see that it remains higher than the general SOL network APR of 7.89%. While BTCS’s APR is slightly lower than Kiln’s when it comes to fees and MEV rewards, it continues to outperform in voting rewards.
This difference in MEV and Block Fee is due to a phenomenon known as “timing games,” where validators adjust block timing to maximize rewards pushing block time from ~400mn to ~600ms. Although this practice is more common on Ethereum, it’s generally viewed as not ethical when it comes to network fairness and overall health. Other than block time, we can see all metrics for BTCS as stable and performing as always.
We are committed to maintaining a balance between optimizing profits and operating a healthy, fair validator that upholds the integrity of the network. That being said, we are happy to explore solutions to address this and develop an approach that aligns with both profitability and network sustainability. With your agreement, we can start working on this and provide you with a detailed plan by the end of the week.
