Skip to content
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

refactor(precompiles): chain as source of truth #66

Merged
merged 6 commits into from
Jul 31, 2024

Conversation

MaxMustermann2
Copy link
Collaborator

@MaxMustermann2 MaxMustermann2 commented Jul 30, 2024

The ExocoreGateway allows the contract owner to call precompiles which allow the registration of a client chain or a token. It also enables updates of these items. To check whether a request is an update or an addition, it relies on the ExocoreGateway keeping a copy of registered items. However, this does not work for items which were registered at genesis.

This PR works around that problem by requiring that the single source of truth be the precompiles, whose responsibility is to report if a request was an update or an addition.

Summary by CodeRabbit

Summary by CodeRabbit

  • New Features

    • Consolidated token management functionality, allowing for both addition and updating of tokens with a single function.
    • Enhanced clarity in client chain registration processes, now allowing for updates in addition to registrations.
    • Introduced new methods for checking registration status of client chains.
  • Documentation

    • Updated the contracts owner manual for improved clarity on token management processes.
  • Bug Fixes

    • Improved input validation for token management functions, ensuring better handling of erroneous inputs.
  • Refactor

    • Streamlined various function signatures and error handling logic across multiple contracts to enhance maintainability and clarity.
  • Chores

    • Removed outdated mappings and error declarations to simplify contract logic and improve functionality.

The `ExocoreGateway` allows the contract owner to call precompiles which
allow the registration of a client chain or a token. It also enables
updated of these items. To check whether a request is an update or an
addition, it relies on the ExocoreGateway keeping a copy of registered
items. However, this does not work for items which were registered at
genesis.

This PR works around that problem by requiring that the single source of
truth be the precompiles, whose responsibility is to report if a request
was an update or an addition.
Copy link
Contributor

coderabbitai bot commented Jul 30, 2024

Walkthrough

The recent updates to the contract system significantly enhance token management by consolidating functionalities for adding and updating whitelist tokens. Key changes include renaming functions for clarity, removing redundant elements, and streamlining processes. These improvements create a more efficient, user-friendly system for managing tokens and client chains, ultimately simplifying the interaction for contract owners.

Changes

Files Change Summary
docs/contracts-owner-manual.md Updated terminology and consolidated add/update functions for clearer operations.
script/3_Setup.s.sol, test/foundry/ExocoreDeployer.t.sol Renamed addWhitelistTokens to addOrUpdateWhitelistTokens, enhancing flexibility in token management.
src/core/ExocoreGateway.sol, src/interfaces/IExocoreGateway.sol, src/interfaces/precompiles/IAssets.sol Renamed functions to reflect new dual capabilities for registration and updates of client chains and tokens.
src/libraries/Errors.sol, src/storage/ExocoreGatewayStorage.sol Removed error declarations and mappings related to client chain registration, simplifying error handling.
test/foundry/unit/ExocoreGateway.t.sol, test/mocks/ExocoreGatewayMock.sol Updated tests to reflect new function names and revised validation checks for token management processes.
test/mocks/AssetsMock.sol Enhanced methods for registering/updating client chains and tokens; returned additional status booleans.

Sequence Diagram(s)

sequenceDiagram
    participant Owner
    participant ExocoreGateway
    participant ClientChain
    participant Token

    Owner->>ExocoreGateway: addOrUpdateWhitelistTokens()
    ExocoreGateway->>Token: Validate tokens
    Token->>ExocoreGateway: Return validation status
    ExocoreGateway->>ClientChain: Register or update chain
    ClientChain->>ExocoreGateway: Return registration status
    ExocoreGateway->>Owner: Emit events based on action
Loading

🐇 "In the garden where tokens play,
Adding and updating in a single sway.
No more confusion, just hop along,
With clearer paths, we'll sing our song!
Whitelist tokens, both new and old,
A rabbit's tale of changes bold!" 🥕


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?

Share
Tips

Chat

There are 3 ways to chat with CodeRabbit:

  • Review comments: Directly reply to a review comment made by CodeRabbit. Example:
    • I pushed a fix in commit <commit_id>.
    • Generate unit testing code for this file.
    • Open a follow-up GitHub issue for this discussion.
  • Files and specific lines of code (under the "Files changed" tab): Tag @coderabbitai in a new review comment at the desired location with your query. Examples:
    • @coderabbitai generate unit testing code for this file.
    • @coderabbitai modularize this function.
  • PR comments: Tag @coderabbitai in a new PR comment to ask questions about the PR branch. For the best results, please provide a very specific query, as very limited context is provided in this mode. Examples:
    • @coderabbitai generate interesting stats about this repository and render them as a table.
    • @coderabbitai show all the console.log statements in this repository.
    • @coderabbitai read src/utils.ts and generate unit testing code.
    • @coderabbitai read the files in the src/scheduler package and generate a class diagram using mermaid and a README in the markdown format.
    • @coderabbitai help me debug CodeRabbit configuration file.

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)

  • @coderabbitai pause to pause the reviews on a PR.
  • @coderabbitai resume to resume the paused reviews.
  • @coderabbitai review to trigger an incremental review. This is useful when automatic reviews are disabled for the repository.
  • @coderabbitai full review to do a full review from scratch and review all the files again.
  • @coderabbitai summary to regenerate the summary of the PR.
  • @coderabbitai resolve resolve all the CodeRabbit review comments.
  • @coderabbitai configuration to show the current CodeRabbit configuration for the repository.
  • @coderabbitai help to get help.

