Skip to content
This repository has been archived by the owner on Nov 15, 2023. It is now read-only.

Refactor the balances module #4649

Merged
merged 38 commits into from
Feb 1, 2020
Merged

Refactor the balances module #4649

merged 38 commits into from
Feb 1, 2020

Conversation

gavofyork
Copy link
Member

@gavofyork gavofyork commented Jan 16, 2020

Closes #4613

Note that this "cheats" slightly and coalesces WithdrawReasons within balances to just two categories: TransactionPayment (Fees) and everything else (Misc). That allows an aggregate to be stored and avoids lock-list traversals in all balance operations without bloating the account storage item too much. It does mean that locking an account for Transfers now also locks it for Reserves as well, but it's questionable whether they should ever really have been separate in the first place. I left WithdrawReasons as it is since I couldn't see any reason to dumb down the public API just because one implementation happens to implement it in a conservative way.

TODO:

  • Make sure I shouldn't be doing anything special with balances being instanceable.
  • Test migration.

@gavofyork gavofyork added the A3-in_progress Pull request is in progress. No review needed at this stage. label Jan 16, 2020
frame/vesting/src/lib.rs Outdated Show resolved Hide resolved
frame/vesting/src/lib.rs Outdated Show resolved Hide resolved
frame/vesting/src/lib.rs Outdated Show resolved Hide resolved
frame/vesting/src/lib.rs Show resolved Hide resolved
frame/vesting/src/lib.rs Outdated Show resolved Hide resolved
frame/utility/src/lib.rs Outdated Show resolved Hide resolved
frame/vesting/src/lib.rs Show resolved Hide resolved
frame/balances/src/migration.rs Show resolved Hide resolved
@gavofyork gavofyork added the U1-asap No need to stop dead in your tracks, however issue should be addressed as soon as possible. label Jan 29, 2020
@gavofyork
Copy link
Member Author

@shawntabrizi any further comments?

Copy link
Member

@shawntabrizi shawntabrizi left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It all looks good to me, although I wonder if the migration logic is too much for a single block...

How will we test?

@gavofyork
Copy link
Member Author

not sure we really can; re: execution-time it's not a big deal - it'll just be a long block. memory usage should be fine in principle, however if there's some issue with memory leakage (like that you found), then it could be a problem. i'd like to know what's going on with that before upgrading.

@gavofyork
Copy link
Member Author

ok - obvious way to test is to dump balances state, spin up a local testnet with it as genesis and then execute with wasm.

@gavofyork gavofyork merged commit 3c80891 into master Feb 1, 2020
@gavofyork gavofyork deleted the gav-refactor-balances branch February 1, 2020 13:20
@gavofyork
Copy link
Member Author

Tested it on a dev chain, and can confirm it works fine in wasm. (Actually it's surprisingly fast migrating ~7k accounts)

@Polkadot-Forum
Copy link

This pull request has been mentioned on Polkadot Forum. There might be relevant details there:

https://forum.polkadot.network/t/moving-frame-out-of-substrate/907/1

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
A0-please_review Pull request needs code review. U1-asap No need to stop dead in your tracks, however issue should be addressed as soon as possible.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Refactor and optimise balances pallet
6 participants