A more gas efficient earnings calculation approach

Protocol
4

I believe we use the creationRound instead of currentRound because if the transcoder is no longer active in currentRound the fees can’t be assigned properly due to the feeshare not being initiated on the EarningsPool for that round.

That’s one benefit of using the ticket’s creationRound. The other reason for using the ticket’s creationRound is because fees ideally should go to delegators staked to the orchestrator in the round that a ticket was created since the delegator’s stake helped the orchestrator get selected for work.

While technically a ticket’s creationRound can be at most currentRound - 2, in practice tickets are usually going to be redeemed in the round that they are created so assigning fees to rounds that have already passed may not be that big of a problem.

I feel like we can calculate the fees and rewards for the round up to which the last cumulative values are stored and then loop from that point on.

Yeah that is what I’m thinking - use the old earnings calculation algorithm up to the first round that cumulative values are stored for the orchestrator and then use the new earnings calculation algorithm from then on which doesn’t require any additional looping.