Additionally, you can add @coderabbitai ignore anywhere in the PR description to prevent this PR from being reviewed.

CodeRabbit Configuration File (.coderabbit.yaml)

  • You can programmatically configure CodeRabbit by adding a .coderabbit.yaml file to the root of your repository.
  • Please see the configuration documentation for more information.
  • If your editor has YAML language server enabled, you can add the path at the top of this file to enable auto-completion and validation: # yaml-language-server: $schema=https://coderabbit.ai/integrations/schema.v2.json

Documentation and Community

  • Visit our Documentation for detailed information on how to use CodeRabbit.
  • Join our Discord Community to get help, request features, and share feedback.
  • Follow us on X/Twitter for updates and announcements.

Copy link
Contributor

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 0

Outside diff range, codebase verification and nitpick comments (2)
docs/contracts-owner-manual.md (2)

20-20: Add the missing article "the".

The section title should include the article "the" before "whitelist" for grammatical correctness.

-## add or update tokens to whitelist
+## add or update tokens to the whitelist
Tools
LanguageTool

[uncategorized] ~20-~20: You might be missing the article “the” here.
Context: ...r contract. ## add or update tokens to whitelist Another important task before restakin...

(AI_EN_LECTOR_MISSING_DETERMINER_THE)


22-22: Add the missing article "the".

The description should include the article "the" before "whitelist" for grammatical correctness.

-Another important task before restaking being activated is to add tokens to whitelist to mark them as stake-able on both Exocore and client chain.
+Another important task before restaking being activated is to add tokens to the whitelist to mark them as stake-able on both Exocore and client chain.
Tools
LanguageTool

[uncategorized] ~22-~22: You might be missing the article “the” here.
Context: ...ing being activated is to add tokens to whitelist to mark them as stake-able on both Exoc...

(AI_EN_LECTOR_MISSING_DETERMINER_THE)

Review details

Configuration used: CodeRabbit UI
Review profile: CHILL

Commits

Files that changed from the base of the PR and between 29f2982 and 9c469d4.

Files selected for processing (12)
  • docs/contracts-owner-manual.md (1 hunks)
  • script/3_Setup.s.sol (1 hunks)
  • src/core/ExocoreGateway.sol (4 hunks)
  • src/interfaces/IExocoreGateway.sol (2 hunks)
  • src/interfaces/precompiles/IAssets.sol (1 hunks)
  • src/libraries/Errors.sol (1 hunks)
  • src/storage/ExocoreGatewayStorage.sol (2 hunks)
  • test/foundry/ExocoreDeployer.t.sol (1 hunks)
  • test/foundry/unit/ExoCapsule.t.sol (1 hunks)
  • test/foundry/unit/ExocoreGateway.t.sol (15 hunks)
  • test/mocks/AssetsMock.sol (1 hunks)
  • test/mocks/ExocoreGatewayMock.sol (3 hunks)
Additional context used
Learnings (4)
src/interfaces/IExocoreGateway.sol (1)
Learnt from: adu-web3
PR: ExocoreNetwork/exocore-contracts#39
File: test/foundry/unit/ExocoreGateway.t.sol:360-366
Timestamp: 2024-07-02T01:45:58.683Z
Learning: The `updateWhitelistedTokens` function in `ExocoreGateway` interacts solely with the trusted `ASSET_CONTRACT` precompile, mitigating the need for a reentrancy guard.
test/mocks/ExocoreGatewayMock.sol (2)
Learnt from: adu-web3
PR: ExocoreNetwork/exocore-contracts#23
File: test/mocks/ExocoreGatewayMock.sol:0-0
Timestamp: 2024-06-17T07:43:43.986Z
Learning: User adu-web3 suggests that the `chainToBootstrapped[clientChainId]` marking in `ExocoreGatewayMock.sol` has no significant effects beyond setting a state and that synchronization issues are currently not a concern. They are open to implementing a response check in the future if necessary.
Learnt from: adu-web3
PR: ExocoreNetwork/exocore-contracts#39
File: test/foundry/unit/ExocoreGateway.t.sol:360-366
Timestamp: 2024-07-02T01:45:58.683Z
Learning: The `updateWhitelistedTokens` function in `ExocoreGateway` interacts solely with the trusted `ASSET_CONTRACT` precompile, mitigating the need for a reentrancy guard.
test/foundry/ExocoreDeployer.t.sol (1)
Learnt from: adu-web3
PR: ExocoreNetwork/exocore-contracts#39
File: test/foundry/unit/ExocoreGateway.t.sol:360-366
Timestamp: 2024-07-02T01:45:58.683Z
Learning: The `updateWhitelistedTokens` function in `ExocoreGateway` interacts solely with the trusted `ASSET_CONTRACT` precompile, mitigating the need for a reentrancy guard.
test/foundry/unit/ExocoreGateway.t.sol (1)
Learnt from: adu-web3
PR: ExocoreNetwork/exocore-contracts#39
File: test/foundry/unit/ExocoreGateway.t.sol:360-366
Timestamp: 2024-07-02T01:45:58.683Z
Learning: The `updateWhitelistedTokens` function in `ExocoreGateway` interacts solely with the trusted `ASSET_CONTRACT` precompile, mitigating the need for a reentrancy guard.
LanguageTool
docs/contracts-owner-manual.md

