The vulnerability arises from reorgs changing task IDs, which are tied to nonce validation in the assertValidNonce function. When a reorg occurs, generators and validators must recompute nonces with new task IDs, effectively doubling their workload without extra compensation.
If a reorg happens at block n, all generators and validators will have to do work all over again to generate a new nonce
So they do 2x the work, and get paid the same amount(even though difficulty is high)
Looking at the respond function:
assertValidNonce includes the taskId in getting the hash to validate the nonce.
If a reorg happens at block n that contains a tx that requests a new taskId, the taskIds of subsequent requests will change. Hence, the generators and validators will have to refetch a new nonce to get the attached fees.
Depending on the difficulty of the request, this will be very problematic to the generators and validators
A reorg at block n would disrupt the nonce validation process for generators and validators by altering task IDs, which are essential to verifying nonces. This forces them to redo computations with the new task IDs, doubling their work without additional compensation, especially problematic with high-difficulty tasks
Manual Review
don't include taskId in the hash for assertValidNonce
The contest is live. Earn rewards by submitting a finding.
This is your time to appeal against judgements on your submissions.
Appeals are being carefully reviewed by our judges.