-
Notifications
You must be signed in to change notification settings - Fork 18
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
Provider Boosting implementation #1694
base: main
Are you sure you want to change the base?
Conversation
Codecov ReportAttention: Patch coverage is
|
09ede24
to
164a197
Compare
82610e5
to
ea9ccda
Compare
b80b627
to
977ad65
Compare
977ad65
to
63f6651
Compare
0bf5c06
to
defdb39
Compare
a159bb8
to
aaeec80
Compare
…-rewards-impl # Conflicts: # designdocs/provider_boosting_implementation.md # pallets/capacity/src/lib.rs # pallets/capacity/src/tests/stake_and_deposit_tests.rs # pallets/capacity/src/tests/unstaking_tests.rs # pallets/capacity/src/tests/withdraw_unstaked_tests.rs
} | ||
|
||
#[pallet::hooks] | ||
impl<T: Config> Hooks<BlockNumberFor<T>> for Pallet<T> { | ||
fn on_initialize(current: BlockNumberFor<T>) -> Weight { | ||
Self::start_new_epoch_if_needed(current) | ||
.saturating_add(Self::start_new_reward_era_if_needed(current)) |
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.
Just leaving this as a note: we might want to consider using the new Poll hook instead of on_initialize. Here’s the relevant issue for reference: #2098.
Passkey check only balance not nonce and don't pre-fund it Working consistently
// We have already paid out for the previous era. Put one entry for the previous era as if that is when they staked, | ||
// so they will be credited for current_era. |
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.
Suggestions for better wording, or leave it out entirely?
# Goal The goal of this PR is to address some feedbacks - added feature flags for test only methods - added a constant - small refactor
# Goal Reward eras were 1-indexed but this made things too confusing.
* Use unwrap_or_default for getting a reward pool chunk * warning for inserting a new chunk failure * code golf * linting in e2e * remove unnecessary change in helpers
…ists for a different provider (#2136) ## Summary A user can stake to multiple providers, but the minimum staking amount is enforced only for the first staking action that the user submits. ## Issue details During the staking process, both for the `stake` and `provider_boost` extrinsics, a minimum staking amount should be enforced by the `Runtime::MinimumStakingAmount` parameter. The current implementation of [ensure_can_stake](https://github.com/frequency-chain/frequency/blob/9ef58185f2230aaf92dc166fb8eade56a78e4cf3/pallets/capacity/src/lib.rs#L638) verifies if the amount that the account is staking in total (the current active staking and the new staking amount) is greater than the `MinimumStakingAmount`: ```rust let new_active_staking_amount = staking_details .active .checked_add(&stakable_amount) .ok_or(ArithmeticError::Overflow)?; ensure!( new_active_staking_amount >= T::MinimumStakingAmount::get(), Error::<T>::StakingAmountBelowMinimum ); ``` This implies that the user has to stake the `MinimumStakingAmount` only when they first submit a stake for a provider, all the subsequent staking requests being accepted even with the amount of 1. ## Risk The current implementation does not follow the intended use-case, as described in the design documentation. An attacker could stake the minimum required amount to a provider, and then stake 1 token to each of the other available providers, underpaying for the storage that they use. This can cause a storage bloating, slowing down the network in the long run. ## Mitigation The `ensure_can_stake` function should verify that the `stakable_amount` is greater than `MinimumStakingAmount`, instead of verifying the `new_active_staking_amount`. Closes #2135 # Discussion - `ensure_can_stake` updated to remove the addition of the existing stakes and check `stakable_amount` - `get_stakable_amount_for` updated to use `reducible_balance` as recommended by parity when using the `fungible` trait. `reducible_balance` requires an Existential Deposit, so the unit test values were updated. - `/designdocs/capacity.md` updated to the latest code, and reflects changes in language due to replacing `lock`s with `freeze`s. - CI Checks are not running on this branch, but the unit tests and e2e tests passed in local. # Checklist - [ ] Updated Pallet Readme? - [ ] Updated js/api-augment for Custom RPC OR Runtime API? - [x] Design doc(s) updated? - [ ] Unit Tests added? - [ ] e2e Tests added? - [ ] Benchmarks added? - [x] Spec version incremented? --------- Co-authored-by: Wil Wade <[email protected]> Co-authored-by: Shannon Wells <[email protected]>
Goal
Implement a Provider Boost feature, whereby token holders may support the network and a specific Provider by means of a custom staking model. Token holders lock up a certain amount of token, and receive a return in Frequency token for this support. The token holder chooses a Provider to receive some Capacity, which the Provider may use to pay for chain transactions.
Token holders may still stake for
MaximizedCapacity
and receive no token return. As before, the entire benefit for staking would go to the targeted Provider for this type.Discussion
Support the new staking type, Provider Boost
stake
transaction now specifies the Staking Type ofMaximizedCapacity
which is stored withStakingTargetDetails
.provider_boost
which specifies ProviderBoost staking type.claim_staking_rewards
which mints and transfers all eligible rewards in token to the staker.change_staking_target
which basically swaps your Provider Boost staking target from one Provider to another.StakingType
determines how much Capacity is generated for the targeted provider. ForProviderBoost
type, 50% of the Capacity forMaximizedCapacity
is generated when usingprovider_boost
.StakingType
also determines if there is a periodic return in token to the staker. ForProviderBoost
type, there is a periodic return. ForMaximizedCapacity
type, there isn't.Issue rewards to Provider Boost accounts
RewardEras
that the token holder has staked.RewardEra
is approximately two weeks of blocks.claim_staking_rewards
extrinsic succeeds.Allow a staking 'retarget'
A staker may change some or all of their staked token to target a different provider up to 16 times in a
RewardEra
without penalty. Otherwise, they must wait until the nextRewardEra
.For more details, please see the Capacity Staking Rewards Implementation design doc, which links to the economic model for this feature.
Checklist