revive: Include immutable storage deposit into the contracts storage_base_deposit#7230
Merged
revive: Include immutable storage deposit into the contracts storage_base_deposit#7230
storage_base_deposit#7230Conversation
athei
commented
Jan 18, 2025
…tend --pallet pallet_migrations --fail-fast --clean'
…evive --fail-fast --clean'
xermicus
approved these changes
Jan 24, 2025
pgherveou
reviewed
Jan 24, 2025
Contributor
pgherveou
left a comment
pgherveou
left a comment
There was a problem hiding this comment.
Looks good, apart from the migration that probably need proper weight instead of just using RuntimeDbWeight
pgherveou
approved these changes
Jan 24, 2025
Co-authored-by: PG Herveou <pgherveou@gmail.com>
ggwpez
approved these changes
Feb 4, 2025
Member
Author
|
/cmd bench --runtime dev --pallet pallet_revive --clean |
Contributor
|
Command "bench --runtime dev --pallet pallet_revive --clean" has started 🚀 See logs here |
…t_revive --clean'
Contributor
|
Command "bench --runtime dev --pallet pallet_revive --clean" has finished ✅ See logs here DetailsSubweight results:
Command output:✅ Successful benchmarks of runtimes/pallets: |
alexanderregnier
approved these changes
Feb 10, 2025
This was referenced Apr 22, 2025
7 tasks
This was referenced Jul 16, 2025
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
7 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This PR is centered around a main fix regarding the base deposit and a bunch of drive by or related fixtures that make sense to resolve in one go. It could be broken down more but I am constantly rebasing this PR and would appreciate getting those fixes in as-one.
This adds a multi block migration to Westend AssetHub that wipes the pallet state clean. This is necessary because of the changes to the
ContractInfostorage item. It will not delete the child storage though. This will leave a tiny bit of garbage behind but won't cause any problems. They will just be orphaned.Record the deposit for immutable data into the
storage_base_depositThe
storage_base_depositare all the deposit a contract has to pay for existing. It included the deposit for its own metadata and a deposit proportional (< 1.0x) to the size of its code. However, the immutable code size was not recorded there. This would lead to the situation where on terminate this portion wouldn't be refunded staying locked into the contract. It would also make the calculation of the deposit changes onset_code_hashmore complicated when it updates the immutable data (to be done in #6985). Reason is because it didn't know how much was payed before since the storage prices could have changed in the mean time.In order for this solution to work I needed to delay the deposit calculation for a new contract for after the contract is done executing is constructor as only then we know the immutable data size. Before, we just charged this eagerly in
charge_instantiatebefore we execute the constructor. Now, we merely send the ED as free balance before the constructor in order to create the account. After the constructor is done we calculate the contract base deposit and charge it. This will makeset_code_hashmuch easier to implement.As a side effect it is now legal to call
set_immutable_datamultiple times per constructor (even though I see no reason to do so). It simply overrides the immutable data with the new value. The deposit accounting will be done after the constructor returns (as mentioned above) instead of when setting the immutable data.Don't pre-charge for reading immutable data
I noticed that we were pre-charging weight for the max allowable immutable data when reading those values and then refunding after read. This is not necessary as we know its length without reading the storage as we store it out of band in contract metadata. This makes reading it free. Less pre-charging less problems.
Remove delegate locking
Fixes #7092
This is also in the spirit of making #6985 easier to implement. The locking complicates
set_code_hashas we might need to block settings the code hash when locks exist. Check #7092 for further rationale.Enforce "no terminate in constructor" eagerly
We used to enforce this rule after the contract execution returned. Now we error out early in the host call. This makes it easier to be sure to argue that a contract info still exists (wasn't terminated) when a constructor successfully returns. All around this his just much simpler than dealing this check.
Moved refcount functions to
CodeInfoThey never really made sense to exist on
Stack. But now with the locking gone this makes even less sense. The refcount is stored insideCodeInfoto lets just move them there.Set
CodeHashLockupDepositPercentfor test runtimeThe test runtime was setting
CodeHashLockupDepositPercentto zero. This was trivializing many code paths and excluded them from testing. I set it to30%which is our default value and fixed up all the tests that broke. This should give us confidence that the lockup doeposit collections properly works.Reworked the
MockExecutableto have both adeployand acallentry pointThis type used for testing could only have either entry points but not both. In order to fix the
immutable_data_set_overridesI needed to a new functionadd_bothtoMockExecutablethat allows to have both entry points. Make sure to make use of it in the future :)