[uncategorized] ~20-~20: You might be missing the article “the” here.
Context: ...r contract. ## add or update tokens to whitelist Another important task before restakin...

(AI_EN_LECTOR_MISSING_DETERMINER_THE)


[uncategorized] ~22-~22: You might be missing the article “the” here.
Context: ...ing being activated is to add tokens to whitelist to mark them as stake-able on both Exoc...

(AI_EN_LECTOR_MISSING_DETERMINER_THE)

Additional comments not posted (25)
src/interfaces/IExocoreGateway.sol (1)

Line range hint 52-57:
LGTM! The function renaming is appropriate.

The renaming of addWhitelistTokens to addOrUpdateWhitelistTokens accurately reflects the combined functionality of adding and updating tokens.

test/mocks/AssetsMock.sol (2)

53-65: LGTM! The function renaming and return type update are appropriate.

The renaming of registerClientChain to registerOrUpdateClientChain and the updated return type accurately reflect the combined functionality and provide useful information about the operation's outcome.


68-84: LGTM! The function renaming and return type update are appropriate.

The renaming of registerToken to registerOrUpdateToken and the updated return type accurately reflect the combined functionality and provide useful information about the operation's outcome.

src/interfaces/precompiles/IAssets.sol (5)

20-26: LGTM! The parameter renaming improves clarity.

The renaming of clientChainLzID to clientChainID aligns with LayerZero's conventions and enhances the parameter's clarity.


32-39: LGTM! The parameter renaming improves clarity.

The renaming of clientChainLzID to clientChainID aligns with LayerZero's conventions and enhances the parameter's clarity.


45-56: LGTM! The function renaming and return type update are appropriate.

The renaming of registerClientChain to registerOrUpdateClientChain and the updated return type accurately reflect the combined functionality and provide useful information about the operation's outcome.


58-77: LGTM! The function renaming and return type update are appropriate.

The renaming of registerToken to registerOrUpdateToken and the updated return type accurately reflect the combined functionality and provide useful information about the operation's outcome.


79-81: No changes required.

The function getClientChains remains unchanged and does not require any modifications.

script/3_Setup.s.sol (1)

121-121: LGTM! But verify the function usage in the codebase.

The code changes are approved.

However, ensure that all function calls to addOrUpdateWhitelistTokens match the new functionality.

Verification successful

Function usage verified!

The function addOrUpdateWhitelistTokens is used consistently with the new functionality across the codebase.

  • Multiple instances of the function call with {value: nativeFee}.
  • Multiple instances of the function call with parameters clientChainId, whitelistTokens, decimals, tvlLimits, names, metaData.
Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Verify all function calls to `addOrUpdateWhitelistTokens` match the new functionality.

# Test: Search for the function usage. Expect: Only occurrences of the new function name.
rg --type solidity -A 5 $'addOrUpdateWhitelistTokens'

Length of output: 85


Script:

#!/bin/bash
# Description: Verify all function calls to `addOrUpdateWhitelistTokens` match the new functionality.

# Find all Solidity files and search for the function usage within those files.
fd -e sol -x rg 'addOrUpdateWhitelistTokens' {}

Length of output: 1730

src/libraries/Errors.sol (1)

Line range hint 1-1:
LGTM! But verify the error handling logic in the codebase.

The code changes are approved.

However, ensure that the removal of ExocoreGatewayNotRegisteredClientChainId is consistent with the updated error handling logic.

Verification successful

The removal of ExocoreGatewayNotRegisteredClientChainId is consistent with the updated error handling logic. No occurrences of this error were found in the codebase.

Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Verify the removal of `ExocoreGatewayNotRegisteredClientChainId` is consistent with the updated error handling logic.

# Test: Search for the error usage. Expect: No occurrences of the removed error.
rg --type solidity -A 5 $'ExocoreGatewayNotRegisteredClientChainId'

Length of output: 99


Script:

#!/bin/bash
# Description: Verify the removal of `ExocoreGatewayNotRegisteredClientChainId` is consistent with the updated error handling logic.

# Test: Search for the error usage. Expect: No occurrences of the removed error.
rg -A 5 'ExocoreGatewayNotRegisteredClientChainId'

Length of output: 50

src/storage/ExocoreGatewayStorage.sol (3)

Line range hint 1-1:
Verify the impact of removing isRegisteredClientChain.

The removal of the isRegisteredClientChain mapping aligns with the PR objective of using precompiles as the single source of truth. Ensure that all references to this mapping are updated accordingly.

Verification successful

Verification successful: No references to isRegisteredClientChain found.

The removal of the isRegisteredClientChain mapping aligns with the PR objective of using precompiles as the single source of truth. All references to this mapping have been successfully removed or updated.

Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Verify all references to `isRegisteredClientChain` have been removed or updated.

# Test: Search for the mapping usage. Expect: No occurrences of `isRegisteredClientChain`.
rg --type solidity -A 5 $'isRegisteredClientChain'

Length of output: 82


Script:

#!/bin/bash
# Description: Verify all references to `isRegisteredClientChain` have been removed or updated.

# Test: Search for the mapping usage. Expect: No occurrences of `isRegisteredClientChain`.
rg --type-add 'solidity:*.sol' -A 5 'isRegisteredClientChain'

Length of output: 61


Line range hint 1-1:
Verify the impact of removing ClientChainIDNotRegisteredBefore error declaration.

