-
Notifications
You must be signed in to change notification settings - Fork 104
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
Refactoring XcmExportFeeToSibling and more tests for outbound fee #1109
Conversation
Codecov ReportAttention:
Additional details and impacted files@@ Coverage Diff @@
## main #1109 +/- ##
==========================================
- Coverage 76.36% 76.25% -0.12%
==========================================
Files 56 58 +2
Lines 2344 2400 +56
Branches 72 72
==========================================
+ Hits 1790 1830 +40
- Misses 537 553 +16
Partials 17 17
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good. Added minor comments.
Co-authored-by: Alistair Singh <[email protected]>
Co-authored-by: Alistair Singh <[email protected]>
Co-authored-by: Alistair Singh <[email protected]>
Co-authored-by: Alistair Singh <[email protected]>
… into ron/handle-fee
ensure!( | ||
gas_used_at_most > T::GasMeter::MAXIMUM_BASE_GAS && | ||
gas_used_at_most < T::GasMeter::MAXIMUM_GAS_CAP, | ||
SendError::MessageInvalidGasFees | ||
); | ||
let fee = Self::calculate_fee(gas_used_at_most, T::PricingParameters::get()); | ||
let zero_fee = <Self as SendMessageFeeProvider>::Balance::zero(); | ||
ensure!(fee.local > zero_fee && fee.remote > zero_fee, SendError::MessageInvalidGasFees); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
These checks don't make sense to me. The expectation is that T::GasMeter::maximum_gas_used_at_most
and Self::calculate_fee
always return correct values for any arbitrary Command
.
This behavior is important, as we can't reject commands because for some reason we could not calculate fees. To do otherwise would lead to a loss of user funds.
It seems these checks are acting as unit tests, and so we should convert them to actual unit tests.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This check fee.remote > 0
is for the test case as I mentioned here in #1109 (comment) in which the remote_fee
calculated being zero(though pricing parameters are all non-zero and valid). It will lead to the sovereign account of the sibling chain not being properly refunded in XcmExportFeeToSibling
and finally the agent on the Ethereum side can't be funded.
That's also the reason why I introduced the sanity check of the pricing params, prefer to reject commands because for some reason we could not calculate fees
rather than silently ignoring.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
MAXIMUM_GAS_CAP
added here is a hard limit that applies to all commands. It's mainly for command Upgrade with a sanity initializer_max_gas
. It also applies to the future arbitrary transact for which the gas is dynamic from the input of the end-user.
MAXIMUM_GAS_CAP
should be consistent with the default relayer config otherwise the check in Gateway will always fail and the bridge stuck.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This check fee.remote > 0 is for the test case as I mentioned here in #1109 (comment) in which the remote_fee calculated being zero(though pricing parameters are all non-zero and valid). It will lead to the sovereign account of the sibling chain not being properly refunded in XcmExportFeeToSibling and finally the agent on the Ethereum side can't be funded.
Thanks Ron, that makes sense. But it seems there is a bug in our code if the calculated remote fee ends up being zero. Can you investigate why this happens? We should try and fix it so that we don't need to have these checks.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think we should introduce MAXIMUM_GAS_CAP
, for the same reasons I outlined in #1109 (comment).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
See #1109 (comment). I think its fine if calculated remote fee is zero. It just means the fee is too low to be represented using DOT decimals.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Checks reverted in af15053
if self.exchange_rate < FixedU128::from_rational(1, 10000) || | ||
self.exchange_rate > FixedU128::from_rational(1, 1) | ||
{ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I prefer not to change the validation logic. I also thought about this approach, but ultimately decided it wasn't worth it.
- If the exchange rate does actually mistakenly get set to
1/9999
(slightly less than the limit), then that practically still ends up blocking the bridge anyway. - The upper limit is arbitrary, and if the real-world exchange rate breaches the limit (quite possible), then a runtime upgrade would be required to fix the validation code.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Reverted in f43fce3
My only concern is #1109 (comment) but can be avoided by double check before sending the governance call so should be fine.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
+1
Resolves: SNO-820, SNO-812
This is the sibling PR for #1107 without the change required for the xcm primitives in Snowfork/polkadot-sdk#95.
In this PR we focus on
XcmExportFeeToSibling