[CORE-834] Wire x/ratelimit methods to IBC transfer logic #962
Conversation
WalkthroughThe recent update introduces a rate-limiting module to an existing blockchain protocol, enhancing the control over transaction flow within the network. It integrates the module within the application logic, extends the IBC middleware for packet handling with rate-limiting features, and updates the keeper logic to manage these new functionalities. Utility functions and tests are added to support parsing and handling IBC packets, while new message types and constants are introduced to facilitate internal communication and metrics within the rate-limiting context. Changes
Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media? TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (invoked as PR comments)
Additionally, you can add CodeRabbit Configration File (
|
teddyding
force-pushed
the
td/ratelimit-ibc
branch
2 times, most recently
from
a21c886 to
1b010c3
Compare
teddyding
changed the title
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Review Status
Actionable comments generated: 3
Configuration used: CodeRabbit UI
Files selected for processing (10)
- protocol/app/app.go (5 hunks)
- protocol/x/ratelimit/ibc_middleware.go (1 hunks)
- protocol/x/ratelimit/keeper/keeper.go (3 hunks)
- protocol/x/ratelimit/keeper/package_test.go (1 hunks)
- protocol/x/ratelimit/keeper/packet.go (1 hunks)
- protocol/x/ratelimit/types/expected_keepers.go (2 hunks)
- protocol/x/ratelimit/types/ibc.go (1 hunks)
- protocol/x/ratelimit/types/keys.go (2 hunks)
- protocol/x/ratelimit/util/ibc.go (1 hunks)
- protocol/x/ratelimit/util/ibc_test.go (1 hunks)
Additional comments: 38
protocol/x/ratelimit/types/keys.go (3)
3-3: The addition of the "fmt" package import is necessary for the new function
GetPendingSendPacketKeywhich usesfmt.Sprintf.20-21: The new constant
PendingSendPacketPrefixis introduced for key-value store prefixing, which is a common pattern for namespacing in key-value stores to avoid collisions.27-29: The new function
GetPendingSendPacketKeygenerates a key for a pending send packet. It uses thefmt.Sprintffunction to concatenate the channel ID and sequence number with an underscore. This is a simple and effective way to create unique keys for each packet.protocol/x/ratelimit/types/ibc.go (4)
5-10: The
PacketDirectiontype is defined as anint32which is a common practice for enum-like types in Go. This will be used to indicate the direction of an IBC packet.12-18: The
IBCTransferPacketInfostruct is well-defined with clear field names indicating the information it holds about an IBC transfer packet. This will be useful for rate-limiting logic that needs to know about the packet's channel, denomination, and amount.20-28: The
AckResponseStatustype and its associated constants provide a clear way to represent the status of an IBC packet acknowledgment. This is a good use of Go'siotafor creating a series of related constants.30-34: The
AcknowledgementResponsestruct is introduced to encapsulate the status and potential error of an IBC transfer packet acknowledgment. This is a straightforward approach to handling acknowledgments.protocol/x/ratelimit/types/expected_keepers.go (2)
8-9: The addition of
capabilitytypesandclienttypesimports is necessary for the newICS4Wrapperinterface, which uses types from these packages.22-40: The
ICS4Wrapperinterface is introduced with methods that are essential for interacting with IBC packets. This interface will be implemented by the middleware to handle packet sending and acknowledgments. The methods are well-defined and include all necessary parameters for IBC operations.protocol/x/ratelimit/keeper/package_test.go (1)
- 10-50: The test
TestPendingPacketis added to ensure the correct behavior of the pending packet functionality. It tests setting, checking, and removing pending packets. The use ofrequirefrom thetestifypackage is appropriate for asserting conditions in tests.protocol/x/ratelimit/ibc_middleware.go (7)
23-28: The
IBCMiddlewarestruct is defined with fields for the underlying IBC module and the keeper. This struct will act as middleware for IBC, handling channel lifecycle events and packet processing.30-36: The
NewIBCMiddlewarefunction is correctly implemented to initialize theIBCMiddlewarestruct. It takes a keeper and an IBC module as parameters and returns a new instance ofIBCMiddleware.38-58: The
OnChanOpenInitmethod correctly implements theIBCMiddlewareinterface, delegating the call to the underlying IBC module. This pattern is consistent across all channel lifecycle event handlers in this file.141-153: The
OnAcknowledgementPacketmethod handles the acknowledgment of an IBC packet. It calls the keeper'sAcknowledgeIBCTransferPacketmethod and logs an error if it fails. This is a critical part of the IBC packet lifecycle.155-165: The
OnTimeoutPacketmethod handles the timeout of an IBC packet. It calls the keeper'sTimeoutIBCTransferPacketmethod and logs an error if it fails. This ensures that the state is correctly reverted if a packet times out.168-188: The
SendPacketandWriteAcknowledgementmethods implement theICS4Wrapperinterface. They delegate the work to the keeper, which contains the rate-limiting logic. This separation of concerns is good for modularity.200-203: The
GetAppVersionmethod provides the application version for the underlying application. This is a simple getter method that is part of theICS4Wrapperinterface.protocol/x/ratelimit/keeper/packet.go (7)
22-35: The
RemovePendingSendPacketandSetPendingSendPacketmethods are correctly implemented to manage the state of pending IBC packets. They use a prefix store for namespacing and simple byte slices for values.37-43: The
HasPendingSendPacketmethod checks if a packet sequence number is pending. It uses the same prefix store pattern as the other methods, ensuring consistency in how packet state is managed.46-75: The
AcknowledgeIBCTransferPacketandTimeoutIBCTransferPacketmethods handle the acknowledgment and timeout of IBC packets, respectively. They include logic to update the state based on the success or failure of the packet transfer.91-106: The
UndoSendPacketmethod is idempotent and reverts the capacity decrease that happened during the send if a packet fails or times out. This is an important feature for maintaining correct state in the event of failures.108-145: The
SendPacketmethod wraps the IBCChannelKeeper'sSendPacketfunction and includes rate-limiting logic. It ensures that packets are sent according to the rate limits set for the channel.148-165: The
SendRateLimitedPacketmethod checks if the rate limit has been exceeded before sending the packet. This is a critical part of the rate-limiting functionality.168-181: The
WriteAcknowledgementandGetAppVersionmethods wrap corresponding methods from the IBCChannelKeeper. They are simple pass-through methods that allow the keeper to interact with the IBC module.protocol/x/ratelimit/util/ibc_test.go (3)
42-95: The tests
TestParseDenomFromRecvPacketandTestParseDenomFromSendPacketensure that the utility functions for parsing denominations from IBC packets work as expected. These tests are comprehensive and cover different scenarios.130-173: The
TestParsePacketInfotest checks theParsePacketInfoutility function, ensuring it correctly parses packet information for both send and receive directions. This is an important test for verifying packet parsing logic.176-231: The
TestUnpackAcknowledgementResponseForTransfertest ensures that the unpacking of IBC transfer packet acknowledgments works correctly and handles both success and error cases. This is crucial for the correct processing of acknowledgments.protocol/x/ratelimit/util/ibc.go (4)
21-44: The
ParseDenomFromSendPacketfunction is implemented to parse the denomination from a send packet. It correctly handles both native and non-native tokens, returning the appropriate denomination for rate-limiting purposes.46-106: The
ParseDenomFromRecvPacketfunction handles parsing the denomination from a receive packet. It accounts for whether the chain is acting as a source or sink and adjusts the denomination accordingly.109-147: The
ParsePacketInfofunction extracts information from an IBC packet and constructs anIBCTransferPacketInfostruct. It handles both send and receive directions and performs necessary parsing and conversion of the amount.150-191: The
UnpackAcknowledgementResponseForTransferfunction unmarshals acknowledgments for IBC transfers and determines the status. It handles both result and error acknowledgments, providing a structured response.protocol/x/ratelimit/keeper/keeper.go (3)
29-29: The addition of the
ics4Wrapperfield to theKeeperstruct is necessary for the keeper to interact with the IBC module. This allows the keeper to send packets and write acknowledgments.43-43: The
NewKeeperfunction is updated to accept anICS4Wrapperas a parameter, which is then set on theKeeperstruct. This change is necessary for the keeper to perform IBC operations.57-58: The expanded documentation for the
ProcessWithdrawalfunction provides clarity on the error handling. It specifies that an error will result in the transaction failing upstream, which is important for developers to understand the implications of capacity inefficiencies.protocol/app/app.go (4)
153-153: The import of the
ratelimitmoduleand its sub-packages is correctly added to integrate the new rate-limiting functionality.543-549: Capabilities for the new
ratelimitmoduleare being granted here. It's important to ensure that the capability is correctly scoped and that no other module can accidentally or maliciously claim the same capability.Verification successful
The verification process has confirmed that the
ratelimitmodulecapability is scoped uniquely within the codebase, as no other instances ofScopeToModuleusingratelimitmoduletypes.ModuleNamewere found outside of the one inapp.go. This addresses the concern raised in the review comment.* 596-596: The `TransferKeeper` is being modified to include the `RatelimitKeeper` as an `ICS4Wrapper`. This change is crucial for the middleware to function correctly. It's important to ensure that the `TransferKeeper` is correctly updated everywhere it's used.Scripts Executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Verify that the ratelimitmodule's capability is unique and not claimed elsewhere. ast-grep --lang go --pattern $'app.CapabilityKeeper.ScopeToModule("ratelimitmoduletypes.ModuleName")'Length of output: 102
Script:
#!/bin/bash # Broaden the search to find any instances of ScopeToModule being used with the ratelimitmodule's capability rg 'ScopeToModule\(.*ratelimitmoduletypes.ModuleName.*\)'Length of output: 148
* 607-610: The `ratelimitmodule` middleware is being wrapped over the IBC Transfer module. This is a critical integration point and must be done correctly to ensure that the middleware functions as expected.Verification successful
---
---
--- The output from the script shows the instantiation of `app.TransferKeeper` with `ibctransferkeeper.NewKeeper`. The parameters passed to this function include `app.RatelimitKeeper`, which is commented as `ICS4Wrapper`. This confirms that the `RatelimitKeeper` is indeed being passed as a parameter where expected in the instantiation of `TransferKeeper`. Based on this information, the review comment stating that the `TransferKeeper` is being modified to include the `RatelimitKeeper` as an `ICS4Wrapper` is consistent with the codebase. The verification process has confirmed that the `TransferKeeper` is correctly updated in the `app.go` file. </details> <details> <summary>Scripts Executed</summary> The following scripts were executed for the analysis: --- Script: ```shell #!/bin/bash # Verify that TransferKeeper is updated to include RatelimitKeeper as ICS4Wrapper wherever used. ast-grep --lang go --pattern $'ibctransferkeeper.NewKeeper($_, $_, $_, app.RatelimitKeeper, $_, $_, $_)'Length of output: 105
Script:
#!/bin/bash # Search for instances of TransferKeeper being instantiated or referenced to verify the inclusion of RatelimitKeeper. ast-grep --lang go --pattern $'ibctransferkeeper.NewKeeper($$$)'Length of output: 65
Script:
#!/bin/bash # Broaden the search to find any reference to TransferKeeper in the codebase. ast-grep --lang go --pattern $'TransferKeeper'Length of output: 45
Script:
#!/bin/bash # Use ripgrep to perform a text-based search for "TransferKeeper" across the codebase. rg 'TransferKeeper'Length of output: 482
Script:
#!/bin/bash # Extract the instantiation of TransferKeeper to check the parameters passed to NewKeeper. rg 'NewKeeper' protocol/app/app.goLength of output: 1505
Script:
#!/bin/bash # Display the lines around the instantiation of TransferKeeper to check the parameters passed to NewKeeper. cat protocol/app/app.go | grep -C 5 'app.TransferKeeper = ibctransferkeeper.NewKeeper'Length of output: 387
| @@ -0,0 +1,232 @@ | |||
| package util_test | |||
There was a problem hiding this comment.
Unit tests most re-used from https://github.com/Stride-Labs/stride/blob/121f2ac5d2e5f8e406f89999410a49ea4277a552/x/ratelimit
| @@ -0,0 +1,191 @@ | |||
| package util | |||
There was a problem hiding this comment.
Utilities mostly re-used from https://github.com/Stride-Labs/stride/blob/121f2ac5d2e5f8e406f89999410a49ea4277a552/x/ratelimit
There was a problem hiding this comment.
Can you separate these util functions into two files:
- exact copy from Stride
- methods that made some modifications
There was a problem hiding this comment.
Done - moved exact copies and tests in to file parse_denom.go and parse_denom_test.go
There was a problem hiding this comment.
Review Status
Actionable comments generated: 0
Configuration used: CodeRabbit UI
Files selected for processing (2)
- protocol/app/app.go (4 hunks)
- protocol/x/ratelimit/util/capacity_test.go (1 hunks)
Files skipped from review as they are similar to previous changes (1)
- protocol/app/app.go
Additional comments: 5
protocol/x/ratelimit/util/capacity_test.go (5)
16-16: The test function
TestCalculateNewCapacityListhas been renamed appropriately to reflect its functionality. Ensure that all references to this function are updated accordingly.16-16: The test cases within
TestCalculateNewCapacityListare comprehensive and cover a wide range of scenarios, including edge cases. The use of table-driven tests is a good practice for clarity and maintainability.16-16: The error handling in the test cases is done correctly using
require.Errorandrequire.NoError. The assertions are appropriate for the conditions being tested.16-16: The expected results in the test cases appear to match the logic of the
CalculateNewCapacityListfunction. It's important to ensure that the function's logic is sound and that the test cases accurately reflect the expected behavior.16-16: The error case where the length of the capacity list does not match the length of the limiters is handled correctly, and the error message provides sufficient information to diagnose the issue.
| @@ -0,0 +1,191 @@ | |||
| package util | |||
There was a problem hiding this comment.
Can you separate these util functions into two files:
- exact copy from Stride
- methods that made some modifications
There was a problem hiding this comment.
Review Status
Actionable comments generated: 9
Configuration used: CodeRabbit UI
Files selected for processing (7)
- protocol/x/ratelimit/ibc_middleware.go (1 hunks)
- protocol/x/ratelimit/keeper/keeper.go (2 hunks)
- protocol/x/ratelimit/keeper/packet_test.go (1 hunks)
- protocol/x/ratelimit/util/ibc.go (1 hunks)
- protocol/x/ratelimit/util/ibc_test.go (1 hunks)
- protocol/x/ratelimit/util/parse_denom.go (1 hunks)
- protocol/x/ratelimit/util/parse_denom_test.go (1 hunks)
| return | ||
| } | ||
| // Undo'ing a withdrawal is equivalent to processing a deposit. | ||
| k.ProcessDeposit(ctx, denom, amount) |
There was a problem hiding this comment.
Does calling this function have any negative downstream effects? For example logging or metrics that indicate a deposit happened?
Wonder if it's better to have an explicit UndoWithdrawal function to prevent these issues (now or in the future if code is modified/refactored)
There was a problem hiding this comment.
Good point, I renamed ProcessDeposit to IncrementCapacitiesForDenom and wrapped UndoWithdrawal around it (and added metrics)
There was a problem hiding this comment.
Review Status
Actionable comments generated: 0
Configuration used: CodeRabbit UI
Files selected for processing (1)
- protocol/x/ratelimit/util/parse_denom_test.go (1 hunks)
Files skipped from review as they are similar to previous changes (1)
- protocol/x/ratelimit/util/parse_denom_test.go
There was a problem hiding this comment.
Review Status
Actionable comments generated: 0
Configuration used: CodeRabbit UI
Files selected for processing (6)
- protocol/lib/ante/internal_msg.go (2 hunks)
- protocol/lib/metrics/constants.go (1 hunks)
- protocol/x/ratelimit/ibc_middleware.go (1 hunks)
- protocol/x/ratelimit/keeper/keeper.go (3 hunks)
- protocol/x/ratelimit/keeper/packet.go (1 hunks)
- protocol/x/ratelimit/util/ibc.go (1 hunks)
Files skipped from review as they are similar to previous changes (3)
- protocol/x/ratelimit/ibc_middleware.go
- protocol/x/ratelimit/keeper/keeper.go
- protocol/x/ratelimit/util/ibc.go
Additional comments: 12
protocol/lib/ante/internal_msg.go (2)
- 25-25: The import of
ratelimitis correctly placed alphabetically among other imports.- 102-103: The addition of
MsgSetLimitParamsandMsgSetLimitParamsResponseto theIsInternalMsgfunction is consistent with the pattern of adding message types to this function. Ensure that these message types are indeed intended to be internal and not exposed to external users or systems.protocol/x/ratelimit/keeper/packet.go (9)
- 24-28: The
RemovePendingSendPacketfunction correctly deletes a key from the store, which is used to track pending send packets. This is a standard pattern for managing state in a key-value store.- 31-35: The
SetPendingSendPacketfunction correctly sets a key in the store to indicate a packet is pending. Using a single bit as the value is efficient for this purpose.- 39-43: The
HasPendingSendPacketfunction correctly checks for the existence of a key in the store. This is a standard existence check in a key-value store.- 49-74: The
AcknowledgeIBCTransferPacketfunction handles the acknowledgement of an IBC transfer packet. It checks the status of the acknowledgement and either removes the pending packet or undoes the send packet. This logic is consistent with the expected behavior of acknowledging a packet.- 81-88: The
TimeoutIBCTransferPacketfunction correctly handles the timeout of an IBC transfer packet by undoing the send packet. This is the expected behavior when a packet times out.- 93-106: The
UndoSendPacketfunction is idempotent, as it checks for the existence of the pending packet before attempting to undo it. This is a good practice to prevent unintended side effects.- 110-145: The
SendPacketfunction sends a packet and attempts to send a rate-limited packet. It logs an error if the rate-limited send fails. Ensure that the error logging is sufficient for debugging purposes and consider if any additional error handling is necessary.- 150-165: The
TrySendRateLimitedPacketfunction processes a withdrawal and sets the packet as pending if successful. Ensure that theProcessWithdrawalfunction has appropriate error handling and that the pending packet state is correctly managed.- 168-181: The
WriteAcknowledgementandGetAppVersionfunctions are simple wrappers around theics4Wrapperinterface methods. Ensure that theics4Wrapperinterface is correctly implemented and that these functions are used appropriately in the middleware.protocol/lib/metrics/constants.go (1)
- 405-408: The addition of the
UndoWithdrawAmountconstant is consistent with the naming and categorization of other constants in this file. Ensure that this constant is used appropriately wherever metrics related to undoing a withdrawal amount are recorded.
teddyding
force-pushed
the
td/ratelimit-ibc
branch
from
3f47889 to
d1a7930
Compare
There was a problem hiding this comment.
Review Status
Actionable comments generated: 1
Configuration used: CodeRabbit UI
Files selected for processing (14)
- protocol/app/app.go (4 hunks)
- protocol/lib/metrics/constants.go (1 hunks)
- protocol/x/ratelimit/ibc_middleware.go (1 hunks)
- protocol/x/ratelimit/keeper/keeper.go (3 hunks)
- protocol/x/ratelimit/keeper/packet.go (1 hunks)
- protocol/x/ratelimit/keeper/packet_test.go (1 hunks)
- protocol/x/ratelimit/types/expected_keepers.go (2 hunks)
- protocol/x/ratelimit/types/ibc.go (1 hunks)
- protocol/x/ratelimit/types/keys.go (2 hunks)
- protocol/x/ratelimit/util/capacity_test.go (1 hunks)
- protocol/x/ratelimit/util/ibc.go (1 hunks)
- protocol/x/ratelimit/util/ibc_test.go (1 hunks)
- protocol/x/ratelimit/util/parse_denom.go (1 hunks)
- protocol/x/ratelimit/util/parse_denom_test.go (1 hunks)
Files skipped from review as they are similar to previous changes (9)
- protocol/lib/metrics/constants.go
- protocol/x/ratelimit/ibc_middleware.go
- protocol/x/ratelimit/keeper/keeper.go
- protocol/x/ratelimit/keeper/packet.go
- protocol/x/ratelimit/keeper/packet_test.go
- protocol/x/ratelimit/util/ibc.go
- protocol/x/ratelimit/util/ibc_test.go
- protocol/x/ratelimit/util/parse_denom.go
- protocol/x/ratelimit/util/parse_denom_test.go
Additional comments: 9
protocol/x/ratelimit/types/keys.go (3)
- 3-3: The import of the "fmt" package is added to support the new
GetPendingSendPacketKeyfunction.- 20-21: The new constant
PendingSendPacketPrefixis introduced for key-value store operations.- 27-29: The
GetPendingSendPacketKeyfunction constructs a key for pending send packets. Ensure that the format used here is consistent with other key generation patterns in the system.protocol/x/ratelimit/types/expected_keepers.go (2)
- 8-10: New imports for
capabilitytypes,clienttypes, andibcexportedare added to support the newICS4Wrapperinterface methods.- 22-40: The
ICS4Wrapperinterface is expanded with new methods for middleware. Ensure that the new methods are implemented wherever this interface is used and that the method signatures align with the expected behavior.protocol/x/ratelimit/util/capacity_test.go (1)
- 16-16: The test function
TestUpdateAllCapacitiesEndBlockerhas been renamed toTestCalculateNewCapacityList. This change should be reflected in any test suite or documentation that references this test.protocol/app/app.go (3)
- 633-644: The
TransferKeeperis correctly modified to incorporate theRatelimitKeeperas anICS4Wrapper. This change aligns with the PR objectives to integrate rate-limiting into the IBC transfer logic.- 650-650: The middleware stack is correctly updated to wrap the
ratelimitmodule.NewIBCMiddlewarearound thetransferStack. This change is consistent with the PR's goal of adding rate-limiting functionality to the IBC transfer module.- 656-656: The
ibcRouteris updated to include thetransferStackwith the rate-limiting middleware. This ensures that the IBC transfer module will use the new middleware for packet handling.
| // grant capabilities for the ibc, ibc-transfer, ICAHostKeeper and ratelimit modules | ||
|
|
||
| scopedIBCKeeper := app.CapabilityKeeper.ScopeToModule(ibcexported.ModuleName) | ||
| scopedIBCTransferKeeper := app.CapabilityKeeper.ScopeToModule(ibctransfertypes.ModuleName) | ||
| scopedICAHostKeeper := app.CapabilityKeeper.ScopeToModule(icahosttypes.SubModuleName) | ||
| // scopedRatelimitKeeper is not used as an input to any other module. | ||
| app.CapabilityKeeper.ScopeToModule(ratelimitmoduletypes.ModuleName) |
There was a problem hiding this comment.
The addition of the ratelimit module to the capabilities grant is noted. However, the scoped keeper for ratelimit is created but not stored or used. This could potentially be an oversight.
Ensure that the scoped keeper for the ratelimit module is stored and used appropriately, or remove it if it's unnecessary.
teddyding
force-pushed
the
td/ratelimit-ibc
branch
from
d1a7930 to
b700060
Compare
There was a problem hiding this comment.
Review Status
Actionable comments generated: 0
Configuration used: CodeRabbit UI
Files selected for processing (14)
- protocol/app/app.go (4 hunks)
- protocol/lib/metrics/constants.go (1 hunks)
- protocol/x/ratelimit/ibc_middleware.go (1 hunks)
- protocol/x/ratelimit/keeper/keeper.go (3 hunks)
- protocol/x/ratelimit/keeper/packet.go (1 hunks)
- protocol/x/ratelimit/keeper/packet_test.go (1 hunks)
- protocol/x/ratelimit/types/expected_keepers.go (2 hunks)
- protocol/x/ratelimit/types/ibc.go (1 hunks)
- protocol/x/ratelimit/types/keys.go (2 hunks)
- protocol/x/ratelimit/util/capacity_test.go (1 hunks)
- protocol/x/ratelimit/util/ibc.go (1 hunks)
- protocol/x/ratelimit/util/ibc_test.go (1 hunks)
- protocol/x/ratelimit/util/parse_denom.go (1 hunks)
- protocol/x/ratelimit/util/parse_denom_test.go (1 hunks)
Files skipped from review as they are similar to previous changes (14)
- protocol/app/app.go
- protocol/lib/metrics/constants.go
- protocol/x/ratelimit/ibc_middleware.go
- protocol/x/ratelimit/keeper/keeper.go
- protocol/x/ratelimit/keeper/packet.go
- protocol/x/ratelimit/keeper/packet_test.go
- protocol/x/ratelimit/types/expected_keepers.go
- protocol/x/ratelimit/types/ibc.go
- protocol/x/ratelimit/types/keys.go
- protocol/x/ratelimit/util/capacity_test.go
- protocol/x/ratelimit/util/ibc.go
- protocol/x/ratelimit/util/ibc_test.go
- protocol/x/ratelimit/util/parse_denom.go
- protocol/x/ratelimit/util/parse_denom_test.go
Changelist
The overall architecture of the IBC middleware resembles closely to Stride's
x/ratelimitimplementation. Thex/ratelimitmodule spec includes a high level summary.Many functions were re-used or re-written from Stride implementation. I left TODO items to for giving generally better attributions.
Test Plan
Some unit tests.
More tests to come in below tickets:
Author/Reviewer Checklist
state-breakinglabel.indexer-postgres-breakinglabel.PrepareProposalorProcessProposal, manually add the labelproposal-breaking.feature:[feature-name].backport/[branch-name].refactor,chore,bug.