-
Notifications
You must be signed in to change notification settings - Fork 305
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
fee: support v0 multi-asset fees (protocol side only)
This commit implements a v0 of multi-asset fees (on the protocol side). Multi-asset fees are important because they allows users who send tokens into Penumbra over IBC to start using the chain immediately. It does this by extending the `GasPrices` struct to include the asset ID of the fee token the prices are for. This allows natural handling of multi-asset fees by just having multiple sets of `GasPrices`. In the past, we've laid the groundwork for this (by allowing other assets in the `Fee` structure, even if it defaults to the staking token) but haven't prioritized it, due to concerns about some of the details of the implementation, particularly: A: How does the chain know that the prices of non-native fee tokens are correct? B: What happens to the non-native fee tokens? C: What are the privacy implications for users paying with non-native fee tokens? This design punts on (A) by only allowing non-native fee tokens with prices explicitly specified using governance. In the future, Penumbra could own DEX as a price oracle, but this would be better to do after it's live and we have real data about it, rather than worrying about edge cases now (e.g., if someone can temporarily manipulate a price for their own trades, that's not a big deal in itself, but hooking it to the fee mechanism used for resource usage could make it one). The approach to (C) is that these explicitly specified prices should be substantially higher (10x) than those of the native token. This means that regardless of price variability, it should remain the case that the native fee token is cheaper, so that the majority of users will use the same fee token and their transactions will not be distinguishable. On the other hand, letting it be _possible_ to use non native fee tokens means that users who send IBC tokens into Penumbra can access the protocol, and even if one of their first acts is to swap some de minimis amount of the native token, they can do that within the system. This implementation currently does not properly handle (B), in that it silently burns all fees, regardless of token. It is not appropriate to burn any tokens other than the native token, whose supply is managed by the chain. Instead, the transaction-level fee check should move into `check_and_execute`, and call a method on the fee component that records the fee amount in the object store. At the end of the block, all non-native fees should be swapped into the native token and then burned. Emitted events should record: - an `EventFee` for each transaction, with the transaction's gas cost, the gas prices used to compute the base fee, the base fee, and the actual fee; - an `EventFeeBurn` at the end of the block, with the total amount of native fees burned as well as, for each alt fee token used to pay fees in that block, how much of the alt token was paid and how much of the native token it was traded for. Client support is still mostly missing, though I have manually tested this on a local devnet, by 1. Creating the devnet 2. Executing a parameter change proposal to set `dexParams.fixedAltGasPrices` to `"[{\"assetId\":{\"altBaseDenom\":\"ugm\"},\"blockSpacePrice\":\"80000\",\"compactBlockSpacePrice\":\"80000\",\"verificationPrice\":\"80000\",\"executionPrice\":\"80000\"}]"` 3. Hardcoding at the top of `TxCmd::exec` a change to the `gas_prices` to add the `gm` asset ID and multiplying all the prices by 10. To properly support clients, we need to - Record the `gas_prices` data for alt fee tokens that is newly included in the `CompactBlock` in the view server's storage (probably in a new `gas_prices` table that maps a fee token asset ID to the latest price); - Use that data to populate the view server's gas prices RPC response (instead of the current `Vec::new` stub that reports any alt fee tokens as non-existing); - Change the `pcli tx` command so that the existing `--fee-tier` and a new `--fee-token` parameters move to `pcli tx`, and apply to all subcommands (i.e., `pcli tx --fee-tier ... --fee-token gm send ...`) so that `TxCmd::exec` can pull the right `GasPrices` out of the RPC response.
- Loading branch information
1 parent
7854a5f
commit a0baeda
Showing
25 changed files
with
346 additions
and
115 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.