store relayer on relay [SLT-182] #3170
Conversation
WalkthroughThe Changes
Possibly related PRs
Suggested labels
Suggested reviewers
Poem
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
Documentation and Community
|
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## master #3170 +/- ##
===================================================
- Coverage 39.46606% 38.41907% -1.04700%
===================================================
Files 479 424 -55
Lines 26932 24454 -2478
Branches 342 147 -195
===================================================
- Hits 10629 9395 -1234
+ Misses 15557 14318 -1239
+ Partials 746 741 -5
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. |
![github-advanced-security[bot]](https://avatars.githubusercontent.com/in/57789?s=60&v=4){kind=small}
Deploying sanguine-fe with
|
| Latest commit: |
caa01ec
|
| Status: | ✅ Deploy successful! |
| Preview URL: | https://7bf9c4dd.sanguine-fe.pages.dev |
| Branch Preview URL: | https://feat-fbv2-storerelayeronrela.sanguine-fe.pages.dev |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 0
Outside diff range and nitpick comments (2)
packages/contracts-rfq/contracts/interfaces/IFastBridgeV2.sol (1)
28-32: LGTM: NewBridgeRelaystruct efficiently stores relayer informationThe
BridgeRelaystruct is well-designed and aligns with the PR objectives. It efficiently packs the block number, timestamp, and relayer address into a single 32-byte slot.Consider adding a brief comment above the struct to explain its purpose, similar to the documentation provided for the
bridgeRelaysfunction. For example:/// @notice Stores information about a bridge relay transaction struct BridgeRelay { uint48 blockNumber; uint48 blockTimestamp; address relayer; }packages/contracts-rfq/contracts/FastBridgeV2.sol (1)
142-148: Ensure safe casting when storing block numbers and timestampsCasting
block.numberandblock.timestamptouint48saves storage space, but please ensure that these values won't exceeduint48limits in the future. While unlikely, consider documenting the rationale or adding safeguards.
Review details
Configuration used: .coderabbit.yaml
Review profile: CHILL
Files selected for processing (2)
- packages/contracts-rfq/contracts/FastBridgeV2.sol (3 hunks)
- packages/contracts-rfq/contracts/interfaces/IFastBridgeV2.sol (1 hunks)
Additional context used
GitHub Check: Slither
packages/contracts-rfq/contracts/FastBridgeV2.sol
[notice] 183-186: Block timestamp
FastBridgeV2.bridgeRelays(bytes32) (contracts/FastBridgeV2.sol#183-186) uses timestamp for comparisons
Dangerous comparisons:
- bridgeRelayDetails[transactionId].blockNumber != 0 (contracts/FastBridgeV2.sol#185)
Additional comments not posted (4)
packages/contracts-rfq/contracts/interfaces/IFastBridgeV2.sol (2)
23-26: LGTM: NewbridgeRelaysfunction aligns with PR objectivesThe added
bridgeRelaysfunction is well-implemented and documented. It provides a backwards-compatible view function as mentioned in the PR objectives, allowing users to check if a specific transaction has been relayed.
23-32: Summary: Changes effectively implement PR objectivesThe additions to the
IFastBridgeV2interface successfully implement the PR objectives. The newbridgeRelaysfunction provides a backwards-compatible way to check if a transaction has been relayed, while theBridgeRelaystruct efficiently stores relayer information on-chain. These changes will improve the reliability of relayer data and facilitate custom logic related to block confirmations for Guards and Relayers.packages/contracts-rfq/contracts/FastBridgeV2.sol (2)
38-39: LGTM: Addition ofbridgeRelayDetailsmappingThe new mapping
bridgeRelayDetailscorrectly introduces storage for relay details on the destination chain.
183-186: LGTM: Backwards-compatiblebridgeRelaysfunctionThe
bridgeRelaysfunction maintains backwards compatibility by providing a boolean relay status. The implementation is correct.Tools
GitHub Check: Slither
[notice] 183-186: Block timestamp
FastBridgeV2.bridgeRelays(bytes32) (contracts/FastBridgeV2.sol#183-186) uses timestamp for comparisons
Dangerous comparisons:
- bridgeRelayDetails[transactionId].blockNumber != 0 (contracts/FastBridgeV2.sol#185)
| @@ -139,8 +139,13 @@ contract FastBridgeV2 is Admin, IFastBridgeV2 { | |||
| if (block.timestamp > transaction.deadline) revert DeadlineExceeded(); | |||
|
|
|||
| // mark bridge transaction as relayed | |||
| if (bridgeRelays[transactionId]) revert TransactionRelayed(); | |||
| bridgeRelays[transactionId] = true; | |||
| if (bridgeRelayDetails[transactionId].blockNumber != 0) revert TransactionRelayed(); | |||
There was a problem hiding this comment.
To avoid repetition, let's make bridgeRelays(bytes32) a public view - will make it easier to maintain later on.
| @@ -20,4 +20,15 @@ interface IFastBridgeV2 is IFastBridge { | |||
| /// @param request The encoded bridge transaction to claim on origin chain | |||
| function claim(bytes memory request) external; | |||
|
|
|||
| /// @notice Checks if a transaction has been relayed | |||
There was a problem hiding this comment.
Needs forge fmt + in general we try to define the structs at the top of the contract, prior to the functions. In hindsight, both of these should've been flagged by CI workflows - I will make a ticket to update these with a reasonable settings (e.g. older FastBridge has a ton of linter warnings that might as well be ignored at this point)
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Outside diff range and nitpick comments (3)
packages/contracts-rfq/test/FastBridgeV2.Dst.t.sol (1)
118-132: LGTM: New test function correctly verifies block data storage.The
test_relay_eth_withRelayerAddress_checkBlockDatafunction effectively tests the new functionality of storing block number and timestamp during relay operations. It aligns well with the PR objectives.A minor suggestion for improvement:
Consider adding an assertion to verify the stored relayer address:
(uint48 recordedBlockNumber, uint48 recordedblockTimestamp,) = fastBridge.bridgeRelayDetails(txId); assertEq(recordedBlockNumber, 987_654_321); assertEq(recordedblockTimestamp, 123_456_789); +assertEq(fastBridge.bridgeRelayDetails(txId).relayer, address(relayerA)); assertEq(address(userB).balance, ethParams.destAmount);This would ensure that the relayer address is correctly stored along with the block data.
packages/contracts-rfq/contracts/FastBridgeV2.sol (2)
134-146: Enhanced relay function with improved data storageThe updates to the
relayfunction effectively implement the PR objectives:
- The zero address check for the relayer improves security.
- The relay status check now uses the new
bridgeRelayDetailsmapping.- Detailed relay information (block number, timestamp, and relayer address) is now stored, enhancing on-chain data accessibility.
These changes align well with the goal of improving reliability and providing more comprehensive information for Guards and Relayers.
Consider using OpenZeppelin's
block.timestampandblock.numberwrappers for improved readability and gas optimization:-BridgeRelay({blockNumber: uint48(block.number), blockTimestamp: uint48(block.timestamp), relayer: relayer}); +BridgeRelay({blockNumber: uint48(_blockNumber()), blockTimestamp: uint48(_timestamp()), relayer: relayer});
180-185: Backwards-compatible bridgeRelays function addedThe new
bridgeRelaysfunction successfully maintains backwards compatibility while leveraging the enhanced data structure. This aligns with the PR objectives and ensures a smooth transition for existing integrations.Consider using a more gas-efficient approach by directly returning the comparison result:
-function bridgeRelays(bytes32 transactionId) public view returns (bool) { - // has this transactionId been relayed? - return bridgeRelayDetails[transactionId].relayer != address(0); -} +function bridgeRelays(bytes32 transactionId) public view returns (bool) { + return bridgeRelayDetails[transactionId].relayer != address(0); +}This change eliminates the need for an intermediate boolean variable and reduces gas costs.
📜 Review details
Configuration used: .coderabbit.yaml
Review profile: CHILL
📒 Files selected for processing (3)
- packages/contracts-rfq/contracts/FastBridgeV2.sol (3 hunks)
- packages/contracts-rfq/contracts/interfaces/IFastBridgeV2.sol (1 hunks)
- packages/contracts-rfq/test/FastBridgeV2.Dst.t.sol (3 hunks)
🚧 Files skipped from review as they are similar to previous changes (1)
- packages/contracts-rfq/contracts/interfaces/IFastBridgeV2.sol
🔇 Additional comments not posted (5)
packages/contracts-rfq/test/FastBridgeV2.Dst.t.sol (3)
4-4: LGTM: Import statement updated correctly.The import statement has been appropriately updated to include the
ZeroAddresserror. This addition aligns with the PR objectives and prepares for its usage in the new tests.
171-174: LGTM: New test function correctly verifies zero address rejection.The
test_relay_withRelayerAddress_revert_zeroAddrfunction effectively tests that the contract rejects relay attempts with a zero address as the relayer. This is an important edge case to cover and aligns with best practices for input validation.
Line range hint
1-174: Summary: Changes align well with PR objectives and improve test coverage.The modifications to this test file effectively cover the new functionality described in the PR objectives:
- The import statement has been updated to include the new
ZeroAddresserror.- A new test function verifies the storage of block number and timestamp during relay operations.
- Another test function ensures that relaying with a zero address is properly rejected.
These changes provide good coverage for the new features and edge cases related to storing relayer addresses and associated block data. The tests align well with the goal of enhancing the
FastBridgecontract's functionality and reliability.packages/contracts-rfq/contracts/FastBridgeV2.sol (2)
38-39: Improved relay details storageThe introduction of
bridgeRelayDetailsmapping enhances the contract's ability to store comprehensive information about each relay transaction. This change aligns well with the PR objectives and provides better on-chain data accessibility for Guards and Relayers.
134-146: Implemented suggestions and testing reminderGreat job implementing the suggested changes:
- The
bridgeRelays(bytes32)function is now a public view function.- A check for
relayer == address(0)has been added to therelayfunction.To ensure the robustness of these changes, please add unit tests covering the following scenarios:
- The
relayer == address(0)case in therelayfunction.- The new
bridgeRelays(bytes32)function behavior.You can use the following script to check for existing tests:
#!/bin/bash # Description: Check for existing tests related to the new changes # Test: Search for tests related to relay function and bridgeRelays rg --type solidity -i '(test|it).*(relay|bridgeRelays)' test/Also applies to: 180-185
Bundle ReportChanges will increase total bundle size by 251.65kB (0.7%) ⬆️. This is within the configured threshold ✅ Detailed changes
|
| bytes32 transactionId = keccak256(request); | ||
| BridgeTransaction memory transaction = getBridgeTransaction(request); | ||
| if (transaction.destChainId != uint32(block.chainid)) revert ChainIncorrect(); | ||
|
|
||
| // check haven't exceeded deadline for relay to happen | ||
| if (block.timestamp > transaction.deadline) revert DeadlineExceeded(); | ||
|
|
||
| if (bridgeRelayDetails[transactionId].relayer != address(0)) revert TransactionRelayed(); |
There was a problem hiding this comment.
The idea was to utilise the public view here, so that in the event we want/need to update it, we won't end up with outdated check here
| if (bridgeRelayDetails[transactionId].relayer != address(0)) revert TransactionRelayed(); | |
| if (bridgeRelays(transactionId)) revert TransactionRelayed(); |
github-actions
bot
added
size/xs
and removed
size/s
needs-go-generate-agents
needs-go-generate-services/rfq
needs-yarn-install
labels
Changes to gas cost
🧾 Summary (50% most significant diffs)
Full diff report 👇
|
Description
FastBridgecontract doesn’t save the Relayer address, who calledrelay()on the destination chain, which leaves the emitted logs as the only source of truth for this information. This makes the Guard/Relayer implementations a bit more fragile, as opposed to the situation where this information could’ve been read on-chain.This change could be implemented without any additional gas costs by saving the relevant relayer information instead of a single bool flag in
bridgeRelays.block.number, block.timestamp, relayerused for completing therelay()bridgeRelaysmapping.bridgeRelays(bytes32)view.NOTE: decided to not build a more integrator-friendly view that returns a struct of bridgeRelayDetails as opposed to default tuple -- this keeps it consistent with our other mappings.
Summary by CodeRabbit
New Features
Bug Fixes