Submitted by Trust, also found by csanuragjain
HolographOperator.sol#L875
Operators are organized into different pod tiers. Every time a new request arrives, it is scheduled to a random available pod. It is important to note that pods may be empty, in which case the pod array actually has a single zero element to help with all sorts of bugs. When a pod of a non existing tier is created, any intermediate tiers between the current highest tier to the new tier are filled with zero elements. This happens at bondUtilityToken():
The issue is that any user can spam the contract with a large amount of empty operator pods. The attack would look like this:
The above could be wrapped in a flashloan to get virtually any pod tier filled.
The consequence is that when the scheduler chooses pods uniformally, they will very likely choose an empty pod, with the zero address. Therefore, the chosen operator will be 0, which is referred to in the code as open season. In this occurrance, any operator can perform the executeJob() call. This is of course really bad, because all but one operator continually waste gas for executions that will be reverted after the lucky first transaction goes through. This would be a practical example of a griefing attack on Holograph.
Any user can force chaotic open season operator behavior
It is important to pay special attention to the scheduling algorithm, to make sure different pods are given execution time according to the desired heuristics.
ACC01ADE (Holograph) confirmed and commented:
