-
Notifications
You must be signed in to change notification settings - Fork 19
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
Replace Currency->fungible trait migration for time-release pallet #1818
Conversation
⏳ Running benchmarks and calculating weights. DO NOT MERGE! A new commit will be added upon completion... |
✅ Finished running benchmarks. Updated weights have been committed to this PR branch in commit e77de65. |
Codecov ReportAttention:
Additional details and impacted files@@ Coverage Diff @@
## main #1818 +/- ##
==========================================
+ Coverage 82.37% 82.70% +0.33%
==========================================
Files 53 54 +1
Lines 4090 4192 +102
==========================================
+ Hits 3369 3467 +98
- Misses 721 725 +4 ☔ View full report in Codecov by Sentry. |
23c3d8c
to
33a70c6
Compare
for time-release pallet Initial code changes Split from PR #1779
fcabe1b
to
e449930
Compare
…capcity-fungible-trait-time-release
… error for Charlie
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.
- Ran the try-runtime and from migration perspective everything looked good to me except total weights. Which based on current calculation if we only use the NORMAL_DISPATCH_RATIO in a block (
375000000000
) we would get 98% full which is a bit close to what I'm comfortable with. One solution might be to combine v2 and v3 migrations on capacity pallet since both of them iterate onStakingAccountLedger
>>> test_release = 4525000000
>>> test_schemas= 25000000000
>>> test_capacity=260375000000
>>> test_capacity_2=78200000000
>>> (test_release+test_schemas+test_capacity+test_capacity_2) / 500000000000 * 100
73.61999999999999
>>> (test_release+test_schemas+test_capacity+test_capacity_2) / 375000000000 * 100
98.16
- Will recommend somebody else with more context about time-release pallet take another look on that part.
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.
Great effort!
Tested:
- General review of the code
- Ran the try-runtime migration against the snapshots of test-net and main-net
Co-authored-by: Robert La Ferla <robert@onemsg.co>
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.
Lots of good work here.
- I reviewed the code for correctness
- I ran two of try-runtime - against mainnet and testnet.
Agree regarding deferring this to another release.
I think we might need to update Currency::transfer?
|
Here we are using the I think using
|
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.
no blockers for me; minor doc comment suggestion
} else { | ||
Self::update_lock(who, locked); | ||
Self::update_freeze(who, frozen)?; |
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.
Not worth the change but good to know that if we set the update_freeze frozen amount to zero it is the same thing as calling thaw. We can simplify this by removing the if statement and keeping update_freeze.
👍 🚀 Amazing work. Thanks for having a really good commit message. I think this is going to be useful for other migrations. 🥇 |
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.
🥇 Awesome!
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.
lgtm!
Goal
The goal of this PR is to replace the
Currency
trait with thefungible
trait in thetime-release
pallet.This work was split from PR #1779.
Closes #942
Closes #1833
Discussion
The following Parity issues/PRs were used as references for changes:
Deprecate Currency - PR 12951 (Explanation of necessary changes.)
FRAME: Move pallets over to use fungible traits (Issue to track Parity's efforts to update their pallets.)
pallet vesting / update to use fungible (Example of some necessary changes.)
Fungibles: migrate Democracy pallet (Example of storage migration for Locks->Freezes.)
Changes
tokens::fungible::
InspectFungible
forbalance()
andreducible_balance()
InspectFreeze
forbalance_frozen()
Mutate
forset_balance()
,mint_into()
MutateFreeze
forset_freeze()
, andthaw()
pub enum FreezeReason
to supportfreezes
set_freeze()
andthaw()
can fail, so errors needed to be propagated..expect()
whereset_freeze()
orthaw()
can fail.FreezeIdentifier
andRuntimeFreezeReason
configured with defaults.Storage Migrations
The value of
BalancesMaxFreezes
has been updated, which will impact the storage of the Balances pallet by changingT::MaxFreezes
, see the code here: substrate/frame/balances/src/lib.rs:480The previous value of
T::MaxFreezes
was0
so no data could be stored inFreezes
, therefore no storage migration forFreezes
is needed for this change. Even if there was data in storage, it would only need to be migrated ifT::MaxFreezes
is decreased.However, the current chain has data in
Locks
that needs to migrated toFreezes
. Testing has shown that theseLocks
will no longer be accessible once the new traits are in place.The
Balances
pallet is configured to store account data using theSystem
pallet. Therefore, these two pallets must be included when usingtry-runtime
for testing.The migration for
TimeRelease
will access its storage to determine which accounts haveLocks
that need to be translated toFreezes
. Then, the oldCurrency
trait is used to remove theLocks
and the newfungible
trait is used to set theFreeze
.How to Review
set_freeze()
andthaw()
which can now fail and make sure all error states are propagated correctly without possibility forpanic
balance()
is used correctly, or should be changed toreducible_balance()
. The calculations evaluating the Existential Deposit (ED) have been updated and Parity comments indicate thatreducible_balance()
is most likely the value needed.How to Test Runtime Migrations
Install the CLI version of try-runtime, then run try-runtime to test the migration against Frequency Rococo:
cargo build --release --features frequency-rococo-testnet,try-runtime && \ try-runtime --runtime ./target/release/wbuild/frequency-runtime/frequency_runtime.wasm on-runtime-upgrade live --uri wss://rpc.rococo.frequency.xyz:443 --pallet TimeRelease --pallet Balances --pallet System
Alternatively, you can use the non-release version for faster compiles:
cargo build --features frequency-rococo-testnet,try-runtime && \ try-runtime --runtime ./target/debug/wbuild/frequency-runtime/frequency_runtime.wasm on-runtime-upgrade live --uri wss://rpc.rococo.frequency.xyz:443 --pallet TimeRelease --pallet Balances --pallet System
And for testing on main-net:
cargo build --features frequency,try-runtime && \ try-runtime --runtime ./target/debug/wbuild/frequency-runtime/frequency_runtime.wasm on-runtime-upgrade live --uri wss://1.rpc.frequency.xyz:443 --pallet Balances --pallet System --pallet TimeRelease
Testing with a snapshot:
You should see output like this:
The total weight calculated for the TimeRelease migration on testnet:
The total weight calculated for the TimeRelease migration on mainnet:
Upgrade Notes
scripts/upgrade_accounts.py
should be executed to ensure that all accounts have been upgraded before running the migration. This step may be a no-op, if all accounts have previously been upgraded.Checklist