Skip to content
This repository was archived by the owner on May 30, 2023. It is now read-only.

Conversation

@Roznovjak
Copy link
Collaborator

No description provided.

@Roznovjak Roznovjak marked this pull request as ready for review April 7, 2022 00:24
@codecov
Copy link

codecov bot commented Apr 7, 2022

Codecov Report

Merging #42 (4455be8) into main (c73846e) will decrease coverage by 0.59%.
The diff coverage is 87.01%.

@@            Coverage Diff             @@
##             main      #42      +/-   ##
==========================================
- Coverage   77.06%   76.46%   -0.60%     
==========================================
  Files          16       16              
  Lines         933      973      +40     
==========================================
+ Hits          719      744      +25     
- Misses        214      229      +15     
Impacted Files Coverage Δ
transaction-multi-payment/src/lib.rs 65.76% <87.01%> (-0.91%) ⬇️

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update c73846e...4455be8. Read the comment docs.

@Roznovjak
Copy link
Collaborator Author

One notable change is that we replaced withdraw and deposit with one transfer. The consequence is that we can't use withdraw_reason, we don't transfer non-native assets with the KeepAlive parameter and we also don't use deposit_into_existing(). It's because existing currency adapters don't allow us to specify all "low level" parameters and use fixed values for some parameters.

@enthusiastmartin
Copy link
Member

enthusiastmartin commented Apr 15, 2022

i would suggest to keep the original implementation where the native is withdrawn and refunds are deposited.

and introduce new one with fees transferred to selected account.

in this way - it will be easily to swap back if needed.

@Roznovjak Roznovjak self-assigned this Apr 25, 2022
@enthusiastmartin
Copy link
Member

@apopiak Could you have a look at this ?

the reason is that it seems that this PR introduces something similar to what you'd need for xcm trader ( see the TransactioPaymentDataProvider).
So perhaps, we can/should consolidate this into one thing.

Also, review of the PR by you would be appreciated too.

@enthusiastmartin enthusiastmartin requested a review from apopiak May 7, 2022 12:38
match paid {
PaymentInfo::Native(paid_fee) => {
let refund_amount = paid_fee.saturating_sub(corrected_fee);
C::transfer(&fee_receiver, who, refund_amount, ExistenceRequirement::KeepAlive)
Copy link
Contributor

Choose a reason for hiding this comment

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

Doing a transfer up above in withdraw and then doing another one here means that the fees could have moved from the fee receiver account in the mean time so you won't be able to refund.
It's probably fine but if that edge case ever happens it'll be one hell of a thing to debug ;-)

Also: you might want to skip the transfer in case refund_amount is zero?

Copy link
Member

Choose a reason for hiding this comment

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

How else would be possible to withdraw fee and avoiding such scenarios? Would reserve some balance instead of transfer work ?

i mean, you'd first reserve and then only transfer the actual fee and unreserve the remaining balance ?

Copy link
Contributor

Choose a reason for hiding this comment

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

The MultiCurrency trait offers withdraw and deposit which could be used together similar to how Substrate's transaction payment is implremented

Copy link
Collaborator 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 Currency and MultiCurrency traits are inconsistent. Currency returns Imbalance type, MultiCurrency returns Balance type, and it's impossible to combine them. We can't create an imbalance from some balance and we also can't get rid of imbalance without calling it's drop implementation. This is the main reason why we are using transfers in our implementation. We can handle each currency type separately and use withdraw methods, but then in case of any error during execution of an extrinsic, tokens are burned instead of deposited because correct_and deposit_fee is not called. And I'm not sure if we want this behavior.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Is skipping the deposit in case refund is zero really needed? Both deposit methods (native and non-native) have a check for zero balance at the beginning.

Copy link
Contributor

Choose a reason for hiding this comment

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

🤷 good point, that's a fair assumption for the most common implementations.

@Roznovjak Roznovjak requested a review from apopiak May 20, 2022 11:29
@Roznovjak Roznovjak requested review from jak-pan and mrq1911 May 25, 2022 12:12

pub struct DepositAll;

impl DepositFee<AccountId, AssetId, Balance> for DepositAll {
Copy link
Member

@mrq1911 mrq1911 May 26, 2022

Choose a reason for hiding this comment

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

@Roznovjak can you please provide this implementation in pallet (or mby even as default), so it doesn't have to be implemented in the runtime?

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Would you like to have it implemented for the unit type () or just to have DepositFee struct publicly available from the pallet?

Copy link
Member

@enthusiastmartin enthusiastmartin left a comment

Choose a reason for hiding this comment

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

Looks good.

we just need to make sure that no tokens are lost ( after the withdraw and deposit_fee).

/// Account to use when pool does not exist.
#[pallet::storage]
#[pallet::getter(fn fallback_account)]
pub type FallbackAccount<T: Config> = StorageValue<_, T::AccountId, OptionQuery>;
Copy link
Member

Choose a reason for hiding this comment

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

No need for migration to delete the storage ? only if upgraded after it is already in use.

@apopiak
Copy link
Contributor

apopiak commented May 27, 2022

you'll also want 1de7570 to allow Basilisk to compile

@apopiak
Copy link
Contributor

apopiak commented May 28, 2022

and to add the feature "use_alloc" ce90275

@apopiak
Copy link
Contributor

apopiak commented May 28, 2022

As you remove the MultiCurrencyAdapter this will need a companion PR for Basilisk, no?

@Roznovjak
Copy link
Collaborator Author

As you remove the MultiCurrencyAdapter this will need a companion PR for Basilisk, no?

Yes. We will also need another PR for hydra-parachain.

@jak-pan
Copy link

jak-pan commented Jun 13, 2022

Is this ready for merge?

@enthusiastmartin
Copy link
Member

Is this ready for merge?

I would like to resolve first this question

It just looks to me bit unnecessary. i would simplify it. Let's wait for Richard to give his opinion.

Other than that - it is ready for merge.

@apopiak
Copy link
Contributor

apopiak commented Jun 13, 2022

He removed the iterator

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

6 participants