The removal of the ClientChainIDNotRegisteredBefore error declaration aligns with the PR objective of using precompiles as the single source of truth. Ensure that all references to this error are updated accordingly.

Verification successful

Verification successful: The removal of the ClientChainIDNotRegisteredBefore error declaration has been confirmed. No references to this error were found in the codebase, aligning with the PR objective of using precompiles as the single source of truth.

Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Verify all references to `ClientChainIDNotRegisteredBefore` have been removed or updated.

# Test: Search for the error usage. Expect: No occurrences of `ClientChainIDNotRegisteredBefore`.
rg --type solidity -A 5 $'ClientChainIDNotRegisteredBefore'

Length of output: 91


Script:

#!/bin/bash
# Description: Verify all references to `ClientChainIDNotRegisteredBefore` have been removed or updated.

# Find all Solidity files and search for the error usage. Expect: No occurrences of `ClientChainIDNotRegisteredBefore`.
fd -e sol -x rg 'ClientChainIDNotRegisteredBefore' {}

Length of output: 55


Line range hint 1-1:
Verify the impact of removing isWhitelistedToken.

The removal of the isWhitelistedToken mapping aligns with the PR objective of using precompiles as the single source of truth. Ensure that all references to this mapping are updated accordingly.

test/mocks/ExocoreGatewayMock.sol (4)

246-246: Verify function name change and functionality for _registerOrUpdateClientChain.

The function _registerClientChain has been renamed to _registerOrUpdateClientChain, reflecting its new capability to both register and update client chains. Ensure that the function name change is consistent throughout the codebase and that the new functionality is correctly implemented.

Verification successful

Function name change verified for _registerOrUpdateClientChain.

The function _registerClientChain has been successfully renamed to _registerOrUpdateClientChain throughout the codebase, and the new functionality is correctly referenced in the relevant files.

  • test/mocks/ExocoreGatewayMock.sol
  • src/core/ExocoreGateway.sol
Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Verify all references to `_registerClientChain` have been updated to `_registerOrUpdateClientChain`.

# Test: Search for the function usage. Expect: No occurrences of `_registerClientChain`.
rg --type solidity -A 5 $'_registerClientChain'

Length of output: 79


Script:

#!/bin/bash
# Description: Verify all references to `_registerClientChain` have been updated to `_registerOrUpdateClientChain`.

# Test: Search for the function usage. Expect: No occurrences of `_registerClientChain`.
rg '_registerClientChain'

# Test: Search for the new function usage to ensure it is implemented correctly.
rg '_registerOrUpdateClientChain'

Length of output: 497


202-205: Verify control flow and event emissions in addOrUpdateWhitelistTokens.

The addOrUpdateWhitelistTokens function now emits WhitelistTokenAdded if a token was newly added, or WhitelistTokenUpdated if it was updated. Ensure that the control flow correctly differentiates between newly added and updated tokens.

Verification successful

Control flow and event emissions in addOrUpdateWhitelistTokens are correctly implemented.

The function correctly differentiates between newly added and updated tokens and emits the appropriate events based on the success and updated flags.

  • test/mocks/ExocoreGatewayMock.sol lines 202-205
Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Verify the control flow and event emissions in `addOrUpdateWhitelistTokens`.

# Test: Search for the function implementation. Expect: Correct differentiation between newly added and updated tokens.
rg --type solidity -A 10 $'function addOrUpdateWhitelistTokens'

Length of output: 97


Script:

#!/bin/bash
# Description: Verify the control flow and event emissions in `addOrUpdateWhitelistTokens`.

# Test: Search for the function implementation. Expect: Correct differentiation between newly added and updated tokens.
rg -A 10 $'function addOrUpdateWhitelistTokens'

Length of output: 2194


Script:

#!/bin/bash
# Description: Extract the full implementation of the `addOrUpdateWhitelistTokens` function from `test/mocks/ExocoreGatewayMock.sol`.

# Test: Extract the function implementation. Expect: Correct differentiation between newly added and updated tokens.
rg -A 50 'function addOrUpdateWhitelistTokens' test/mocks/ExocoreGatewayMock.sol

Length of output: 2046


157-163: Verify control flow and event emissions in registerOrUpdateClientChain.

The registerOrUpdateClientChain function now emits ClientChainUpdated if the client chain was updated, or ClientChainRegistered if it was newly registered. Ensure that the control flow correctly differentiates between newly registered and updated client chains.

Verification successful

Verified control flow and event emissions in registerOrUpdateClientChain.

The registerOrUpdateClientChain function correctly differentiates between newly registered and updated client chains, and emits the appropriate events (ClientChainUpdated or ClientChainRegistered). The control flow is implemented as expected.

Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Verify the control flow and event emissions in `registerOrUpdateClientChain`.

# Test: Search for the function implementation. Expect: Correct differentiation between newly registered and updated client chains.
rg --type solidity -A 10 $'function registerOrUpdateClientChain'

Length of output: 98


Script:

#!/bin/bash
# Description: Verify the control flow and event emissions in `registerOrUpdateClientChain`.

# Test: Search for the function implementation in Solidity files.
fd -e sol -x rg 'function registerOrUpdateClientChain' -A 10 {}

Length of output: 2330


Script:

#!/bin/bash
# Description: Extract the full implementation of the `registerOrUpdateClientChain` function to verify control flow and event emissions.

# Test: Search for the full implementation of the `registerOrUpdateClientChain` function.
fd -e sol -x rg -A 50 'function registerOrUpdateClientChain' {}

