feat(x/gov): change lazy dynamic deposit computation in favor of endblocker per-tick update #104
Conversation
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
tbruyelle
reviewed
Mar 25, 2025
| lastMinDeposit, lastMinDepositTime := keeper.GetLastMinDeposit(ctx) | ||
| if checkElapsedTime && ctx.BlockTime().Sub(lastMinDepositTime).Nanoseconds() < tick.Nanoseconds() { | ||
| return | ||
| } |
There was a problem hiding this comment.
There is no additional case in the unit tests for this new condition, is it because it is already covered or is it a miss ?
tbruyelle
reviewed
Mar 25, 2025
| lastMinInitialDeposit, lastMinInitialDepositTime := keeper.GetLastMinInitialDeposit(ctx) | ||
| if checkElapsedTime && ctx.BlockTime().Sub(lastMinInitialDepositTime).Nanoseconds() < tick.Nanoseconds() { | ||
| return | ||
| } |
|
This PR should be closed in favor of #105 because it already changes the lazy computation. |
|
Closing in favor of #105 |
giunatale
added a commit
that referenced
this pull request
May 29, 2025
… and decreases only with time (#105) This PR is based on #104 Based on discussions, this is a revised model for the dynamic deposit that: - only performs deposit increases upon proposal activation (proposal deactivation does not trigger an update of the deposit), and - only perform time-dependent updates to decrease the deposit, and a decrease happens only if active proposals is less than the target, otherwise the time-based update has no effect. Plus, remove the sensitivity to the distance for increases. This PR should be merged only after #104 is (or in its stead). Moreover, if this PR is accepted, the partially overlapping PR #103 can be closed. --- Importantly, this PR does not yet update neither the `x/gov` README.md nor the Dynamic Deposit ADR to reflect these changes, so it needs to be done. --------- Co-authored-by: Thomas Bruyelle <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 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.
As per the title.
It seems unnecessarily complex in hindsight to lazily compute the dynamic deposit.
If we assume per-tick updates aren't too frequent, it's better to do this then only once and limit to reading a single value for queries.
Moreover, since store updates just overwrite an existing value, even a per-block update should not be too expensive in practice.