This repository has been archived by the owner on Nov 15, 2023. It is now read-only.
-
Notifications
You must be signed in to change notification settings - Fork 2.6k
contracts: Lazy storage removal #7740
Merged
Merged
Changes from all commits
Commits
Show all changes
19 commits
Select commit
Hold shift + click to select a range
da56e0b
Do not evict a contract from within a call stack
athei 6456a36
Lazily delete storage in on_initialize instead of when removing the c…
athei a702a46
Add missing documentation of new error
athei aa03aa7
Make Module::claim_surcharge public
athei 9eb3a9f
Merge branch 'master' into at-lazy-contract-removal
athei e9be4d6
review: Add final newline
athei d0ccc05
review: Simplify assert statement
athei 765c21a
Merge branch 'master' into at-lazy-contract-removal
athei 76a54f8
Merge branch 'master' into at-lazy-contract-removal
athei efa81bb
Add test that checks that partial remove of a contract works
athei 91850a0
Premote warning to error
athei 91c2d76
Added missing docs for seal_terminate
athei 8f2fc0c
Lazy deletion should only take AVERAGE_ON_INITIALIZE_RATIO of the block
athei 98d3f28
Added informational about the lazy deletion throughput
athei d5a820c
Avoid lazy deletion in case the block is already full
athei 57737ff
Prevent queue decoding in case of an already full block
athei ed4c7e8
Add test that checks that on_initialize honors block limits
athei 736dba6
Merge branch 'master' into at-lazy-contract-removal
athei 5c24ce0
Merge branch 'master' into at-lazy-contract-removal
athei File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains 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
This file contains 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
This file contains 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
This file contains 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
Oops, something went wrong.
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.
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.
I wonder how this can collide with staking implementation of
OffchainSolutionWeightLimit
.Basically staking offchain worker will use the maximum weight available for normal extrinsic. This maximum is computed using
AVERAGE_ON_INITIALIZE_RATIO
. If the on_initialize weight is more thanAVERAGE_ON_INITIALIZE_RATIO
for all the time where offchain worker needs to submit election result. Then a less good on-chain election will happen (I'm not sure how much this should be avoided).So having underestimated
AVERAGE_ON_INITIALIZE_RATIO
under the offchain election is open can be a problem maybe, WDYT @kianenigmaThere 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.
Having multiple
on_initialize
functions that want to take some non-substantial amounts of weight from the block are a problem. They need to be coordinated somehow. Moving the lazy removal fromon_initialize
to some potential on_idle could be a solution.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.
That said, I am open to change those numbers here to whatever works.
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.
I guess one way could be to have
DeletionWeightLimitRatio < AVERAGE_ON_INITIALIZE_RATIO
. so that even if the chain is busy removing lots of tries, election is still fine.But I agree
on_idle
could be helpful, maybe staking could notifyon_idle
that it needs some space somehowThere 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.
But this assumes that this would be the only
on_initialize
in the block which it isn't. TheAVERAGE_ON_INITIALIZE_RATIO
shared between all of them.Don't we already have this problem because of this code already:
substrate/bin/node/runtime/src/lib.rs
Lines 818 to 821 in 0fc8329
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.
I tuned it down to
AVERAGE_ON_INITIALIZE_RATIO
. With that setting we get the following throughput of the lazy removal:In order to increase this throughput in the future we should look into
on_idle
or off chain workers.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.
The current
OffchainSolutionWeightLimit
is a bit tricky because it essential to the system to work properly, yet it is an unsigned transaction, so it is always likely that sum ofon_initialize
causes it to fail, in which case we do the notorious on-chain election. This will be fixed with #7319 which is far from being shipped yet, but almost ready. Once this is merged, we do hope to do most of the solution processing inon_initialize
as well. In which case, the competition becomes fair. Something like staking, because it is critical to the system, would stay inon_initialize
, and this can move to lazy removal.A little brain dump about that: Let's say that a block has 100 weight units. Usually, 10 is consumed in on_initialize, and 40 in extrinsic, leaving 50 unused. Spreading this into the on_idle cases resembleas a thread/process scheduling situation. Two important notes come to mind:
on_idle {}
call? No, the runtime should have trust within it and the on_idle call of a module should simply return the weight that it has consumed, similar toon_initialize
.{0..3}
got to execute their on_idle on this block, on the next block we start from{4..}
.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.
Shouldn't we discuss this in the
on_idle
issue? Or do you think the lazy deletion would essentially break elections and therefore we need to implementon_idle
first?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.
I added the following issue to keep track of this issue: #7817
That said, I will merge in the current form because:
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.
I don't have any objections with merging this as it is. Thanks for making the issue!
About
Yes, it could break it, but I don't think it is a showstopper because afaik there are not mainnets with both pallets. Just once you are setting the value of maximum weight that you can consume for this operation in
node/runtime/src/lib
, for the sake of prosperity, document that fact that the value shoudl be chosen with care and with care.