Length of output: 8193


179-179: Verify function name change and functionality for addOrUpdateWhitelistTokens.

The function addWhitelistTokens has been renamed to addOrUpdateWhitelistTokens, reflecting its new capability to both add and update tokens. Ensure that the function name change is consistent throughout the codebase and that the new functionality is correctly implemented.

test/foundry/ExocoreDeployer.t.sol (1)

186-186: Verify function call change and functionality for addOrUpdateWhitelistTokens.

The function call to addWhitelistTokens has been replaced with addOrUpdateWhitelistTokens, suggesting an enhancement in functionality. Ensure that the function call change is consistent with the updated function name and that the new functionality is correctly utilized.

test/foundry/unit/ExoCapsule.t.sol (1)

Line range hint 144-144:
Removal of assertions may reduce test robustness.

The assertions checking validator.mostRecentBalanceUpdateTimestamp against validatorProof.beaconBlockTimestamp and validator.restakedBalanceGwei against the result of _getEffectiveBalance(validatorContainer) have been removed. This may reduce the robustness of the validation checks performed during the deposit proof verification process.

Ensure that the removal of these assertions does not impact the reliability of the contract's functionality.

src/core/ExocoreGateway.sol (3)

145-153: LGTM! Streamlined event emission logic.

The use of the updated flag to streamline the control flow and event emission logic is a good improvement. It simplifies the code and reduces redundancy.


171-215: LGTM! Enhanced input validation and event emission.

The restructuring of the addOrUpdateWhitelistTokens function to handle both adding and updating tokens is a good improvement. The added input validation and tracking of token registration success enhance the robustness of the function.


277-295: LGTM! Improved control flow with boolean return value.

The modification of _registerOrUpdateClientChain to return a boolean indicating whether the client chain was updated is a good improvement. It streamlines the control flow in the calling function.

test/foundry/unit/ExocoreGateway.t.sol (3)

Line range hint 360-366:
LGTM! Updated to use registerOrUpdateClientChain.

The function test_Success_RegisterClientChain has been successfully updated to use the new registerOrUpdateClientChain function.


Line range hint 368-373:
LGTM! Updated to use registerOrUpdateClientChain.

The function test_Success_UpdateClientChain has been successfully updated to use the new registerOrUpdateClientChain function.


624-624: LGTM! Updated to use addOrUpdateWhitelistTokens.

The function test_Success_AddWhiteListTokens has been successfully updated to use the new addOrUpdateWhitelistTokens function.

Copy link
Collaborator

@adu-web3 adu-web3 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

overall look good to me. I'm not sure if it's worthy to add some interface like isRegisteredClientChain for IAssets precompile

src/core/ExocoreGateway.sol Show resolved Hide resolved
Copy link
Contributor

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 0

Review details

Configuration used: CodeRabbit UI
Review profile: CHILL

Commits

Files that changed from the base of the PR and between 9c469d4 and c01c9a3.

Files selected for processing (6)
  • src/core/ExocoreGateway.sol (4 hunks)
  • src/interfaces/precompiles/IAssets.sol (1 hunks)
  • src/libraries/Errors.sol (1 hunks)
  • test/foundry/unit/ExocoreGateway.t.sol (14 hunks)
  • test/mocks/AssetsMock.sol (2 hunks)
  • test/mocks/ExocoreGatewayMock.sol (4 hunks)
Files skipped from review as they are similar to previous changes (2)
  • src/interfaces/precompiles/IAssets.sol
  • src/libraries/Errors.sol
Additional context used
Learnings (3)
test/mocks/ExocoreGatewayMock.sol (2)
Learnt from: adu-web3
PR: ExocoreNetwork/exocore-contracts#23
File: test/mocks/ExocoreGatewayMock.sol:0-0
Timestamp: 2024-06-17T07:43:43.986Z
Learning: User adu-web3 suggests that the `chainToBootstrapped[clientChainId]` marking in `ExocoreGatewayMock.sol` has no significant effects beyond setting a state and that synchronization issues are currently not a concern. They are open to implementing a response check in the future if necessary.
Learnt from: adu-web3
PR: ExocoreNetwork/exocore-contracts#39
File: test/foundry/unit/ExocoreGateway.t.sol:360-366
Timestamp: 2024-07-02T01:45:58.683Z
Learning: The `updateWhitelistedTokens` function in `ExocoreGateway` interacts solely with the trusted `ASSET_CONTRACT` precompile, mitigating the need for a reentrancy guard.
src/core/ExocoreGateway.sol (1)
Learnt from: adu-web3
PR: ExocoreNetwork/exocore-contracts#39
File: test/foundry/unit/ExocoreGateway.t.sol:360-366
Timestamp: 2024-07-02T01:45:58.683Z
Learning: The `updateWhitelistedTokens` function in `ExocoreGateway` interacts solely with the trusted `ASSET_CONTRACT` precompile, mitigating the need for a reentrancy guard.
test/foundry/unit/ExocoreGateway.t.sol (1)
Learnt from: adu-web3
PR: ExocoreNetwork/exocore-contracts#39
File: test/foundry/unit/ExocoreGateway.t.sol:360-366
Timestamp: 2024-07-02T01:45:58.683Z
Learning: The `updateWhitelistedTokens` function in `ExocoreGateway` interacts solely with the trusted `ASSET_CONTRACT` precompile, mitigating the need for a reentrancy guard.
Additional comments not posted (17)
test/mocks/AssetsMock.sol (3)

