invocamanman
commented
10 months ago I implemented this way because:
- The scenario described ( which is a very edge situation) could be solved just if one of the active oracles send again their proposal
- Adding an extra logic just for this edge case will cause less readability of the code, and a more expensive call of all the oracle calls, which i think it's nor worth it to just stop this edge case
- In a usual scenario probably, since the quorum should be less than the total oracles, the finalization of the state will take place when just another oracle submits their proposal.
Since the current system can handle this situation, is a very edge case, and it adds complexity and gas cost to all calls i think that the current implementation is better.
This issue tho, does not block the system in any way, or steal funds, for instance, i would lower it to an informational
Github username: @0xmahdirostami Submission hash (on-chain): 0xa6592499766f7ab911916c2e19b65c141099104b707c98d3820285734b24966e Severity: medium
Description: Description\ In the governance system, there's a way to decrease the quorum using the updateQuorum function. However, this function has a vulnerability. It doesn't check the current state of the VotedReportHash.
Scenario\ Consider the following scenario to understand the issue:
Impact\ I've described one scenario, but there could be more. The impact of this vulnerability is that decreasing the quorum doesn't lead to an update of the state root, even if the current VotedReportHash.votes is higher than the new quorum.
Attachments\ Revised Code File (Optional)
To address this vulnerability, a new variable, let's call it currentReportHash, needs to be introduced. We should also check its vote count in the updateQuorum function. If the new quorum is lower than the current quorum and the vote count is sufficient, then update the state root.
This change ensures that the state gets updated when the current vote count permits it.