-
Notifications
You must be signed in to change notification settings - Fork 2.6k
Conversation
Co-Authored-By: Xiliang Chen <[email protected]>
Co-Authored-By: Xiliang Chen <[email protected]>
…refactor-balances
@shawntabrizi any further comments? |
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.
It all looks good to me, although I wonder if the migration logic is too much for a single block...
How will we test?
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. |
ok - obvious way to test is to dump balances state, spin up a local testnet with it as genesis and then execute with wasm. |
Tested it on a dev chain, and can confirm it works fine in wasm. (Actually it's surprisingly fast migrating ~7k accounts) |
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 |
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 forTransfers
now also locks it forReserve
s as well, but it's questionable whether they should ever really have been separate in the first place. I leftWithdrawReasons
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: