Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

getGasPriceMinimum reverts when there is no rate #10932

Closed
wants to merge 4 commits into from

Conversation

pahor167
Copy link
Contributor

@pahor167 pahor167 commented Feb 9, 2024

Description

Readable error message instead of panic when no medianRate for token exists

Addresses: https://github.com/celo-org/audit-a-findings/issues/8

@pahor167 pahor167 requested a review from a team as a code owner February 9, 2024 10:26
@@ -175,7 +176,7 @@ contract GasPriceMinimum is
* For other addresses it returns gasPriceMinimum() mutiplied by
* the SortedOracles median of the token. It does not check tokenAddress is a valid fee currency.
* this function will never returns values less than ABSOLUTE_MINIMAL_GAS_PRICE.
* If Oracle rate doesn't exist, it returns ABSOLUTE_MINIMAL_GAS_PRICE.
* If Oracle rate doesn't exist, it reverts.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There's a question of what's the desired behavior. Sounds like in the past we intended to return ABSOLUTE_MINIMAL_GAS_PRICE (defined to be 1 wei).

  1. If that is the desired behavior, the fix should be instead to return 0 from the function above, instead of reverting.
  2. But likely it's a good idea to not return such a tiny gas price, in which case sounds like we're good to remove any references to ABSOLUTE_GAS_PRICE_MINIMUM, including the max calculation below.

I guess the one thing to check is how would the celo-blockchain client react to a revert here?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think reverting is ok.

But sure, need to check what happens on the client

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The problem is that it can technically be 0 even for whitelisted tokens that do not use adapter. This is not yet supported by client but in long run it should be. Then it is up to user whether they will choose to pay with this token even though it is more expensive.

Personally I would keep the revert.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree we should revert (like we've been doing, now it'd be more explicit).
@marekolszewski The comment it's a typo, should have been how Pavel left it now.

Copy link
Contributor

@mcortesi mcortesi left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

need to check what happens on client

@@ -165,6 +165,7 @@ contract GasPriceMinimum is
uint256 rateNumerator;
uint256 rateDenominator;
(rateNumerator, rateDenominator) = sortedOracles.medianRate(tokenAddress);
require(rateDenominator > 0, "Token has no rate");
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

wouldn't it be cleaner for medianRate to do this require? If not we make every caller need to make this check

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

actually... checking sorted oracles. var names looks odd

it should be:

rate, numOfRates = 

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I moved it to medianRate and also renamed variable to medianRate and denominator

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

wouldn't it be cleaner for medianRate to do this require?

I think it makes sense for the oracle to have a non-reverting version of this function so consumers can decide what to do in the case of a missing rate.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

After checking blockchain client code:

Our options are:

  • Revert when no medianRate exists - problem is that exchange rate of fee currency is consider 1:1 to CELO which will cause user to pay less/more than what they agreed to
  • Keep it as it is (== returning 0) - problem is that if we whitelist new fee currency, but forget to add oracle feed, then we will panic the client since we are dividing by 0 and it has potential to shutdown whole Celo network
  • Return uint256.max - which would make paying by this feeCurrency extremely expensive - we need to check whether there are no potential overflows

We agreed with @karlb to go with 3. for now

@@ -175,7 +176,7 @@ contract GasPriceMinimum is
* For other addresses it returns gasPriceMinimum() mutiplied by
* the SortedOracles median of the token. It does not check tokenAddress is a valid fee currency.
* this function will never returns values less than ABSOLUTE_MINIMAL_GAS_PRICE.
* If Oracle rate doesn't exist, it returns ABSOLUTE_MINIMAL_GAS_PRICE.
* If Oracle rate doesn't exist, it reverts.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think reverting is ok.

But sure, need to check what happens on the client

(rateNumerator, rateDenominator) = sortedOracles.medianRate(tokenAddress);
return ((gasPriceMinimum() * rateNumerator) / rateDenominator);
(uint256 medianRate, uint256 denominator) = sortedOracles.medianRate(tokenAddress);
return ((gasPriceMinimum() * medianRate) / denominator);
Copy link
Contributor

@martinvol martinvol Feb 19, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@pahor167 pahor167 closed this Feb 20, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants