EIP-7514: Add Max Epoch Churn Limit
Mitigating Risks of Rapid Beacon Chain Growth by Introducing a Max Epoch Churn Limit
The Beacon chain has been widely successful, as it was expected to achieve a 10% or even 30% total ETH stake over a long period. Initially, some doubts came with the implementation, and it had explosive growth that was so fast to comprehend. It came with many uncertainties, which could lead to challenges if left tinkered with. Dapplion and Tim Beiko proposed this proposal to fully understand the risks that come with this growth and find ways to mitigate the risks.
Index
Introduction.
Economic Risks.
EIP-7514
What is churn?
Is this EIP necessary?
Risks of EIP-7514.
Conclusion
Introduction
Considering the rapid growth of the beacon chain, if it becomes too large, numerous challenges may arise, with technical issues being the most prominent. Every research in all directions—disk, CPU, memory, and bandwidth—could grow linearly with validator state size. Consensus clients such as Prism, Lighthouse, Teku, and Genesis have evolved so much, making them able to handle a network of the size today and can do it with ease due to immense directions—discussed by the core engineers to deal with complexities that happen at this validator set.
For instance, the Bigboy team carried out the Parity test in preparation for the Holenski testnet on the beacon chain, and it was able to handle about 1.4 million and crashed entirely at 2 million. This means that clients today are not yet ready to handle such a large network. More so, the type of changes they would have to make to accommodate such fundamental design could take a very long period of years, such as a 1-year timespan, and this is similar to what Geth did to switch to snap sync, and this was a big change that brought increased efficiency. The Geth change took about 2 years before it could be implemented. Other clients like Nethermind are yet to catch up and have been working on it, but it has not yet been released. Also, the growth of the beacon chain has brought about other challenges, such as economic ones, which will be discussed in the next.
Economic Risks
If demand remains very high, the beacon chain could become too successful, potentially leading to its decline. By slowing the rate of growth, the network can create space for developing necessary fixes and improvements. The other set of challenges that have an extremely high risk are the economic risks, and it's the counterpoint of this proposal and why it's controversial, which led to some people being in support of it and some others not.
The beacon chain was designed way back (2018-2019) with a specific framework in mind of how the blockchain world was at that point, and concepts like liquid staking, derivatives, and Maximum Extractable Values (MEV) were not in the minds of researchers or engineers at that point. On the contrary, the landscape point evolved beyond imagination, and the thought of how Ethereum can be secured has changed dramatically. Some concepts have not yet been fully understood to account for cases such as If the chain goes to a 50% ETH stake or even an 80% ETH stake, what happens next? This sparks a curious question in the minds of engineers, researchers, and now researchers and engineers, which makes them slow the growth for now, giving them time to implement more long-term solutions.
EIP-7514: Add Max Epoch Churn Limit
This proposal aims to mitigate the negative externalities of a very high level of total ETH supply staked before a proper solution is implemented. In other words, this proposal accepts the complexities of changing the rewards curve and is meant only to slow down growth. The main goal of EIP-7514 is to limit the growth of the beacon chain. The minimum viable change is to limit the churn by some max.
What is churn?
The Ethereum beacon chain is a dynamic system, which means validators can enter and also exist because of security parameters and defaults. We do not want the validators set to change too quickly, so there are queues that affect the activation and exist.
Churn is defined as the amount of validators that can join per unit of time.
The formula for how churn works is that the number of validators allowed to join per unit time (or epoch) is proportional to the size of the current validator set. This creates an exponential effect: the more validators there are, the more can enter within a given time frame.
This EIP just wraps the function (the one underlined in red) in a max. So if we are above the new parameter—the max churn—then that’s the value that will apply as the constant value of the validator per epoch, which is why we get a linear behavior. This applies to the activation, and the exits are governed by the same function as usual.
This EIP also modifies process_registry_updates to use bounding activation churn limits.
We can limit the growth of the chain by either a lot or very little. The plot below shows the expected growth of the validator set depending on what value is set. This plot is a worst-case scenario of what EIP-7514 is guarding against.
The red line above shows that if we set the MAX_PER_EPOCH_CHURN_LIMIT to 8 (which is what we have in mind), the churn can still grow but at a reduced rate.
Is this EIP necessary?
One of the criticisms of this proposal is if it is necessary, and one of the authors (Dapplion) said, "I would be very happy if that happens to be the case, which means we are not messing with the protocol.”
But this is not the case in reality. The cryptocurrency market is still young, unpredictable, and volatile, and some events, such as the bull market, become the new meta or some unknown catalyst that increases demand again and then brings up the same debate of whether EIP-7514 is necessary and we have only the December window to implement it.
Risks of EIP-7514
The risks around EIP-7514 include the following:
If demand surges, the EIP becomes practically ineffective, as it won't have a significant impact. However, if demand eventually does increase, the EIP provides some assurance that we won't reach critically high levels that could cause concern.
If demand stops, it has no effect and also turns out to be a useless feature.
This EIP buys insurance that the potential mathematical worst case that could happen does not happen.
Decun window for the implementation of this EIP
The diagram below shows the decan window for the implementation of EIP-7514, as it is the best-suited time for this to be implemented before more growth happens in the chain and relying on the next Ethereum upgrade is not that feasible.
The EIP-7514 status is currently in the final status, and it is scheduled for inclusion in Lighthouse and Loadstar after it is tested. To test this EIP-7514, you need to have a very high validator set size or be required to change the parameters to something different to mainnet to trigger the behavior. Test cases for this EIP can be found in the Deneb test suite of the consensus-specs repository.
Conclusion
This EIP was proposed to act as a safeguard to the rapid growth of the beacon chain by adding the maximum epoch churn limit. It was suggested that the many unknowns that come with the growth should be countered and that researchers and engineers in the Ethereum ecosystem should have time to implement a solution against the unknowns. It introduces a cap on the number of validators that can join per unit time (or epoch).
I am grateful that you took the time to read this. I will be back soon with another.