99-101: LGTM!

The code changes are approved.


53-65: LGTM! But verify the function usage in the codebase.

The code changes are approved.

However, ensure that all function calls to registerOrUpdateClientChain match the new signature.


68-84: LGTM! But verify the function usage in the codebase.

The code changes are approved.

However, ensure that all function calls to registerOrUpdateTokens match the new signature.

Verification successful

LGTM! But verify the function usage in the codebase.

The code changes are approved.

All function calls to registerOrUpdateTokens match the new signature.

Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Verify all function calls to `registerOrUpdateTokens` match the new signature.

# Test: Search for the function usage. Expect: Only occurrences of the new signature.
rg --type solidity -A 5 $'registerOrUpdateTokens'

Length of output: 81


Script:

#!/bin/bash
# Description: Verify all function calls to `registerOrUpdateTokens` match the new signature.

# Find all Solidity files
fd -e sol -e solidity -x rg 'registerOrUpdateTokens' {} +

Length of output: 3942


Script:

#!/bin/bash
# Description: Verify the context of `registerOrUpdateTokens` function calls to ensure they match the new signature.

# Check the context of the function call in `test/mocks/ExocoreGatewayMock.sol`
rg --type solidity -A 5 'registerOrUpdateTokens' test/mocks/ExocoreGatewayMock.sol

# Check the context of the function call in `src/core/ExocoreGateway.sol`
rg --type solidity -A 5 'registerOrUpdateTokens' src/core/ExocoreGateway.sol

# Check the context of the function declaration in `src/interfaces/precompiles/IAssets.sol`
rg --type solidity -A 5 'registerOrUpdateTokens' src/interfaces/precompiles/IAssets.sol

Length of output: 346


Script:

#!/bin/bash
# Description: Verify the context of `registerOrUpdateTokens` function calls to ensure they match the new signature.

# Check the context of the function call in `test/mocks/ExocoreGatewayMock.sol`
rg -A 5 'registerOrUpdateTokens' test/mocks/ExocoreGatewayMock.sol

# Check the context of the function call in `src/core/ExocoreGateway.sol`
rg -A 5 'registerOrUpdateTokens' src/core/ExocoreGateway.sol

# Check the context of the function declaration in `src/interfaces/precompiles/IAssets.sol`
rg -A 5 'registerOrUpdateTokens' src/interfaces/precompiles/IAssets.sol

Length of output: 890

test/mocks/ExocoreGatewayMock.sol (3)

258-270: LGTM!

The code changes are approved.


181-220: LGTM! But verify the function usage in the codebase.

The code changes are approved.

However, ensure that all function calls to addOrUpdateWhitelistTokens match the new signature.


158-164: LGTM! But verify the function usage in the codebase.

The code changes are approved.

However, ensure that all function calls to registerOrUpdateClientChain match the new signature.

Verification successful

LGTM! But verify the function usage in the codebase.

The code changes are approved.

However, ensure that all function calls to registerOrUpdateClientChain match the new signature. The provided context shows that the new signature is being used correctly in the codebase.

Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Verify all function calls to `registerOrUpdateClientChain` match the new signature.

# Test: Search for the function usage. Expect: Only occurrences of the new signature.
rg --type solidity -A 5 $'registerOrUpdateClientChain'

Length of output: 86


Script:

#!/bin/bash
# Description: Verify all function calls to `registerOrUpdateClientChain` match the new signature.

# Find all Solidity files and search for the function usage within them.
fd -e sol -x rg 'registerOrUpdateClientChain' {}

Length of output: 1708


Script:

#!/bin/bash
# Description: Verify all function calls to `registerOrUpdateClientChain` match the new signature.

# Find all Solidity files and search for the function usage within them, displaying context around each match.
fd -e sol -x rg 'registerOrUpdateClientChain' -A 5 -B 5 {}

Length of output: 11543

src/core/ExocoreGateway.sol (3)

303-315: LGTM!

The code changes are approved.


146-153: LGTM! But verify the function usage in the codebase.

The code changes are approved.

However, ensure that all function calls to registerOrUpdateClientChain match the new signature.

Verification successful

Verification Successful!

The function calls to registerOrUpdateClientChain match the new signature across the codebase.

  • All instances of registerOrUpdateClientChain adhere to the new signature.
Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Verify all function calls to `registerOrUpdateClientChain` match the new signature.

# Test: Search for the function usage. Expect: Only occurrences of the new signature.
rg --type solidity -A 5 $'registerOrUpdateClientChain'

Length of output: 86


Script:

#!/bin/bash
# Description: Verify all function calls to `registerOrUpdateClientChain` match the new signature.

# Find all Solidity files and search for the function usage.
fd -e sol -x rg 'registerOrUpdateClientChain' {}

Length of output: 1708


Script:

#!/bin/bash
# Description: Verify all function calls to `registerOrUpdateClientChain` match the new signature.

# Find all Solidity files and search for the function usage with more context lines.
fd -e sol -x rg -A 10 -B 2 'registerOrUpdateClientChain' {}

Length of output: 12418


175-220: LGTM! But verify the function usage in the codebase.

The code changes are approved.

However, ensure that all function calls to addOrUpdateWhitelistTokens match the new signature.

Verification successful

Function usage verified.

