-
Notifications
You must be signed in to change notification settings - Fork 208
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
Conversation
Co-authored-by: sampocs <[email protected]>
It would be nice if this PR supports blacklisting for specific token IBC transfer (receive/send) and export interface for registration of those tokens in keeper level so that it can be used on other modules. |
I was just passing by and saw this comment, you might be interested in this middleware celestia have implemented |
// } | ||
// | ||
// 2. Add hour epoch to store | ||
// 3. Add rate limits for existing denoms |
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.
Should we implement these here and just leave them commented out?
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.
It'd require adding the whole upgrade handler, so I think I'd lean toward doing it in a separate PR. Wdyt?
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.
Agreed, makes sense to put in a separate PR. We should just make sure that goes in the next upgrade.
Sam's suggestion to set the rate limit to 0 for the particular IBC denom in this case sounds like the cleanest solution to this question |
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.
Unit testing coverage is really strong. I have no comments and I think this is ready to merge if you feel good about it @sampocs 🎉
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!
x/ratelimit/keeper/rate_limit.go
Outdated
} | ||
|
||
// If the rate limit is exceeded or the denom is blacklisted, we emit an event | ||
func EmitRateLimitExceededEvent(ctx sdk.Context, denom, channelId string, direction types.PacketDirection, amount sdkmath.Int, err error) { |
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.
Nit: might be nice to have separate events for attempts to transfer blacklisted assets vs attempts to transfer assets whose rate limits were exceeded. The former seems important to be able to identify at a moment's notice in potential emergency scenarios
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 went back and forth on that a little. My thinking was you could easily determine whether it was blacklisted or throttled based on the error message and I thought it would be nice to have a common event type to listen to all blocked txs.
Another option is to change the event type to TransferBlocked and then add an attribute that's either RateLimitExceeded or BlacklistedDenom?
Also fine with just using different event types
Wdyt?
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.
change the event type to TransferBlocked and then add an attribute that's either RateLimitExceeded or BlacklistedDenom?
I think this would be nice n clean. I know this is nit, but it could make a big difference in the moment if there's ever a blacklist event
Was wondering @sampocs : is there any reason we should prevent from-and-to-Stride transfers of blacklisted assets? (eg bank send from stride1...A to stride1....B. I can't think of any, but curious if you can! |
Co-authored-by: riley-stride <[email protected]>
Good question! Nothing comes to mind |
Co-authored-by: antstalepresh <[email protected]> Co-authored-by: antstalepresh <[email protected]> Co-authored-by: Aidan Salzmann <[email protected]> Co-authored-by: riley-stride <[email protected]>
Co-Author: @antstalepresh
Closes: #414
Context and purpose of the change
The
ratelimit
module is meant as a safety control in the event of a bug or attack, and prevents massive inflows or outflows of IBC tokens to/from Stride in a short time frame. See module docs here for an overview of the purpose and tech spec.Brief Changelog
ratelimit
module as IBC middleware around transfer moduleAddRateLimit
,UpdateRateLimit
,ResetRateLimit
andRemoveRateLimit
rate-limit
,list-rate-limits
andrate-limits-by-chain
queriesUpgrade
The upgrade handler was excluded from the PR as the target upgrade has not been determined yet.
IN THE ASSOCIATED UPGRADE, WE MUST REMEMBER TO ADD THE STORE KEY AND HOUR EPOCH
WE MUST ALSO ADD RATE LIMITS FOR EXISTING DENOMS!
Testing
make start-docker-all && bash dockernet/scripts/ratelimit/run_all_tests.sh
Updates needed for sdk 46 and ibc-go v5
Before Merging
Author's Checklist
I have...
If skipped any of the tests above, explain.
Reviewers Checklist
All items are required. Please add a note if the item is not applicable and please add
your handle next to the items reviewed if you only reviewed selected items.
I have...
Documentation and Release Note
Unreleased
section inCHANGELOG.md
?How is the feature or change documented?
XXX
x/<module>/spec/
)