-
Notifications
You must be signed in to change notification settings - Fork 26
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
fix typo in chainId -> chainID in crossl2 prover #293
Conversation
Warning There were issues while running some tools. Please review the errors and either fix the tool’s configuration or disable the tool if it’s a critical failure. 🔧 eslint
src/evm/contracts/CrossL2Prover.ts(node:10437) [MODULE_TYPELESS_PACKAGE_JSON] Warning: Module type of file:///eslint.config.js?mtime=1734521317918 is not specified and it doesn't parse as CommonJS. Oops! Something went wrong! :( ESLint: 8.57.1 TypeError: Key "rules": Key "@typescript-eslint/quotes": Could not find "quotes" in plugin "@typescript-eslint". Did you mean "@/quotes"? WalkthroughThis pull request introduces significant changes to multiple contracts and their Go and TypeScript bindings, primarily focusing on modifying the data types for chain identifiers from Changes
Possibly related PRs
Suggested Reviewers
Poem
Tip CodeRabbit's docstrings feature is now available as part of our Early Access Program! Simply use the command 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 (
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actionable comments posted: 1
🔭 Outside diff range comments (2)
bindings/go/crossl2prover/CrossL2Prover.go (1)
Inconsistency found in interface documentation
The interface file
contracts/interfaces/ICrossL2Prover.sol
has a documentation comment that uses "chainID" while the actual function signature uses "chainId". The comment should be updated to maintain consistency with the implementation.
contracts/interfaces/ICrossL2Prover.sol
: Update the@return chainId
documentation to use "chainId" instead of "chainID" in the description.🔗 Analysis chain
Line range hint
329-349
: Confirm correct usage of 'chainId' instead of 'chainID'.The function's Solidity signature and Go binding now use "chainId" consistently. This matches the PR objective of aligning naming. Ensure other parts of the codebase that consume this method are updated to the new name, if any references existed to the older "chainID".
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Verify no references to 'chainID' remain in the repo rg 'chainID'Length of output: 121
Script:
#!/bin/bash # Let's check the full context of the interface definition to understand if this is a comment or actual code rg -A 10 'chainId The chainID' contracts/interfaces/ICrossL2Prover.solLength of output: 764
src/evm/contracts/Venus.ts (1)
Line range hint
85-91
: Type change: BytesLike to string for chain IDsThe type change from
BytesLike
tostring
forsrcChainId
could affect data validation and encoding. Ensure that:
- All consumers can handle string chain IDs
- The string format is well-defined and validated
- No data loss occurs during type conversion
Consider adding input validation for the string format to prevent invalid chain IDs.
🧹 Nitpick comments (2)
bindings/go/crossl2prover/CrossL2Prover.go (1)
384-396
: Check for potential string-based vulnerabilities or large data usage.While changing from bytes32 to string for chain identifiers can be more readable or flexible, it may lead to higher gas usage when storing or handling chain IDs. Consider whether a length-limited approach or standardized representation (e.g., a struct or fixed-length bytes) might be more optimal.
contracts/examples/Venus.sol (1)
89-91
: Review string comparison implementationThe use of
Bytes.equal
for string comparison is correct but consider adding a helper function for chain ID comparison if this pattern is used frequently.+ function compareChainIds(string memory a, string memory b) internal pure returns (bool) { + return Bytes.equal(bytes(a), bytes(b)); + }Also applies to: 120-121
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (12)
bindings/go/crossl2prover/CrossL2Prover.go
(7 hunks)bindings/go/icrossl2prover/ICrossL2Prover.go
(8 hunks)bindings/go/venus/Venus.go
(6 hunks)contracts/core/proofAPI/CrossL2Prover.sol
(2 hunks)contracts/examples/Venus.sol
(5 hunks)contracts/interfaces/ICrossL2Prover.sol
(2 hunks)package.json
(1 hunks)src/evm/contracts/CrossL2Prover.ts
(2 hunks)src/evm/contracts/Venus.ts
(5 hunks)src/evm/contracts/factories/CrossL2Prover__factory.ts
(3 hunks)src/evm/contracts/factories/ICrossL2Prover__factory.ts
(2 hunks)src/evm/contracts/factories/Venus__factory.ts
(6 hunks)
✅ Files skipped from review due to trivial changes (1)
- package.json
🔇 Additional comments (19)
bindings/go/crossl2prover/CrossL2Prover.go (1)
54-54
: ABI consistency check.
The ABI string at line 54 reflects the updated return types (e.g., "chainId" as a string) for the contract methods. This matches the rest of the code changes in this file, ensuring the Go bindings are correctly synchronized with Solidity.
bindings/go/venus/Venus.go (4)
34-34
: ABI alignment for 'chainId' representation.
At line 34, the ABI references to "_chainId" as a string are correctly reflected in the rest of the methods. No leftover references to "chainID" detected here.
185-210
: String-based chainId return type.
The functions at lines 185-210 consistently return chainId as a string. This change is in line with the updated interface. Confirm that any client code dealing with chain ID values still works correctly now that it’s a dynamic string rather than a fixed type.
318-336
: Extended parameters for 'receiveTransmissionEvent'.
The addition of the 'expectedEmitter' address parameter at lines 318-336 replaces the removed “counterParty” usage. Confirm upstream calls consistently provide the new parameter.
[approve]
408-408
: Event log updates to string-based SrcChainId.
The "SuccessfulReceipt" event now includes "srcChainId" as a string at line 408. All filter/watch/parse methods at lines 413+, 462+ are updated accordingly. This is consistent with the broader shift away from bytes32.
Also applies to: 413-427, 462-464
src/evm/contracts/factories/ICrossL2Prover__factory.ts (2)
85-86
: Renamed output to string-based chainId.
The outputs now reflect "chainId" as "string" instead of bytes32. This fix implements the PR objective of correcting the variable name and type.
119-120
: Changed srcChainId field to string.
The shift from bytes32 → string for srcChainId here is consistent with the CrossL2Prover changes. Confirm no leftover references to the old type remain in the TypeScript codebase.
✅ Verification successful
Let me search for more specific references to srcChainId in TypeScript files.
Let me try one more search to be thorough, using a different ripgrep approach:
Type change from bytes32 to string is consistently applied
Based on the comprehensive search results, all references to srcChainId
in the TypeScript codebase are using the string
type. The change has been properly propagated across all relevant files including Venus.ts, ICrossL2Prover.ts, and their respective factory files. No leftover references to the old bytes32 type were found.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Checks for references to 'srcChainId' as bytes32 in TS code
rg 'srcChainId.*bytes32'
Length of output: 3434
Script:
#!/bin/bash
# Search for srcChainId in TypeScript files specifically
rg -t typescript 'srcChainId'
# Also check for any interface or type definitions that might reference srcChainId
ast-grep --pattern 'interface $_ {
$$$
srcChainId
$$$
}'
Length of output: 335
Script:
#!/bin/bash
# Search in all files with common TypeScript/JavaScript extensions
rg -g '*.{ts,tsx,js,jsx}' 'srcChainId'
# Also check for any type annotations with bytes32
rg -g '*.{ts,tsx}' 'srcChainId.*:.*bytes'
Length of output: 696
contracts/interfaces/ICrossL2Prover.sol (2)
69-69
: Changed return type for srcChainId in validateReceipt.
Returning srcChainId as a string aligns with the rest of the codebase updates. Make sure any domain logic expecting a 32-byte value is updated accordingly.
87-87
: Renamed chainId in validateEvent.
The function’s return type is now “string memory chainId,” fixing the mismatch. This similarly addresses the original issue of chainID vs chainId.
contracts/core/proofAPI/CrossL2Prover.sol (2)
Line range hint 84-88
: Ensure consistent chain ID validation across the codebase
The change to string type for chain IDs should be consistently applied across all contracts and interfaces.
Line range hint 50-78
: Consider the performance implications of using string for chain IDs
While changing from bytes32
to string
improves readability, it increases gas costs due to dynamic memory allocation and string comparison operations. Consider documenting any performance impact and standardizing the chain ID format.
contracts/examples/Venus.sol (2)
32-32
: Verify the impact of removing counterParty variable
The removal of the counterParty variable and change to string chainId requires careful verification of all dependent contracts.
Also applies to: 40-40
114-124
: Validate expectedEmitter parameter thoroughly
The addition of expectedEmitter parameter improves security but ensure all calling contracts are updated accordingly.
✅ Verification successful
Let me search for any actual implementations or calls to this function in the codebase to ensure we have a complete picture.
Let me check the content of these test files to see how the function is being used.
Let me try a broader search to find any references to this function, including potential interface definitions or inheritance.
Based on the search results, I can now provide the final response:
No external callers found - parameter addition is safe
The receiveTransmissionEvent
function appears to be newly introduced or only defined in the Venus contract itself, with no existing calls found in the Solidity codebase. The Go bindings are auto-generated and will be updated accordingly. The addition of the expectedEmitter
parameter is safe to proceed with.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Check for existing calls to receiveTransmissionEvent
rg -A 2 'receiveTransmissionEvent\('
Length of output: 1846
Script:
#!/bin/bash
# Search for actual calls or implementations using this function
rg -l "\.receiveTransmissionEvent\(" --type-add 'sol:*.sol' --type sol
# Also check for any test files that might be using this function
fd -e sol -e js -e ts test
Length of output: 164
Script:
#!/bin/bash
# Check the test files for usage of receiveTransmissionEvent
rg -A 5 "receiveTransmissionEvent" test/utils/TestUtils.t.sol src/scripts/fork-deployment-test.ts
Length of output: 97
Script:
#!/bin/bash
# Look for any mentions of receiveTransmissionEvent in the entire codebase
rg "receiveTransmissionEvent" --type-add 'sol:*.sol' --type sol -B 2 -A 2
# Also check if Venus contract inherits from any interfaces
ast-grep --pattern 'contract Venus is $_'
Length of output: 645
src/evm/contracts/CrossL2Prover.ts (1)
221-221
: Ensure TypeScript bindings are updated consistently
The return type changes in the TypeScript interface match the Solidity contract changes. Verify that all consuming TypeScript code is updated accordingly.
Also applies to: 287-287
✅ Verification successful
No direct usage of validateReceipt method found
Based on the search results, the validateReceipt
method appears only in type definitions and contract interfaces (CrossL2Prover.ts
, ICrossL2Prover.ts
, and their respective factories). There are no direct calls to this method in the TypeScript codebase, suggesting it's likely only used through contract interactions at runtime.
The type changes are properly reflected in both the main contract interface and its interface counterpart, maintaining consistency in the TypeScript bindings.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Search for validateReceipt usage in TypeScript files
rg -t ts -A 2 'validateReceipt\('
Length of output: 35
Script:
#!/bin/bash
# Search for validateReceipt usage with a broader pattern
rg -t ts "validateReceipt"
# Also search for any imports of CrossL2Prover to find potential consumers
rg -t ts "CrossL2Prover"
# Search for the class definition to understand the context better
ast-grep --pattern 'class CrossL2Prover {
$$$
}'
Length of output: 4533
src/evm/contracts/Venus.ts (2)
Line range hint 281-287
: Event signature updated to match type changes
The event filter signature has been updated to use string type for chain IDs. This change is consistent with the type changes above.
61-61
:
Breaking change: New parameter added to receiveTransmissionEvent
The function signature has been updated to include an expectedEmitter
parameter. This is a breaking change that will require updates to all callers of this function.
Also applies to: 209-209, 246-246
src/evm/contracts/factories/Venus__factory.ts (1)
280-283
:
Breaking changes in contract deployment
Multiple breaking changes have been introduced:
- The
_chainId
parameter type has changed fromBytesLike
tostring
- The
_counterParty
parameter has been removed
These changes will affect contract deployment scripts and factory usage.
Also applies to: 287-290
src/evm/contracts/factories/CrossL2Prover__factory.ts (2)
141-142
: Verify chain identifier type consistency across the codebase.
The change from bytes32
to string
for the chainId
output type in validateEvent
aligns with the PR objectives. However, we should verify this change is consistently applied across related files.
✅ Verification successful
Based on the search results, I can generate the final response as we have sufficient information to verify the chain identifier type consistency. The search results show:
Chain identifier type changes are consistently applied across the codebase
The change from bytes32
to string
for chain identifiers is consistently implemented across the relevant interfaces and implementations:
- In contracts/interfaces/ICrossL2Prover.sol, both
validateEvent
andvalidateReceipt
functions usestring
type - In contracts/examples/Venus.sol, the
chainId
field and event parameters usestring
type - In contracts/core/proofAPI/CrossL2Prover.sol, the implementation uses
string
type - The only remaining
bytes32
chainId usage is in SequencerSignatureVerifier.sol which is a separate component with different requirements
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Verify chain identifier type consistency across related files
# Check for any remaining bytes32 chainId references
rg -i 'chainid.*bytes32|bytes32.*chainid'
# Check for string chainId declarations
rg -i 'chainid.*string|string.*chainid'
Length of output: 29148
174-176
: Verify validateReceipt return type changes.
The changes to validateReceipt
include:
- Changed first return parameter type from
bytes32
tostring
- Removed parameter name
receiptRLP
from second return value
These changes align with the PR objectives for standardizing chain identifiers.
Also applies to: 179-179
i mistyped chainID as chainId and then compiler didn't complain when they were different types because they were different variables 😱
Summary by CodeRabbit
New Features
validateEvent
andvalidateReceipt
functions to usestring
instead ofbytes32
forchainId
andsrcChainId
, respectively.counterParty
variable from theVenus
contract, simplifying its state and constructor parameters.expectedEmitter
parameter to thereceiveTransmissionEvent
function for enhanced validation.Bug Fixes
Chores
package.json
from4.0.17
to4.0.18
.