-
Notifications
You must be signed in to change notification settings - Fork 341
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat(streamer): distribute rewards immediately in the current block #1173
Conversation
a335aee
to
a33cab4
Compare
25caeb2
to
a1e983b
Compare
a8717ef
to
a939117
Compare
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.
so, I can see that the logic in both EndBlock
and AfterEpochEnd
roughly has some similarities:
1. GetActiveStreams
2. CalculateRewards
3. SendCoinsFromModuleToModule
4. ik.Distribute
is there a way to somehow extract that logic into a common method?
the main difference I see is that EndBlock
iterates over all epochPointers
while AfterEpochEnd
distributes for the current epochPointer
the is that the implementation is a bit convoluted, it's not trivial to follow the logic, so maybe it would help to centralize those critical pieces of logic
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #1173 +/- ##
==========================================
- Coverage 25.30% 24.95% -0.36%
==========================================
Files 499 513 +14
Lines 98751 102755 +4004
==========================================
+ Hits 24989 25642 +653
- Misses 70523 73786 +3263
- Partials 3239 3327 +88 ☔ View full report in Codecov by Sentry. |
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 will continue the review but it's better I ask questions first, mainly I don't quite understand the intent behind the linked list and its wrapper
https://github.com/dymensionxyz/dymension/pull/1173/files
Somehow I can't see the forest through the trees when it comes to the data structures and it's usage
- please docstring all public methods on InsertionOrdered
- in general better documentation of insertion ordered data structure
- why need key func in insertion ordered?
- no need for insertion ordered upsert multiple and upsert, just have upsert take variadic
- Linked lists are not performant AT ALL afaiu, use a more hardware friendly data structure? does perf matter?
- why linked list? what property there is important?
- Use data structure library instead of implement from scratch? If implement then put in sdk-utils?, (and test with rapid?)
- if it's in common utility it should be common, but data structure seems pretty specialized to use case
Other
- possible to dry out endblock and AfterEpochEnd?
- don't interpolate data into error strings
- golang support iterators natively in 1.23 did you consider?
- general weighted pagination maybe better called weightedPagination or something
- x/streamer/keeper/abci_test.go is huge, would it have been possible to use rapid?
- confusing between weight of gauages and weight of iteration
@danwt thanks for the review! regarding slices/linked lists. my point about re-allocations was that in case of multiple appends the slice can trigger re-allocations (we don't know the number in advance, but it might be 0-100.000 approx), and it might be inefficient at some scale compared to the linked list. in theory it seems reasonable, but in practice apparently it's not :) so i used a slice for this cache after all.
don't think so, they have different semantics though they are very similar. i think i've done the best i could
i got your point, tried to avoid it
yes i did, they seem over-engineering for me
kept just pagination, but added a detailed comment + renames weight to operations
it's possible, but i'm afraid that writing them is time consuming. i created a task for it to take on in the future #1231
fixed! see my comments above |
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.
good work monsieur
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.
lgtm nice work
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.
beautiful
Hi @keruch, I have a question. Is this PR moved incentives distribution (around 12k transfer as I see on Mainnet) from begin blocker to end blocker? |
Description
https://www.notion.so/dymension/ADR-x-Incentives-DoS-47238d8a29734ee686e25caef8b68c4f
Closes #XXX
All items are required. Please add a note to the item if the item is not applicable and
please add links to any relevant follow-up issues.
PR review checkboxes:
I have...
Unreleased
section inCHANGELOG.md
godoc
commentsSDK Checklist
map
time.Now()
sendCoin
and notSendCoins
Full security checklist here
For Reviewer:
After reviewer approval: