Replace Currency->fungible trait migration for time-release pallet#1818
Replace Currency->fungible trait migration for time-release pallet#1818mattheworris merged 14 commits intomainfrom
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
aramikm
left a comment
There was a problem hiding this comment.
- 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.
Co-authored-by: Robert La Ferla <robert@onemsg.co>
shannonwells
left a comment
There was a problem hiding this comment.
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
|
JoeCap08055
left a comment
There was a problem hiding this comment.
no blockers for me; minor doc comment suggestion
| Self::delete_freeze(who)?; | ||
| } else { | ||
| Self::update_lock(who, locked); | ||
| Self::update_freeze(who, frozen)?; |
There was a problem hiding this comment.
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. 🥇 |
Goal
The goal of this PR is to replace the
Currencytrait with thefungibletrait in thetime-releasepallet.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::InspectFungibleforbalance()andreducible_balance()InspectFreezeforbalance_frozen()Mutateforset_balance(),mint_into()MutateFreezeforset_freeze(), andthaw()pub enum FreezeReasonto supportfreezesset_freeze()andthaw()can fail, so errors needed to be propagated..expect()whereset_freeze()orthaw()can fail.FreezeIdentifierandRuntimeFreezeReasonconfigured with defaults.Storage Migrations
The value of
BalancesMaxFreezeshas 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::MaxFreezeswas0so no data could be stored inFreezes, therefore no storage migration forFreezesis needed for this change. Even if there was data in storage, it would only need to be migrated ifT::MaxFreezesis decreased.However, the current chain has data in
Locksthat needs to migrated toFreezes. Testing has shown that theseLockswill no longer be accessible once the new traits are in place.The
Balancespallet is configured to store account data using theSystempallet. Therefore, these two pallets must be included when usingtry-runtimefor testing.The migration for
TimeReleasewill access its storage to determine which accounts haveLocksthat need to be translated toFreezes. Then, the oldCurrencytrait is used to remove theLocksand the newfungibletrait 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 forpanicbalance()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 SystemAlternatively, 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 SystemAnd 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 TimeReleaseTesting with a snapshot:
You should see output like this:
The total weight calculated for the TimeRelease migration on testnet:
[2023-12-18T14:50:36Z INFO runtime::time-release] total accounts migrated from locks to frozen 6 [2023-12-18T14:50:36Z INFO runtime::time-release] 🔄 Time Release migration finished [2023-12-18T14:50:36Z INFO runtime::time-release] Time Release Migration calculated weight = Weight { ref_time: 4525000000, proof_size: 0 } [2023-12-18T14:50:36Z INFO runtime::time-release] ✅ migration post_upgrade checks passedThe total weight calculated for the TimeRelease migration on mainnet:
[2023-12-18T14:57:04Z INFO runtime::time-release] 🔄 Time Release migration finished [2023-12-18T14:57:04Z INFO runtime::time-release] Time Release Migration calculated weight = Weight { ref_time: 16525000000, proof_size: 0 } [2023-12-18T14:57:04Z INFO runtime::time-release] ✅ migration post_upgrade checks passedUpgrade Notes
scripts/upgrade_accounts.pyshould 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