You can read about the rewards v5 specification here -
And the actual specification here -
The key performance hangup is that for smoothing pool rewards, the tree generation process has to figure up the attestation performance for every minipool particpating. That means looking at all 7500+ attestations, for every epoch, over the 6300 epochs in a 28 day period. As the number of minipools participating in the smoothing pool increase (which we all hope will happen), the processing time to determine that attestation performance will increase at a linear rate at best. Right now, unless you put the whole beacon chain into ram the way the lighthouse folks do it, this is a 2+ hour process. With double the minipools, this timeframe also roughly doubles. Given community angst around how long this takes now under the best circumstatnces, it might be worth looking at managing the processing time by chopping the time interval up. If folks are comfortable and expectations are well managed about this taking longer and longer as we grow, then this proposal really isn’t needed.
The only other obvious optimisation would require statefully caching the minipool attestation performance over the whole period. This works to great effect (I beleive Rocketscan does this for its’ rewards previews), but can add some trust assumptions that the data hasn’t been tampered with after it’s been logged.