Beacon Chain Ice Age

[torfbolt]

Proposal

I would like to propose an ice age function for proof of stake, similar to the difficulty bomb in Ethereum proof of work.

Reasoning

The Ethereum ice age aka difficulty bomb in the current form will not really work after the merge, as PoW difficulty will disappear. But I would argue that the concept itself is one of the most important safeguards to keep the Ethereum protocol layer from becoming stagnant. Some people argue that the ice age was only implemented to facilitate the switch to PoS, and is obsolete after the merge. However, PoS is only one of many important planned changes (e.g. sharding, statelessness, VDFs, ...) to the base layer and I don't see why L1 governance decisions should become easier after the merge.

The ice age is a wonderful tool to enforce active, conscious decisions about protocol changes and improvements. It basically codifies the preference of hardforks over softforks in the Ethereum community, as it removes the possibility of voting no to changes by inactivity or lack of participation.

In this aspect it is comparable to writing down a regular election interval in a country's constitution, to make sure that a conscious election process and the accompanying public discussions actually happen.

If the community consensus is not to change anything substantial within a development period, a hard-fork can of course always consist of just a simple push-back of the ice age. Of course then everyone still needs to upgrade their machines, but a) such a hardfork would be very low in dev effort and risk b) this is good practice to make sure people are familiar with client updates in case we ever need one rolled out quickly c) the ice age activation time can be set to increasingly larger intervals as the base layer becomes more feature-complete and tested d) it can be forked out again completely after the important features on the roadmap have been implemented

Requirements

I would argue that an ice age function should fulfill several requirements:

1. It should have a configurable activation epoch number t_0 that is resettable to higher values.
2. After activation plus some time interval it should make the chain increasingly or totally unusable.
3. It should do so gradually, to allow for some wiggle-room in hard-fork deployments.
4. It should not be circumvent-able by simply changing other parameters like block gas limits.

Implementation

The above requirements could be fulfilled by a function that deactivates certain slots within the epoch, i.e. does not allow block proposals for these slots. Compared to simply increasing slot times this has the advantage of keeping the slot times since genesis predictable, both for the past and future. Another alternative would be decreasing the usable execution chain gas limit, but in case of on-chain voting on the maximum gas limit this might be circumvented.

Since the validator shuffling already guarantees a fair and random slot assignment, the deactivated slot numbers within each epoch can be constant and predetermined, without risk of manipulation or grieving. So an ice age function could just deactivate an increasing amount of slots within each epoch. There are several ways to design this progression:

1. Exponential: similar to the current difficulty bomb, the onset only mildly affects chain throughput, but progresses very harshly. It would deactivate 1, 2, 4, 8, 16 and finally all 32 slots of the epoch, bringing the chain to a complete halt (in contrast to PoW, where the chain can still progress).
2. Linear: constant progression, it would deactivate 1, 2, 3, ..., 32 slots of the epoch.
3. Logistic: slow onset, strong progression, but tailing out. It would deactivate 1, 2, 4, 8, 16, 24, 28, 30, 31, 32 slots of the epoch. Generates pain quicker than linear, but leaves the chain alive longer than exponential.

Questions

• What is the consensus on the need to have this?
• Are there any similar existing proposals that I didn't find?
• Should this be discussed on a different platform, e.g. EIP?
• Are there better ways to implement an ice age in PoS?

[hwwhww]

Hi @torfbolt, At this moment, I'd say you might be able to get more feedback on ethereum-magicians forum.