All instances of addOrUpdateWhitelistTokens match the new function signature.

Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Verify all function calls to `addOrUpdateWhitelistTokens` match the new signature.

# Test: Search for the function usage. Expect: Only occurrences of the new signature.
rg --type solidity -A 5 $'addOrUpdateWhitelistTokens'

Length of output: 85


Script:

#!/bin/bash
# Description: Verify all function calls to `addOrUpdateWhitelistTokens` match the new signature.

# Find all Solidity files and search for the function usage within those files.
fd -e sol -x rg 'addOrUpdateWhitelistTokens' {}

Length of output: 1730


Script:

#!/bin/bash
# Description: Verify all function calls to `addOrUpdateWhitelistTokens` match the new signature with context.

# Find all Solidity files and search for the function usage within those files, including more context lines.
fd -e sol -x rg -A 10 'addOrUpdateWhitelistTokens' {}

Length of output: 8326

test/foundry/unit/ExocoreGateway.t.sol (8)

Line range hint 1-83: Ensure the setup supports new functionality.

The SetUp contract initializes the state for the tests. Ensure that the setup correctly supports the new functionality introduced by the renamed function addOrUpdateWhitelistTokens.


Line range hint 85-135: Ensure pause and unpause functionality works with new function.

The Pausable contract tests the pause and unpause functionality. Ensure that the pause and unpause functionality works correctly with the new function addOrUpdateWhitelistTokens.


Line range hint 137-283: Ensure message handling works with new function.

The LzReceive contract tests the message handling functionality. Ensure that the message handling works correctly with the new function addOrUpdateWhitelistTokens.


Line range hint 285-358: Ensure client chain registration and update works with new function.

The RegisterOrUpdateClientChain contract tests the client chain registration and update functionality. Ensure that the client chain registration and update functionality works correctly with the new function addOrUpdateWhitelistTokens.


Line range hint 360-405: Ensure peer setting works with new function.

The SetPeer contract tests the peer setting functionality. Ensure that the peer setting functionality works correctly with the new function addOrUpdateWhitelistTokens.


Line range hint 407-630: Ensure tests validate new functionality.

The AddWhitelistTokens contract contains tests for adding whitelist tokens. Ensure that these tests correctly validate the new functionality introduced by the renamed function addOrUpdateWhitelistTokens.


Line range hint 632-786: Ensure tests validate new functionality.

The UpdateWhitelistTokens contract contains tests for updating whitelist tokens. Ensure that these tests correctly validate the new functionality introduced by the renamed function addOrUpdateWhitelistTokens.


Line range hint 788-859: Ensure operator association works with new function.

The AssociateOperatorWithEVMStaker contract tests the operator association functionality. Ensure that the operator association functionality works correctly with the new function addOrUpdateWhitelistTokens.

After the precompiles for assets and client chains were merged, the
convoluted mechanism of calling the `getClientChains` function via the
selector is not necessary.
Copy link
Contributor

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 0

Review details

Configuration used: CodeRabbit UI
Review profile: CHILL

Commits

Files that changed from the base of the PR and between c01c9a3 and 88a6f96.

Files selected for processing (4)
  • src/core/ExocoreGateway.sol (5 hunks)
  • src/libraries/Errors.sol (1 hunks)
  • src/storage/ExocoreGatewayStorage.sol (3 hunks)
  • test/foundry/unit/ExocoreGateway.t.sol (15 hunks)
Files skipped from review as they are similar to previous changes (2)
  • src/libraries/Errors.sol
  • src/storage/ExocoreGatewayStorage.sol
Additional context used
Learnings (2)
src/core/ExocoreGateway.sol (1)
Learnt from: adu-web3
PR: ExocoreNetwork/exocore-contracts#39
File: test/foundry/unit/ExocoreGateway.t.sol:360-366
Timestamp: 2024-07-02T01:45:58.683Z
Learning: The `updateWhitelistedTokens` function in `ExocoreGateway` interacts solely with the trusted `ASSET_CONTRACT` precompile, mitigating the need for a reentrancy guard.
test/foundry/unit/ExocoreGateway.t.sol (1)
Learnt from: adu-web3
PR: ExocoreNetwork/exocore-contracts#39
File: test/foundry/unit/ExocoreGateway.t.sol:360-366
Timestamp: 2024-07-02T01:45:58.683Z
Learning: The `updateWhitelistedTokens` function in `ExocoreGateway` interacts solely with the trusted `ASSET_CONTRACT` precompile, mitigating the need for a reentrancy guard.
Additional comments not posted (15)
src/core/ExocoreGateway.sol (6)

111-121: Verify the bootstrap marking logic.

The function marks chains as bootstrapped upon sending an interchain message. Consider marking them only upon receiving a response to ensure reliability.


181-218: Ensure comprehensive testing for token management.

The function now handles both adding and updating tokens. Ensure that thorough tests cover all scenarios, including edge cases.


Line range hint 266-276:
LGTM! Ensure thorough testing of input validation.

The function now focuses on validating input lengths. Ensure that tests cover various input scenarios to confirm correctness.


301-313: LGTM! But verify the function usage in the codebase.

The code changes are approved. Ensure that all function calls to _registerOrUpdateClientChain are correctly implemented.

Verification successful

Function usage verified successfully.

The function _registerOrUpdateClientChain is correctly implemented in the codebase.

  • src/core/ExocoreGateway.sol
  • test/mocks/ExocoreGatewayMock.sol
Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Verify all function calls to `_registerOrUpdateClientChain` are correctly implemented.

# Test: Search for the function usage. Expect: Only occurrences of the new logic.
rg --type solidity -A 5 $'_registerOrUpdateClientChain'

Length of output: 87


Script:

#!/bin/bash
# Description: Verify all function calls to `_registerOrUpdateClientChain` are correctly implemented.

# Test: Search for the function usage. Expect: Only occurrences of the new logic.
rg '_registerOrUpdateClientChain' -A 5

Length of output: 1743


141-149: LGTM! But verify the function usage in the codebase.

The code changes are approved. Ensure that all function calls to registerOrUpdateClientChain match the new logic.

Verification successful

Let's re-run the verification using a different approach to locate the function usage in Solidity files.


To ensure the function calls match the new logic, let's extract the surrounding lines of each occurrence to verify the context.


Verified: The function calls to registerOrUpdateClientChain match the new logic.

The code changes are correctly implemented, and all occurrences of the function calls follow the updated pattern.

Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Verify all function calls to `registerOrUpdateClientChain` match the new logic.

# Test: Search for the function usage. Expect: Only occurrences of the new logic.
rg --type solidity -A 5 $'registerOrUpdateClientChain'

Length of output: 86


Script:

#!/bin/bash
# Description: Verify all function calls to `registerOrUpdateClientChain` match the new logic.

# Find all Solidity files and search for function usage within them.
fd -e sol -x rg 'registerOrUpdateClientChain' {}

Length of output: 1760


Script:

#!/bin/bash
# Description: Verify all function calls to `registerOrUpdateClientChain` match the new logic.

# Find all Solidity files and search for function usage within them, extracting surrounding lines for context.
fd -e sol -x rg -A 10 -B 10 'registerOrUpdateClientChain' {}

Length of output: 19017


164-168: LGTM! But verify the function usage in the codebase.

The code changes are approved. Ensure that all function calls to setPeer include the new registration check.

Verification successful

Function usage verified and includes the necessary registration check.

The setPeer function in src/core/ExocoreGateway.sol correctly includes the _validateClientChainIdRegistered check, ensuring that the client chain ID is validated before proceeding.

  • src/core/ExocoreGateway.sol: The _validateClientChainIdRegistered check is included in the setPeer function.
Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Verify all function calls to `setPeer` include the new registration check.

# Test: Search for the function usage. Expect: Only occurrences of the new logic.
rg --type solidity -A 5 $'setPeer'

Length of output: 66


Script:

#!/bin/bash
# Description: Verify all function calls to `setPeer` include the new registration check.

# Test: Search for the function usage. Expect: Only occurrences of the new logic.
rg 'setPeer' --glob '*.sol' -A 5

Length of output: 8438


Script:

#!/bin/bash
# Description: Verify that the `_validateClientChainIdRegistered` check is included in the `setPeer` function implementation.

# Test: Search for the `_validateClientChainIdRegistered` function call within the `setPeer` function in `src/core/ExocoreGateway.sol`.
rg '_validateClientChainIdRegistered' --glob 'src/core/ExocoreGateway.sol' -A 5

Length of output: 932

test/foundry/unit/ExocoreGateway.t.sol (9)

535-537: LGTM! Ensure comprehensive testing for ownership checks.

The test ensures that only the contract owner can call the addOrUpdateWhitelistTokens function. Ensure that similar tests cover other functions requiring ownership checks.


549-551: LGTM! Ensure comprehensive testing for paused state.

The test ensures that the addOrUpdateWhitelistTokens function cannot be called when the contract is paused. Ensure that similar tests cover other functions requiring the contract to be unpaused.


562-564: LGTM! Ensure comprehensive testing for input length.

The test ensures that the addOrUpdateWhitelistTokens function reverts when the token list is too long. Ensure that similar tests cover other functions requiring input length validation.


576-578: LGTM! Ensure comprehensive testing for input length matching.

The test ensures that the addOrUpdateWhitelistTokens function reverts when the input lengths do not match. Ensure that similar tests cover other functions requiring input length matching.


596-598: LGTM! Ensure comprehensive testing for zero address validation.

The test ensures that the addOrUpdateWhitelistTokens function reverts when a token address is zero. Ensure that similar tests cover other functions requiring zero address validation.


610-612: LGTM! Ensure comprehensive testing for TVL limit validation.

The test ensures that the addOrUpdateWhitelistTokens function reverts when a TVL limit is zero. Ensure that similar tests cover other functions requiring TVL limit validation.


630-632: LGTM! Ensure comprehensive testing for successful token addition.

The test ensures that the addOrUpdateWhitelistTokens function successfully adds tokens to the whitelist. Ensure that similar tests cover other functions requiring successful operation validation.


761-763: LGTM! Ensure comprehensive testing for successful token updates.

The test ensures that the addOrUpdateWhitelistTokens function successfully updates tokens in the whitelist. Ensure that similar tests cover other functions requiring successful operation validation.


783-785: LGTM! Ensure comprehensive testing for token addition logic.

The function now calls addOrUpdateWhitelistTokens to add tokens to the whitelist. Ensure that tests cover various scenarios to confirm correctness.

@adu-web3 adu-web3 added this pull request to the merge queue Jul 31, 2024
Merged via the queue into ExocoreNetwork:main with commit 9ef6371 Jul 31, 2024
6 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants