-
Notifications
You must be signed in to change notification settings - Fork 263
Description
Description
HashConsensus.sol supports different report hash variants. Oracle members can submit multiple variants for the same refSlot. All report variants are recorded on-chain in the _reportVariants mapping and every new variant increments _reportVariantsLength. When the report should be finalized, HashConsensus.sol iterates over all of the submitted report variants to determine the one with sufficient support (support >= quorum).
The issue lies in the ability to submit an unlimited number of report variants for the same refSlot. If one or more Oracle members submit a significant number of report variants, _submitReport() and _getConsensusReport functions might revert with Out of Gas errors while iterating over all report variants, effectively blocking report finalization until the next refSlot is reached.
_submitReport():
while (
varIndex < variantsLength &&
_reportVariants[varIndex].hash != report
) {
++varIndex;
}
_getConsensusReport():
for (uint256 i = 0; i < variantsLength; ++i) {
uint256 iSupport = _reportVariants[i].support;
if (iSupport >= quorum) {
variantIndex = int256(i);
report = _reportVariants[i].hash;
support = iSupport;
break;
}
}
While the most obvious scenario for the issue to be exploited is the malicious actions of one of the Oracle members, malfunctioning Oracle software can also result in a significant number of report variants being submitted.
According to the estimations, around 7,000 report variants are required to block report processing with the post-Fusaka TX gas limit of 16.8M. Hence, the issue is unlikely under normal mainnet conditions. Nevertheless, it is worth fixing in one of the upcoming protocol releases.
Proposed fix
To fix the issue, the number of report variants each Oracle member can submit is proposed to be limited. The number of variants submitted by the Oracle member should be reset as soon as the first report for the new refSlot is submitted.