Define a sane "max randomness" lookback limit

[Stebalien]

The builtin actors currently enforce their own limits, but we need to set a global one.

[Stebalien]

Alternatively, we can just charge proportional to the lookback distance.

[Stebalien]

cc @anorth who has thought about this in the past.

[anorth]

I do think there should be a fixed limit, and whatever's required for our current sector onboarding seems like a reasonable guide to start.

[raulk]

Would err on the side of conservativeness, so what @anorth proposed makes sense. We can always expand later, can never constrict.

[Stebalien]

So, the question is: What is required. @ZenGround0 any ideas?

[Stebalien]

I'm punting this to M2.2. We've disabled the related precompile, so this is no longer a critical issue.

[ZenGround0]

One weird but useful benefit to arbitrary or at least longer term lookback is the ability to rerun previous PoReps without trust. There are situations where this might be useful. But If we actually wanted to support this we'd probably want to use an accumulator and have the syscall take a proof. We could do that fairly easily in an upgrade too.

As @anorth says above the easiest safe thing to do is restrict on current PoRep lookback limts.

[Stebalien]

After thinking about this a bit... I think we really can just allow arbitrary lookbacks without too much difficulty, what we need is:

1. A quick lookup table for some subset of epochs before finality. I.e., some way to skip to within N epochs of the target epoch so we only have to walk N epochs.
2. A gas schedule that charges less for "recent" epochs (guaranteed to be cached).

This may also be important with respect to things like time-lock encryption.