Placing this here from R&D Discord, for further discussion.
- General pros and cons of an ice age in PoS
- Technical implementation of same
Proposition: Implement an ice-age mechanism in PoS.
“If one desires no-change, then a default of no-change is a good idea.
If one desires change, then a default of change is a good idea.”
"The main things that I think people really want post-PoS are:
- Data sharding
- Statelessness + state expiry
- ZK-SNARKing the EVM and other state transitions
- Miscellaneous security upgrades like VDF oracle, proof of custody, etc
Account abstraction (can be done mostly-off-chain with flashbots-like techniques, so it doesn’t strictly require consensus changes (!!). And the cost of those changes above being delayed is definitely significantly lower than the cost of the merge being delayed."
Technical implementation ideas:
- IA kicking in could decrease the gas limit, so that throughput decreases and the chain becomes more and more expensive to use
- IA kicking in could probabilistically invalidate more and more block proposal slots, similar results as above
- IA kicking in could increase slot times. Simple as a concept, but probably hairy in the details due to the implicit assumption of currently perfectly regular 12s slots.
Delaying slots looks easy at first sight, but I’m not sure about what stuff implicitly depends on regular slots. And the regular slots are a bit too beautiful to touch them tbh
Invalidating slots might work, but I’m not sure if there is non-gameable randomness around to do so, so that it isn’t gameable by the other validators / block proposers.
But then it doesn’t even have to be random. Something like “slot x mod n is invalid”, where n is very large initially and then slowly decreasing could work."