Storage rent thoughts about specs HOT 1 OPEN

Anyone may unfreeze this actor by including all the state referenced by the frozen storage hash in a message and submitting enough funds to get it going again (possible minimum duration?).

Ideally, it would be possible to partially unfreeze an actor by only restoring part of the tree. However, we could do that by allowing actor "trees" (like process trees) where one could restore the root actor and some set of sub actors.

This approach still has the issue that storage required for tracking dead actor storage hashes will take up a growing amount of space on-chain. This could be remedied by freezing actors before their funds run out entirely, using the remaining funds to pay for just the actor and its storage root hash for a long period of time until it is finally fully dies.

We can compress by batching. Assuming actors can be frozen once a day, this'll be at most a gigabyte (very conservatively, possibly less than 100MiB) after 1000 years.

Once per eviction period, we'd take all the actors to freeze and put their hashes into a merkle tree (or some datastructure). We'd then append the root of this "freeze set" to a list of frozen actors.

To restore an actor, a client would have to submit a contract containing:

1. The index in the freeze set where the frozen actor's state is.
2. The merklepath from the root fo the freeze set to the actor's state.
3. The actor's state.

The miner would then:

1. Restore the state.
2. Remove the state from the freeze set.
3. Recompute the freeze set's root and replace the one in the state tree.

Updating the freeze set is essential. Otherwise, one could restore an actor, freeze the actor, and then restore it again from the first freeze state (rolling back time).

from specs.