feat: pallet asset-rate

[wischli]

• Addresses [Multi-Asset Treasury] Exchange Oracle Pallet polkadot-sdk#202
• Required for [Multi-Asset Treasury] Implement treasury pallet to be more generic polkadot-sdk#201 & wip: multiasset treasury pallet #13571

Description

Adds a simple oracle asset-rate pallet which provides means of setting conversion rates for assets to native. These conversion rates are planned to be used to Treasury. Please note that these conversion rates should not be used for the actual payment but just to determine the {Small, Medium, Big} Spender status/track for users which desire to be paid in anything but the native currency. Moreover, it could also be used to softly assert a SpendingPeriods budget has not been exceeded, if that will eventually be necessary for a Multi Asset Treasury.

CUD is enabled via three (potentially) separate origins. The UpdateOrigin could be a DEX which sends an update every N blocks. It was discussed whether {Create, Remove}Origins could be merged. However, I believe we should provide the most flexible granularity and keep all three origins. Consider separate Gov2 track thresholds for adding and removing an asset rate as one argument. In the end, even if CreateOrigin and RemoveOrigin are exactly the same, it's one more line of configuration in the particular runtime.

How is this pallet supposed to be used?

This pallet provides an implementation of ConversionFromAssetBalance which can be plugged into the more generic treasury pallet as an associated type. This enables mapping X amount of balance for an asset to Y amount of native balance. The creation of treasury proposals in Gov2 will always happen on the governance chain (e.g. relay for now, common good in the future). Since such chain does not need to understand multi assets, there needs to be a mechanism to map such balances to the native balance.

TODO

• Add unit tests
• Add benchmarks
• Add pallet docs
• Open separate PR (refactor: inconsistent BalanceConversion fn #13610) to address inconsistent function definition of BalanceConversion, e.g.

- /// Converts a balance value into an asset balance.
+ /// Provides conversion between two balances.
pub trait BalanceConversion<InBalance, AssetId, OutBalance> {
	type Error;
-	fn to_asset_balance(balance: InBalance, asset_id: AssetId) -> Result<OutBalance, Self::Error>;
+	fn to_balance(balance: InBalance, asset_id: AssetId) -> Result<OutBalance, Self::Error>;
}

[cla-bot-2021]

User @wischli, please sign the CLA here.

[xlc]

Do we really need create/upgrade/remove? wouldn't an update with Optional param be enough?

[wischli]

Do we really need create/upgrade/remove? wouldn't an update with Optional param be enough?

That could suffice. IMO though, it should be preferred to have better granularity, especially since adding an asset to this pallet's storage can be considered whitelisting them as payout currencies.

Assume the UpdateOrigin will be a DEX in the future, e.g. on Statemin{e,t}. Should this DEX really have the power to add and remove assets which can be requested as payout on a Government chain? IMO it should not, especially when you consider that parachains probably want to have Multi Asset Treasuries as well without necessarily having an independent chain dictate supported spend assets.

Moreover, in the current design the UpdateOrigin does not essantially have to check which assets it actually can update, e.g. the filtering happens in the TreasuryOracle pallet.

[xlc]

especially since adding an asset to this pallet's storage can be considered whitelisting them as payout currencies.

Why the treasury should rely on the oracle pallet to determine an asset is supported? If treasury wants a whitelist, it should implement a whitelist in the treasury. The oracle pallet could be for example used for fee payment, ED amount calculation etc. But if this is the design that this pallet will tightly coupled with treasury, that maybe fine. Is there a design of how all the pallets interact with each other?

Another thing is, any reason why this needs to be treasury-oracle pallet instead of just a generic oracle pallet?

One thing I don't like on how those issues are approached is that I don't see a high level design. I don't see a detailed spec. There is no way for me (and the community) to review them and provide feedbacks. This is Substrate that the pallets are supposed to be generalized and reusable. Currently I need to read the code to guess what you are trying to achieve and as a result I have a lot of questions. Presumably there are a lot of internal discussion and docs but I don't see them so they don't exist for me.

@joepetrowski @bkchr can we improve the process here by requiring someone to write some tech spec of all the new pallets before start coding them?

[joepetrowski]

especially since adding an asset to this pallet's storage can be considered whitelisting them as payout currencies.

Why the treasury should rely on the oracle pallet to determine an asset is supported? If treasury wants a whitelist, it should implement a whitelist in the treasury. The oracle pallet could be for example used for fee payment, ED amount calculation etc. But if this is the design that this pallet will tightly coupled with treasury, that maybe fine. Is there a design of how all the pallets interact with each other?

Another thing is, any reason why this needs to be treasury-oracle pallet instead of just a generic oracle pallet?

@tonyalaribe is writing up a design of how these work together. But the main reason that this is a Treasury-Oracle is that it's really limited to some specific information related to Treasury logic. I would not be opposed to putting this directly in Treasury, in the context that the Treasury logic exists in one place but its assets exist in many. However for a single-asset, single-location Treasury, this would be pointless, so it also makes sense as an extension.

[tonyalaribe]

especially since adding an asset to this pallet's storage can be considered whitelisting them as payout currencies.

Why the treasury should rely on the oracle pallet to determine an asset is supported? If treasury wants a whitelist, it should implement a whitelist in the treasury. The oracle pallet could be for example used for fee payment, ED amount calculation etc. But if this is the design that this pallet will tightly coupled with treasury, that maybe fine. Is there a design of how all the pallets interact with each other?
Another thing is, any reason why this needs to be treasury-oracle pallet instead of just a generic oracle pallet?

@tonyalaribe is writing up a design of how these work together. But the main reason that this is a Treasury-Oracle is that it's really limited to some specific information related to Treasury logic. I would not be opposed to putting this directly in Treasury, in the context that the Treasury logic exists in one place but its assets exist in many. However for a single-asset, single-location Treasury, this would be pointless, so it also makes sense as an extension.

I shared a potential plan here: paritytech/polkadot-sdk#98

[wischli]

@tonyalaribe Please review, thank you!

[wischli]

I renamed the pallet from treasury-oracle to asset-rate as a result of the most recent renaming of pallet-asset-conversion(#12984) as well as @muharem's and @xlc's comments.

An open discussion point is the potential splitting of whitelisting an asset to a separate pallet such that this pallet truly just serves as a convertor without whitelisting implications.

IMO such splitting would be unnecessary as I think it's feasible to assume giving an asset a conversion to native balance relates to whitelisting is as payout currency. In the end, that logic is dependent on the final design of the Multi-Asset Treasury and out of scope of this PR.

[tonyalaribe]

Thanks for putting this to together @wischli. Other than the updates to documentation and how the pallet is portrayed, everything else looks great to me.

[tonyalaribe]

bot rebase

[paritytech-processbot]

Rebased

[joepetrowski]

bot merge