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.
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
IBC Rate Limiting #556
IBC Rate Limiting #556
Changes from 49 commits
950a274
21089a8
f991e57
6e2a037
32c67d5
8a608c5
d5e4098
573b0e8
43b8bca
3e7b583
acc565c
bff325c
fab8893
1e35a51
6b2cb18
8adfb9f
ebcae0b
8b5a0b9
2937b8d
d3a4369
c2e26da
d3612ad
2b25f18
10ee62a
f45ad70
12a0dfe
0200f69
c83d069
275cbdb
334de7f
bbf7ec1
1397864
9df5cbf
a2ef933
0d3b8c5
a2efe4e
e176282
e7abc29
67da44b
352601f
65200dc
59cdbba
ec41e24
15364df
ad01251
6be7aed
d02ce19
9bb5ef1
510d29d
e00d9ce
4213325
6ae4dd8
30e6e73
79a1930
02cfd23
93bd465
7d60f82
79d653e
c4f2618
3a69e45
560f7e2
1f3d75f
eb795bd
5409792
0d1c62e
4f46c2e
e4c1e9c
703d432
1a1bd4e
d3064f6
aa0af49
4fa3ad7
72b07ce
62d5857
fa505fc
8b5b394
e866d8e
dad4ec9
7bee669
90349c3
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
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.
What's the thinking around the ordering here? I'm not sure it matters, just curious. Conceptually, I'd probably move this down closer to transfer (because it's lower level), but not sure there's actually a reason to do so!
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.
No specific reasoning. I'm fine with moving it closer to transfer
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.
On second thought, I actually think the most logical ordering of everything is probably:
IBC
ratelimit
transfer
records
At the end of the day, it's pretty arbitrary since traffic floats in both directions. But records feels closest to the core application and rate limit/transfer feel more like related to the actually transport/packets.
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 framework makes sense. transfer seems closer to IBC than ratelimit (you can have transfer w/o ratelimit, but not vice-versa)
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'm not sure I follow the with/without argument?
I think of transfer as closer to the application (e.g. it's what mints/burns tokens to users) and ratelimit more as middleware that is meant to sit in between the relaying of packets (IBC) and the handling of those packets (Base App)
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.
yeah I think right now there's a bug - I'm refactoring the middleware wiring as we speak.
I think we need to revert one of the cases, and it depends on the ordering of the stack (as described in my last example), but right now we're reverting neither.
I'm also wondering if it makes sense to just have separate stacks?
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.
Does this error being thrown not revert sends? I would have expected the error to propagate through the middleware stack
Can you elaborate on this?
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.
Hmm actually yeah I think you're right with the current way we set it up. It think the SendPacket you linked above is called in ibc-go here
But that's just cause we added the rateLimitKeeper as the ics4Wrapper in the transfer keeper - but it's not clear to me yet if that's the right way to set it up
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.
Revisited this -
I think transfer has to sit at the bottom of the stack because the transfer
IBCModule
does not have theapp
attribute used for middleware (e.g. this vs this). Meaning, if you had transfer at the top of the stack, then there's no way for the TransferOnRecvPacket
callback to pass the packet down to a different middleware.That then brings us full circle back to the question of whether the stack should be
And between those two, I think I'd side with your OG suggestion that keeping ratelimit closest to transfer probably makes the most sense.
Sorry for the runaround!
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.
And then back to the error question…
(once again for context)
transfer
→ratelimit
→records
records
→ratelimit
→transfer
There are the following two error cases in the rate limit module:
ratelimit
is adequate because it will propagate back to the transfer module and should atomically fail & discard anything the transfer module had done alreadyrecords
and then get emitted in the core IBC keeperThere 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.
Should we also add rate limits for existing denoms in the upgrade?
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.
Yeah that's not a bad idea
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.
Why remove STARS out of curiosity?
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.
Just figured it was overkill, we had also removed it from main