As Ethereum stakers navigate the landscape of staking rewards, it is crucial to understand Figment’s definition of risk-adjusted rewards and what they mean in real terms. This article is the first of three in a series that will provide an overview of what risk-adjusted rewards are, and highlight their significance in Ethereum staking. More specifically, this article focuses on forking the software involved in running a validator.
What are Risk-Adjusted Rewards?
Risk-adjusted rewards refer to the rewards earned by stakers after taking into account the level of risk and potential consequences involved in achieving said rewards. At Figment, we focus on risk-adjusted rewards rather than rewards in isolation to ensure our customers can optimize their staking rewards while minimizing exposure to potential hazards.
Staking Risks to Consider
Figment navigates various risks to maximize risk-adjusted rewards for Ethereum staking. While some risks such as security and regulatory risks are well-known, others such as engineering risks can be more nuanced.
What is Forking and Why do Some Node Operators do it?
Open-source software like Ethereum clients and MEV-Boost is developed and tested by teams of experts and the larger Ethereum community for a long period before release.
Forking open-source software involves copying the source code from the original project and modifying it. This new project diverges from the original, extends the code independently, and leads to the creation of distinct software variants.
Some node operators fork software to maximize their rewards by introducing advanced logic. MEV-Boost connects validators to various relays that offer bids for block proposals, resembling an auction that allows validators to choose the highest reward without requiring complex changes to the existing Ethereum node setup. However, forking MEV-Boost to modify its logic for higher MEV rewards poses significant risks to the node operator and the network.
Forked Software: Timing Games
Forking MEV-Boost for timing games involves introducing artificial delays in interacting with relays during auctions. These delays offer more time for the validators to pick higher bids produced by builders, which can lead to higher rewards. However, this practice can present an element of risk:
Network integrity: This practice is frowned upon by the Ethereum community as these behaviors potentially increase gas fees for the end-users and can jeopardize block proposals and the inclusion of transactions on chain. Moreover, as shown below, these delays can also cause reorgs in the Ethereum blockchain, hurting the network’s health.
Source: https://hackmd.io/@dataalways/latency-is-money
As shown above, the probability of a forked block leading to reorgs increases as the timing games go beyond 1.2 second in the slot time.
Missed proposals:
Excessive timing games can cause validators to miss their opportunities to propose blocks. While block proposals are rare events, they contribute significantly to the total validators’ rewards. Excessive timing games increase the likelihood of missed proposals, negatively impacting individual validators. Node operators that implement forked software to introduce excessive timing games may result in higher-than-average rewards for certain validators, artificially boosting the average rewards rate, to the detriment of other validators of the same node operator.
Forked Software: Ethereum Client
Forking open-source Ethereum clients e.g. Lighthouse or GETH introduces several risks including the creation of a single point of failure:
Single Point of Failure: Thinly tested versions of the open-source software can introduce a single point of failure, reducing the resilience needed for risk mitigation and disaster recovery. For instance, after the Dencun upgrade, an incompatibility between one consensus client and relay led to a peak of 13% missed blocks. Node operators using the forked version of the consensus client couldn’t upgrade to the bug-free version and continued to miss proposals. This lack of resilience directly resulted from forking the client software.
Source: https://beaconcha.in
As shown above, an incompatibility between a relay and a consensus client led to missed proposals. The validators that have forked that consensus client may not have the ability to switch to another open-source client.
Figment’s Risk-Adjusted Rewards Approach
At Figment, we mitigate these risks by using battle-tested open-source software and ensuring redundancy. This strategy boosts our operational security and allows us to switch away from malfunctioning software should that be the right course of action.
Conclusion
Understanding and prioritizing risk-adjusted rewards is essential for Ethereum stakers seeking to optimize their rewards whilst minimizing risk. Figment’s commitment to risk-adjusted rewards through due diligence, robust infrastructure, continuous monitoring, diversification, and regulatory compliance ensures that our customers can achieve rewards without compromising security, safety, or compliance.
Among the various risks in Ethereum staking, forked software risks are significant but yet rarely explored or discussed. Node operators who modify proven open-source software to enhance performance may inadvertently introduce single points of failure and reduce redundancy. Figment’s approach to mitigating these risks is by using unmodified open-source software.
As the Ethereum staking landscape continues to evolve, stakers must remain vigilant and well-informed about the risks. By partnering with a staking provider like Figment, which maximizes risk-adjusted rewards and actively mitigates risks, stakers can confidently navigate this complex landscape and optimize their rewards securely and sustainably.
The information herein is being provided to you for general informational purposes only. It is not intended to be, nor should it be relied upon as, legal, business, tax or investment advice. Figment undertakes no obligation to update the information herein.
SOURCES:
https://gist.github.com/benhenryhunter/7b7d9c9e3218aad52f75e3647b83a6cc
