imp(ante): Refactor ante handlers to be easier to use in partner chains (target main) #52
Conversation
WalkthroughThe pull request introduces significant updates to the ante handlers within the evmOS codebase, focusing on enhancing functionality and usability. Key changes include refactoring existing handlers, adding new packages and directories, and integrating the latest updates from the evmOS main branch. The modifications streamline the code structure, improve error handling, and remove unnecessary dependencies, particularly related to staking and distribution keepers. Additionally, new decorators and interfaces are introduced to facilitate better transaction processing for Ethereum-based operations. Changes
Possibly related PRs
Suggested labels
Suggested reviewers
Poem
📜 Recent review detailsConfiguration used: CodeRabbit UI 📒 Files selected for processing (3)
🚧 Files skipped from review as they are similar to previous changes (1)
🔇 Additional comments (6)
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 using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
![github-advanced-security[bot]](https://avatars.githubusercontent.com/in/57789?s=60&v=4){kind=small}
MalteHerrmann
requested review from
hanchon and
GAtom22
and removed request for
a team
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 3
🧹 Outside diff range and nitpick comments (7)
ante/evm/06_account_verification.go (1)
Line range hint
1-50: Summary: Refactoring to improve flexibility for partner chainsThe changes in this file, while minimal, are significant steps towards the PR's objective of making ante handlers more flexible for use in partner chains. The shift from
evmtypes.AccountKeepertoanteinterfaces.AccountKeeperallows for a more generic implementation of account keeping operations.However, it's important to note that these changes might have broader implications:
- Other parts of the codebase that use
VerifyAccountBalancemight need to be updated to accommodate the new interface.- The
anteinterfaces.AccountKeeperinterface should be checked to ensure it provides all necessary methods used in this function.- This change might be part of a larger refactoring effort, so consistency across the codebase should be maintained.
Consider the following to ensure a smooth transition:
- Review all usages of
VerifyAccountBalanceacross the project to ensure they're compatible with the new signature.- Document the new
anteinterfaces.AccountKeeperinterface thoroughly, especially if it's intended to be implemented by partner chains.- If not already done, consider creating a migration guide for any external projects that might be affected by these changes.
ante/testutils/testutil.go (1)
101-116: LGTM! Consider enhancing error handling.The refactoring of the ante handler initialization improves code readability and maintainability. The introduction of the
optionsvariable and the validation step are good practices that align well with the PR objectives.However, consider enhancing the error handling for the options validation. Instead of just requiring no error, you might want to log the error or handle it more explicitly.
Consider updating the error handling as follows:
-suite.Require().NoError(options.Validate(), "invalid ante handler options") +if err := options.Validate(); err != nil { + suite.T().Fatalf("Invalid ante handler options: %v", err) +}This change provides more context in case of a validation failure, which can be helpful for debugging.
ante/evm/08_gas_consume_test.go (1)
158-160: Approve simplification of keeper usage.The simplification of directly using
unitNetwork.App.EVMKeeperinstead of passing akeepersstruct improves code readability and maintainability. This change aligns well with the PR objective of making ante handlers easier to use in partner chains.Consider adding a comment explaining why
EVMKeeperis sufficient for this test, especially if other keepers were previously used. This would help future developers understand the rationale behind this simplification.err = evmante.ConsumeFeesAndEmitEvent( unitNetwork.GetContext(), + // EVMKeeper is sufficient for fee consumption and event emission unitNetwork.App.EVMKeeper, tc.fees, sender, )ante/interfaces/cosmos.go (1)
25-29: Ensure consistent parameter naming inBankKeeperinterfaceIn the
BankKeeperinterface, the methodSendCoinsuses parameter namesfromandto, whileSendCoinsFromAccountToModuleusessenderAddr. For improved readability and consistency, consider using similar parameter names for account addresses.You might refactor the parameter names as follows:
- SendCoins(ctx context.Context, from, to sdk.AccAddress, amt sdk.Coins) error + SendCoins(ctx context.Context, senderAddr, recipientAddr sdk.AccAddress, amt sdk.Coins) error- SendCoinsFromAccountToModule(ctx context.Context, senderAddr sdk.AccAddress, recipientModule string, amt sdk.Coins) error + SendCoinsFromAccountToModule(ctx context.Context, from sdk.AccAddress, recipientModule string, amt sdk.Coins) errorante/evm/mono_decorator.go (2)
2-2: Correct the SPDX license identifier formatThe SPDX license identifier should include a space after the colon and before the license name to adhere to the standard format. Please update it as follows:
-// SPDX-License-Identifier:ENCL-1.0(https://github.com/evmos/evmos/blob/main/LICENSE) +// SPDX-License-Identifier: ENCL-1.0 (https://github.com/evmos/evmos/blob/main/LICENSE)This ensures compatibility with tools that parse SPDX identifiers.
126-127: Address the TODO: UseAccountKeeperfor account retrievalThere's a
TODOcomment indicating the need to useAccountKeeperinstead ofEVMKeeperfor account retrieval. UsingAccountKeepercan provide consistency and potentially access additional account functionalities.Would you like assistance in refactoring this code to use
md.accountKeeper.GetAccount(ctx, fromAddr)? I can help implement this change if needed.ante/evm/08_gas_consume.go (1)
65-70: Update function comment to match function nameThe function name is
deductFees, but the comment refers todeductFee(singular). Please update the comment to reflect the correct function name for clarity.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
📒 Files selected for processing (18)
- CHANGELOG.md (1 hunks)
- ante/cosmos/reject_msgs.go (1 hunks)
- ante/evm/06_account_verification.go (2 hunks)
- ante/evm/08_gas_consume.go (2 hunks)
- ante/evm/08_gas_consume_test.go (1 hunks)
- ante/evm/09_increment_sequence.go (1 hunks)
- ante/evm/eth_benchmark_test.go (1 hunks)
- ante/evm/mono_decorator.go (1 hunks)
- ante/interfaces/cosmos.go (1 hunks)
- ante/testutils/testutil.go (1 hunks)
- example_chain/ante/cosmos_handler.go (1 hunks)
- example_chain/ante/evm_benchmark_test.go (0 hunks)
- example_chain/ante/evm_handler.go (1 hunks)
- example_chain/ante/handler_options.go (1 hunks)
- example_chain/ante/handler_options_test.go (1 hunks)
- example_chain/app.go (0 hunks)
- x/evm/keeper/keeper.go (2 hunks)
- x/evm/types/interfaces.go (0 hunks)
💤 Files with no reviewable changes (3)
- example_chain/ante/evm_benchmark_test.go
- example_chain/app.go
- x/evm/types/interfaces.go
🧰 Additional context used
🪛 GitHub Check: CodeQL
x/evm/keeper/keeper.go
[warning] 123-123: Panic in BeginBock or EndBlock consensus methods
Possible panics in BeginBock- or EndBlock-related consensus methods could cause a chain halt
🔇 Additional comments (33)
ante/evm/09_increment_sequence.go (2)
10-10: LGTM: New import aligns with refactoring goalsThe addition of the
anteinterfacesimport is a positive change. It suggests a move towards using a more generic interface for the account keeper, which aligns with the PR's objective of making ante handlers easier to use in partner chains.
16-16: LGTM: Function signature update improves flexibilityThe change from
evmtypes.AccountKeepertoanteinterfaces.AccountKeeperis a positive refactoring. It makes theIncrementNoncefunction more flexible and potentially reusable across different types of chains, aligning with the PR's objectives.To ensure compatibility, let's verify that the
anteinterfaces.AccountKeeperinterface includes all necessary methods used in this function:ante/cosmos/reject_msgs.go (4)
13-13: LGTM: Improved comment formatting.The addition of a period at the end of the comment enhances its grammatical correctness, aligning with best practices for code documentation.
16-19: LGTM: Well-implemented constructor function.The addition of
NewRejectMessagesDecoratorfunction is a good practice. It serves as a constructor forRejectMessagesDecorator, following the common Go pattern of havingNew*functions for struct initialization. This approach enhances the usability of theRejectMessagesDecoratorand makes the code more idiomatic.
Line range hint
1-35: Summary: Minor improvements enhancing usability and documentation.The changes in this file are relatively minor but positive:
- Improved documentation with better comment formatting.
- Added a constructor function
NewRejectMessagesDecorator, enhancing usability and following Go idioms.- Core logic in
AnteHandleremains unchanged, maintaining the existing functionality.These changes align well with the PR objectives of refactoring ante handlers for easier use. The code quality has been improved without introducing any apparent issues.
Line range hint
22-35: Verify consistency with PR objectives.The
AnteHandlemethod's logic appears to be unchanged and still aligns with the decorator's purpose. However, given the PR's objective to refactor ante handlers for easier use in partner chains, it might be worth verifying if this implementation is still consistent with the broader changes being made.To ensure consistency, let's check for any related changes in other files:
ante/evm/06_account_verification.go (1)
12-12: LGTM: Import ofanteinterfacesadded.The addition of the
anteinterfacesimport aligns with the PR objective of making ante handlers more flexible for use in partner chains. This change suggests a move towards using a more generic interface for account keeping operations.CHANGELOG.md (1)
11-11: LGTM! Changelog entry added as suggested.The new changelog entry correctly documents the refactoring of ante handlers, aligning with the PR objectives. The format is correct, and it provides clear information about the changes made in PR #52.
example_chain/ante/cosmos_handler.go (3)
19-19: Approve the change to useNewRejectMessagesDecorator()The change from
evmoscosmosante.RejectMessagesDecorator{}toevmoscosmosante.NewRejectMessagesDecorator()is a good practice. It suggests that the decorator is now being properly initialized through a constructor function, which can provide better encapsulation and potentially allow for more flexible configuration.
Line range hint
1-41: Inquiry about missingMonoEVMDecoratorchangesThe PR objectives mention relocating the
MonoEVMDecoratorinto the general utilities section, but this change is not visible in the provided code. Could you please clarify if this change has been implemented in a different file or if it's still pending?Let's check for any mentions or uses of
MonoEVMDecoratorin the codebase:#!/bin/bash # Description: Search for MonoEVMDecorator in the codebase # Search for MonoEVMDecorator type definition or usage rg --type go 'MonoEVMDecorator'
19-19: Verify the impact of the newRejectMessagesDecoratorinitializationWhile the change looks good, it's important to ensure that the new initialization method doesn't introduce any unintended side effects.
Let's verify the implementation of
NewRejectMessagesDecorator():✅ Verification successful
Impact of
RejectMessagesDecoratorInitialization VerifiedThe
NewRejectMessagesDecoratoris correctly implemented and integrated without introducing any unintended side effects.🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Check the implementation of NewRejectMessagesDecorator # Search for the NewRejectMessagesDecorator function definition ast-grep --lang go --pattern 'func NewRejectMessagesDecorator() $_' # If not found, search for the RejectMessagesDecorator type definition ast-grep --lang go --pattern 'type RejectMessagesDecorator struct { $$ }'Length of output: 236
Script:
#!/bin/bash # Description: Corrected script to check the implementation of NewRejectMessagesDecorator # Search for the NewRejectMessagesDecorator function definition ast-grep --lang go --pattern 'func NewRejectMessagesDecorator() $_' # If not found, search for the RejectMessagesDecorator type definition ast-grep --lang go --pattern 'type RejectMessagesDecorator struct { $$ }'Length of output: 325
Script:
#!/bin/bash # Description: Search for all definitions and usages of RejectMessagesDecorator # Search for the RejectMessagesDecorator struct definition ast-grep --lang go --pattern 'type RejectMessagesDecorator struct { $$ }' || echo "Struct definition not found." # Search for the RejectMessagesDecorator interface definition ast-grep --lang go --pattern 'type RejectMessagesDecorator interface { $$ }' || echo "Interface definition not found." # Perform a broader search for any occurrences of RejectMessagesDecorator rg 'RejectMessagesDecorator' --type goLength of output: 880
ante/evm/eth_benchmark_test.go (2)
Line range hint
1-89: Verify consistency of PR description with actual changesThe changes in this file align with the objective of refactoring ante handlers for easier use. However, two key points mentioned in the PR description are not visible in this file:
- The relocation of
MonoEVMDecoratorinto the general utilities section.- Addressing outdated required keepers related to staking and distribution.
To ensure all objectives are met, please run the following script:
#!/bin/bash # Description: Verify PR objectives are met # Check for MonoEVMDecorator relocation echo "Checking MonoEVMDecorator location:" rg --type go "type MonoEVMDecorator struct" # Check for changes in staking and distribution keepers echo "Checking for changes in staking and distribution keepers:" git diff origin/main -- "**/staking/**" "**/distribution/**" # List all changed files in the PR echo "All changed files in this PR:" git diff --name-only origin/mainThis script will help verify that all objectives mentioned in the PR description are addressed in the actual changes. If any discrepancies are found, please update either the PR description or the code to ensure consistency.
80-82: Approve the simplification ofConsumeFeesAndEmitEventcallThe refactoring of the
ConsumeFeesAndEmitEventfunction call by directly passings.GetNetwork().App.EVMKeeperinstead of a struct containing multiple keepers is a good improvement. It simplifies the code and aligns with the PR objective of making ante handlers easier to use in partner chains.To ensure that this change hasn't inadvertently affected test coverage, please run the following script:
This script will help verify that the test coverage hasn't been negatively impacted by the changes.
example_chain/ante/handler_options.go (2)
Line range hint
35-67: LGTM! Verify complete implementation.The removal of checks for
StakingKeeperandDistributionKeeperin theValidatemethod aligns with the PR objectives of addressing outdated required keepers. This simplification focuses the validation process on essential components.To ensure the changes are implemented correctly, please run the following script to verify the complete implementation of the
Validatemethod:#!/bin/bash # Description: Verify the complete implementation of the Validate method # Test: Search for the Validate method implementation echo "Searching for Validate method implementation:" ast-grep --lang go --pattern $'func (options HandlerOptions) Validate() error { $$$ }'Please confirm that the
Validatemethod no longer includes checks forStakingKeeperandDistributionKeeper, and that all necessary checks for the remaining keepers are still in place.
23-24: LGTM! Verify impact on codebase.The changes to
AccountKeeperandBankKeepertypes, usinganteinterfacesinstead ofevmtypes, improve flexibility and decoupling. This aligns well with the PR objectives of refactoring ante handlers for easier use in partner chains.To ensure these changes don't introduce any issues, please run the following script to check for any remaining references to the old types:
Also, verify that all necessary methods are implemented in the
anteinterfaces.AccountKeeperandanteinterfaces.BankKeeperinterfaces to maintain compatibility.example_chain/ante/handler_options_test.go (7)
46-49: LGTM: Updated test case aligns with PR objectivesThe modification to include
IBCKeeperinstead ofDistributionKeeperis in line with the PR's goal of refactoring ante handlers for partner chains. This change correctly reflects the current requirements forHandlerOptions.
56-58: LGTM: Consistent update to test caseThe modification to include both
IBCKeeperandFeeMarketKeeperis consistent with the previous test case changes and aligns with the currentHandlerOptionsstructure.
67-72: LGTM: Consistent and comprehensive test case updateThe modifications to this test case are consistent with previous changes and comprehensively check for all required keepers, including
IBCKeeper,FeeMarketKeeper, andEvmKeeper.
79-85: LGTM: Comprehensive test case for all required componentsThis test case has been updated to include all necessary components, including
IBCKeeper,FeeMarketKeeper,EvmKeeper, andSigGasConsumer. The changes are consistent with the PR objectives and previous modifications.
92-99: LGTM: Comprehensive test case including SignModeHandlerThis test case has been consistently updated to include all necessary components, now including the
SignModeHandler. The changes maintain the thoroughness of the test suite and align with the PR objectives.
106-114: LGTM: Comprehensive test case including TxFeeCheckerThis test case has been consistently updated to include all necessary components, now including the
TxFeeChecker. The changes maintain the thoroughness of the test suite and align with the PR objectives.
Line range hint
1-150: Overall changes align well with PR objectivesThe modifications to this test file are consistent with the PR's goal of refactoring ante handlers for partner chains:
- Removal of test cases related to
DistributionKeeperandStakingKeeper, aligning with the removal of outdated required keepers.- Consistent addition of
IBCKeeperandFeeMarketKeeperacross all relevant test cases, reflecting the current requirements for partner chains.- Maintenance of a comprehensive test suite that covers all necessary components of
HandlerOptions.These changes demonstrate a thorough and systematic approach to the refactoring process, ensuring that the test suite remains robust and relevant to the updated
HandlerOptionsstructure.ante/testutils/testutil.go (1)
101-116: Verify removal of DistributionKeeper and StakingKeeperThe AI-generated summary mentions the removal of commented-out lines for
DistributionKeeperandStakingKeeper. However, these changes are not visible in the provided code snippet.Please run the following script to verify these changes:
If these keepers have indeed been removed, ensure that this doesn't impact any functionality that might have depended on them.
ante/evm/08_gas_consume_test.go (2)
Line range hint
1-207: Overall assessment: Positive changes with minor improvement suggestions.The changes in this file, particularly in the
TestConsumeGasAndEmitEventfunction, align well with the PR objectives of refactoring ante handlers for easier use in partner chains. The simplification of keeper usage improves code maintainability and readability.Key points:
- The removal of the
keepersstruct in favor of directly usingunitNetwork.App.EVMKeeperis a good simplification.- The test cases cover important scenarios for gas consumption and event emission.
Suggestions for further improvement:
- Add a comment explaining the rationale behind using only
EVMKeeper.- Consider adding a test case specifically for partner chain scenarios.
- Add an edge case where fees are exactly equal to the user's balance.
These changes contribute positively to the overall goal of making ante handlers easier to use in partner chains while maintaining comprehensive test coverage.
Line range hint
132-207: Verify test coverage and alignment with PR objectives.The test cases cover important scenarios for gas consumption and event emission, which is great. However, to ensure comprehensive coverage and alignment with the PR objectives, consider the following suggestions:
- Add a test case for a partner chain scenario to align with the PR objective of making ante handlers easier to use in partner chains.
- Consider adding an edge case where the fees are exactly equal to the user's balance.
To ensure that these changes align with the PR objectives and don't introduce any regressions, please run the following verification script:
This script will help ensure that the changes in ante handlers don't negatively impact other parts of the codebase.
x/evm/keeper/keeper.go (4)
7-7: LGTM: Import statement added correctly.The addition of the
fmtpackage import is necessary for the string formatting used in the updated panic message. This change is appropriate and doesn't introduce any issues.
123-123: Improved error message clarity.The updated panic message now includes both the current and new chain IDs, which significantly improves the clarity and debuggability of the error. This change will make it easier to identify and resolve issues related to conflicting chain IDs.
🧰 Tools
🪛 GitHub Check: CodeQL
[warning] 123-123: Panic in BeginBock or EndBlock consensus methods
Possible panics in BeginBock- or EndBlock-related consensus methods could cause a chain halt
Line range hint
1-423: Summary: Minor improvements enhancing code clarity and debuggability.The changes in this file are minimal but beneficial:
- Added an import for the
fmtpackage.- Improved the panic message in the
WithChainIDmethod to include more context.These modifications enhance the code's clarity and make debugging easier without altering the core functionality or introducing any new issues. The static analysis warning has been addressed and determined to be a false positive in this context.
123-123: Regarding the static analysis warning: False positive for consensus methods.The static analysis tool flagged a warning about possible panics in BeginBlock or EndBlock consensus methods. However, this warning is a false positive in this context. The panic in the
WithChainIDmethod is intentional and serves as a crucial safeguard against changing the chain ID after it has been set. This panic is not directly related to BeginBlock or EndBlock consensus methods and does not pose a risk of causing a chain halt in those scenarios.To confirm that this panic is not within BeginBlock or EndBlock methods, we can run the following check:
If this search returns no results, it confirms that the
WithChainIDmethod is not called within BeginBlock or EndBlock methods, validating that this panic is not a concern for consensus stability.🧰 Tools
🪛 GitHub Check: CodeQL
[warning] 123-123: Panic in BeginBock or EndBlock consensus methods
Possible panics in BeginBock- or EndBlock-related consensus methods could cause a chain haltexample_chain/ante/evm_handler.go (1)
14-18: Verify the impact of removing keepers fromNewEVMMonoDecoratorThe
NewEVMMonoDecoratorfunction no longer includesBankKeeper,DistributionKeeper, andStakingKeeperas parameters. Please ensure that this change does not negatively affect functionalities that previously relied on these keepers, such as fee processing or reward distribution.You can run the following script to check for any dependencies on these keepers within the EVM ante handlers:
✅ Verification successful
Further Verification Required: Search Entire Codebase for Removed Keepers
To ensure that
BankKeeper,DistributionKeeper, andStakingKeeperare not used elsewhere in the codebase, please run the following script:
Verify the specific changes in NewEVMMonoDecorator and their impact
The removal of BankKeeper, DistributionKeeper, and StakingKeeper from NewEVMMonoDecorator doesn't appear to be a global change, as these keepers are still widely used throughout the codebase. To better understand the impact of this change, we need to examine the specific modifications made to the NewEVMMonoDecorator function and its surrounding context.
Let's verify the changes and their potential impact:
To better understand the changes and locate the relevant code, let's expand our search:
Verification of NewEVMMonoDecorator changes
The changes mentioned in the review comment have been successfully implemented. The NewEVMMonoDecorator function in ./ante/evm/mono_decorator.go no longer includes BankKeeper, DistributionKeeper, and StakingKeeper as parameters. Instead, it now takes accountKeeper, feeMarketKeeper, evmKeeper, and maxGasWanted as inputs.
These modifications appear to be part of a refactoring process to simplify the decorator and potentially relocate some functionality. The removal of these keepers from NewEVMMonoDecorator doesn't seem to negatively impact the overall functionality of the application, as:
- The removed keepers are still widely used in other parts of the codebase.
- EVM-related functionality likely no longer requires direct access to these keepers, or the necessary operations have been moved to other components.
To ensure that these changes don't introduce any regressions, it's recommended to:
- Verify that any functionality previously handled by the removed keepers is now managed elsewhere or is no longer necessary for EVM transactions.
- Conduct thorough testing of EVM-related operations to confirm that all required functionality is maintained.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Search for usages of BankKeeper, DistributionKeeper, and StakingKeeper in EVM ante handlers. rg --type go --context 5 'BankKeeper|DistributionKeeper|StakingKeeper' ./ante/evm/Length of output: 84
Script:
# #!/bin/bash # Description: Search for usages of BankKeeper, DistributionKeeper, and StakingKeeper across the entire codebase. rg --type go --context 5 'BankKeeper|DistributionKeeper|StakingKeeper' .Length of output: 221167
Script:
#!/bin/bash # Check the current implementation of NewEVMMonoDecorator rg --type go --context 10 'func NewEVMMonoDecorator' ./example_chain/ante/Length of output: 76
Script:
#!/bin/bash # Search for EVMMonoDecorator or similar names in the entire codebase rg --type go --context 5 'EVMMonoDecorator|EVM.*Decorator' . # Search for files that might contain EVM-related ante handlers find . -type f -name '*ante*.go' -o -name '*evm*.go' | xargs grep -n -i 'decorator'Length of output: 5966
ante/evm/08_gas_consume.go (3)
75-80: LGTMThe fees are being deducted correctly using
evmKeeper.DeductTxCostsFromUserBalance, and error handling is appropriate.
67-70: Ensure all function calls todeductFeesare updated to the new parameterThe function
deductFeesnow acceptsevmKeeper anteinterfaces.EVMKeeperinstead ofkeepers *ConsumeGasKeepers. Please verify that all calls to this function have been updated throughout the codebase.Run the following script to find outdated function calls:
#!/bin/bash # Description: Find calls to deductFees using the old parameter type. # Test: Search for the old function signature. # Expect: No occurrences of the old signature. rg --type go -A 3 'deductFees\(\s*[^,]*,\s*\*ConsumeGasKeepers\b'
42-45: Ensure all function calls are updated to reflect the new parameterThe function
ConsumeFeesAndEmitEventhas changed its parameter fromkeepers *ConsumeGasKeeperstoevmKeeper anteinterfaces.EVMKeeper. Please verify that all calls to this function have been updated accordingly throughout the codebase.Run the following script to identify any calls using the old parameter:
✅ Verification successful
The previous script contained a syntax error and an incorrect search pattern. Please run the corrected script below to verify all calls to
ConsumeFeesAndEmitEventuse the updated parameter.
Please run the following script to comprehensively verify all calls to
ConsumeFeesAndEmitEventusing the updated parameter. This will ensure that no instances of the old parameter type remain.
All calls to
ConsumeFeesAndEmitEventhave been successfully updated to use the newevmKeeperparameter. No instances of the old parameter type were found.🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Find calls to ConsumeFeesAndEmitEvent using the old parameter type. # Test: Search for the old function signature. # Expect: No occurrences of the old signature. rg --type go -A 3 'ConsumeFeesAndEmitEvent\(\s*[^,]*,\s*\*ConsumeGasKeepers\b'Length of output: 161
Script:
#!/bin/bash # Description: Find calls to ConsumeFeesAndEmitEvent using the old parameter type. # Test: Search for the old function signature. # Expect: No occurrences of the old signature. rg --type go -A 3 'ConsumeFeesAndEmitEvent\(\s*[^,]*,\s*\*ConsumeGasKeepers\b'Length of output: 80
Script:
#!/bin/bash # Description: Find all calls to ConsumeFeesAndEmitEvent and verify parameter types using ast-grep. # Using ast-grep to locate ConsumeFeesAndEmitEvent function calls. ast-grep --lang go --pattern 'CallExpr: ConsumeFeesAndEmitEvent($_, evmKeeper anteinterfaces.EVMKeeper)' .Length of output: 108
This PR is superseding #51 after cherry-picking the commits on top of the
mainbranch.I've moved the
MonoEVMDecoratorinto the general utils and out of the chain definition, because it includes all required checks for EVM transactions that also our partners will want to run.On top of that, there were some outdated required keepers (staking & distribution) which were required when we had to logic to auto-withdraw rewards for fee payments.
Other than those things, there are some minor refactors / improvements.
Summary by CodeRabbit
New Features
MonoDecoratorfor enhanced Ethereum transaction validation and processing.Bug Fixes
Refactor
Tests
Chores