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

chore: copy evm & feemarket types to sdk-go #265

Open
wants to merge 4 commits into
base: master
Choose a base branch
from

Conversation

maxim-inj
Copy link
Contributor

@maxim-inj maxim-inj commented Nov 26, 2024

Copied types of EVM and FeeMarket modules required for https://github.com/InjectiveLabs/injective-core/pull/2014 in injective-core.

Interchaintest from injective-core uses sdk-go as entrypoint for all type / codec dependencies.

Summary by CodeRabbit

  • New Features

    • Introduced support for Ethereum access lists and dynamic fee transactions.
    • Added functionality for handling compiled Ethereum smart contracts.
    • Implemented error handling for Ethereum Virtual Machine operations.
    • Enhanced transaction management with new transaction types and structures.
    • Added new message types for Ethereum transactions and events in the fee market module.
    • Introduced a comprehensive set of utility functions for managing Ethereum transactions and logs.
  • Bug Fixes

    • Improved validation and error handling for various transaction parameters.
  • Documentation

    • Updated documentation for new message types and parameters in the fee market module.
  • Chores

    • Added entries to .gitignore to exclude certain files from version control.
    • Updated Makefile to streamline module management.
    • Updated Go version and dependencies in go.mod.

Copy link

coderabbitai bot commented Nov 26, 2024

Walkthrough

The changes introduced in this pull request encompass a variety of enhancements and new features across the Ethereum Virtual Machine (EVM) and fee market modules within the Injective blockchain. Key additions include new protocol buffer definitions for transaction handling, event logging, and genesis state management. The .gitignore file has been updated to exclude specific directories, while the Makefile has been modified to facilitate file copying related to EVM modules. Additionally, several new types and methods were added to improve transaction processing, validation, and error handling.

Changes

File/Path Change Summary
.gitignore Added entries to ignore .anima and .vscode directories.
Makefile Updated to include commands for copying Go files for evm and feemarket modules and added cleanup commands for test and gateway files.
chain/evm/types/access_list.go Introduced AccessList type and functions for converting between Ethereum and protobuf access lists.
chain/evm/types/access_list_tx.go Added AccessListTx structure with methods for handling Ethereum-style access list transactions, including validation and fee calculations.
chain/evm/types/chain_config.go Added ChainConfig struct for Ethereum chain configuration, including validation methods.
chain/evm/types/codec.go Established codecs for Ethereum messages and transactions, including packing and unpacking functions.
chain/evm/types/compiled_contract.go Managed compiled Ethereum smart contracts with serialization methods for ABI and bytecode.
chain/evm/types/dynamic_fee_tx.go Introduced DynamicFeeTx structure for dynamic fee transactions, including validation and fee calculation methods.
chain/evm/types/errors.go Added comprehensive error handling for EVM operations with structured error codes and messages.
chain/evm/types/eth.go Defined EthereumTx struct with methods for creating and validating Ethereum transactions.
chain/evm/types/events.go Introduced constants for Ethereum event types and associated attribute keys.
chain/evm/types/genesis.go Added functionality for validating and creating genesis states for EVM accounts.
chain/evm/types/interfaces.go Defined interfaces for various components related to EVM transactions, including account and bank management.
chain/evm/types/key.go Introduced constants and utility functions for EVM module key management.
chain/evm/types/legacy_tx.go Managed Ethereum legacy transactions with validation and signature handling.
chain/evm/types/logs.go Handled Ethereum transaction logs with validation and conversion methods.
chain/evm/types/msg.go Defined MsgEthereumTx for integrating Ethereum transactions into the Cosmos SDK.
chain/evm/types/params.go Introduced parameters for EVM settings, including validation logic.
chain/evm/types/protocol.go Defined constants for Ethereum protocol versions.
chain/evm/types/query.go Added methods for unpacking interfaces in query requests.
chain/evm/types/response.go Processed transaction responses with error handling and log updates.
chain/evm/types/storage.go Managed account storage states with validation methods.
chain/evm/types/tracer.go Introduced functionality for managing Ethereum transaction tracers.
chain/evm/types/tx.go Enhanced transaction handling with priority calculation and error management.
chain/evm/types/tx_args.go Encapsulated arguments for constructing Ethereum transactions.
chain/evm/types/tx_data.go Defined interface for handling Ethereum transaction data structures.
chain/evm/types/utils.go Provided utility functions for Ethereum transaction and log management.
chain/feemarket/types/codec.go Established codecs for the fee market module.
chain/feemarket/types/events.go Defined event types for fee market operations.
chain/feemarket/types/genesis.go Managed genesis state for the fee market module.
chain/feemarket/types/interfaces.go Introduced interfaces for managing fee market parameters.
chain/feemarket/types/keys.go Defined constants and key management for the fee market module.
chain/feemarket/types/msg.go Introduced message structure for updating fee market parameters.
chain/feemarket/types/params.go Managed parameters for fee market settings with validation logic.
proto/injective/evm/v1/access_tuple.proto Defined AccessTuple message for access list elements.
proto/injective/evm/v1/chain_config.proto Defined ChainConfig message for Ethereum chain configuration parameters.
proto/injective/evm/v1/events.proto Introduced messages for Ethereum transaction and log events.
proto/injective/evm/v1/genesis.proto Defined GenesisState and GenesisAccount messages for EVM module initialization.
proto/injective/evm/v1/log.proto Defined Log message for Ethereum log events.
proto/injective/evm/v1/params.proto Defined Params message for EVM module parameters.
proto/injective/evm/v1/query.proto Defined gRPC service for querying Ethereum-related data.
proto/injective/evm/v1/state.proto Defined State message representing key-value pairs in storage.
proto/injective/evm/v1/trace_config.proto Defined TraceConfig message for tracing functions.
proto/injective/evm/v1/transaction_logs.proto Defined TransactionLogs message for encapsulating transaction logs.
proto/injective/evm/v1/tx.proto Defined service and messages for Ethereum transaction handling.
proto/injective/evm/v1/tx_result.proto Defined TxResult message for transaction execution results.
proto/injective/feemarket/v1/events.proto Defined messages for fee market events.
proto/injective/feemarket/v1/feemarket.proto Defined Params message for fee market parameters.
proto/injective/feemarket/v1/genesis.proto Defined GenesisState message for managing fee market genesis state.
proto/injective/feemarket/v1/query.proto Defined gRPC service for querying fee market data.
proto/injective/feemarket/v1/tx.proto Defined service and messages for fee market governance operations.

Poem

In the fields of code, we hop and play,
New features sprout like flowers in May.
With transactions and logs, we dance in delight,
EVM's magic shines ever so bright!
So let’s celebrate, with a joyful cheer,
For in this code, our vision is clear! 🐇✨


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>, please review it.
    • 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 gather interesting stats about this repository and render them as a table. Additionally, render a pie chart showing the language distribution in the codebase.
    • @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 using 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.

Other keywords and placeholders

  • Add @coderabbitai ignore anywhere in the PR description to prevent this PR from being reviewed.
  • Add @coderabbitai summary to generate the high-level summary at a specific location in the PR description.
  • Add @coderabbitai anywhere in the PR title to generate the title automatically.

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

@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.

Caution

Inline review comments failed to post. This is likely due to GitHub's limits when posting large numbers of comments.

🛑 Comments failed to post (43)
proto/injective/feemarket/v1/events.proto (1)

13-18: 🛠️ Refactor suggestion

Consider using numeric types for height and amount fields.

In blockchain contexts, block height and gas amounts are typically represented as integers. Using string types might lead to unnecessary string-number conversions and potential parsing errors.

 message EventBlockGas {
   // height of the block
-  string height = 1;
+  uint64 height = 1;
   // amount of gas wanted by the block
-  string amount = 2;
+  uint64 amount = 2;
 }
📝 Committable suggestion

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.

message EventBlockGas {
  // height of the block
  uint64 height = 1;
  // amount of gas wanted by the block
  uint64 amount = 2;
}
chain/feemarket/types/genesis.go (1)

12-17: 🛠️ Refactor suggestion

Consider adding parameter validation.

The function accepts parameters without validation. Since this is used during genesis, invalid parameters could cause issues at chain initialization.

Consider adding validation:

 func NewGenesisState(params Params, blockGas uint64) *GenesisState {
+	if err := params.Validate(); err != nil {
+		panic(err)
+	}
 	return &GenesisState{
 		Params:   params,
 		BlockGas: blockGas,
 	}
 }

Committable suggestion skipped: line range outside the PR's diff.

proto/injective/evm/v1/events.proto (3)

40-44: 🛠️ Refactor suggestion

Use bytes for bloom filter storage

Ethereum bloom filters are 256-byte arrays. Storing them as strings is inefficient and may lead to unnecessary encoding/decoding overhead.

 message EventBlockBloom {
-  string bloom = 1;
+  bytes bloom = 1;  // 256-byte Ethereum bloom filter
 }
📝 Committable suggestion

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.

// EventBlockBloom defines an Ethereum block bloom filter event
message EventBlockBloom {
  // bloom is the bloom filter of the block
  bytes bloom = 1;  // 256-byte Ethereum bloom filter
}

24-28: 🛠️ Refactor suggestion

Enhance log structure to match Ethereum specification

The current implementation stores logs as strings, which loses the structured nature of Ethereum logs. Consider creating a dedicated Log message type that matches the Ethereum log structure.

+message Log {
+  string address = 1;
+  repeated string topics = 2;
+  string data = 3;
+  uint64 block_number = 4;
+  string tx_hash = 5;
+  uint64 tx_index = 6;
+  uint64 log_index = 7;
+}

 message EventTxLog {
-  repeated string tx_logs = 1;
+  repeated Log tx_logs = 1;
 }
📝 Committable suggestion

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.

// EventTxLog defines the event for an Ethereum transaction log
message Log {
  string address = 1;
  repeated string topics = 2;
  string data = 3;
  uint64 block_number = 4;
  string tx_hash = 5;
  uint64 tx_index = 6;
  uint64 log_index = 7;
}

message EventTxLog {
  // tx_logs is an array of transaction logs
  repeated Log tx_logs = 1;
}

7-22: 🛠️ Refactor suggestion

Consider optimizing field types for better type safety and performance

Several fields could benefit from more specific types:

  • amount: Consider using a numeric type with sufficient precision (e.g., bytes for big integers)
  • index: Should be uint64 for block position
  • gas_used: Should be uint64
  • eth_tx_failed: Consider renaming to error_message or vm_error for clarity
 message EventEthereumTx {
-  string amount = 1;
+  bytes amount = 1;  // Using bytes for arbitrary-precision integers
   string eth_hash = 2;
-  string index = 3;
+  uint64 index = 3;
-  string gas_used = 4;
+  uint64 gas_used = 4;
   string hash = 5;
   string recipient = 6;
-  string eth_tx_failed = 7;
+  string vm_error = 7;
 }
📝 Committable suggestion

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.

message EventEthereumTx {
  // amount
  bytes amount = 1;  // Using bytes for arbitrary-precision integers
  // eth_hash is the Ethereum hash of the transaction
  string eth_hash = 2;
  // index of the transaction in the block
  uint64 index = 3;
  // gas_used is the amount of gas used by the transaction
  uint64 gas_used = 4;
  // hash is the Tendermint hash of the transaction
  string hash = 5;
  // recipient of the transaction
  string recipient = 6;
  // eth_tx_failed contains a VM error should it occur
  string vm_error = 7;
}
chain/evm/types/access_list.go (1)

36-55: ⚠️ Potential issue

Add input validation and optimize slice allocation

Two improvements are needed:

  1. Add validation for hex string formats to prevent panics
  2. Pre-allocate the ethAccessList slice
 func (al AccessList) ToEthAccessList() *ethtypes.AccessList {
-	var ethAccessList ethtypes.AccessList
+	ethAccessList := make(ethtypes.AccessList, 0, len(al))
 
 	for _, tuple := range al {
+		// Validate address format
+		if !common.IsHexAddress(tuple.Address) {
+			return nil
+		}
+		
+		// Validate storage key formats
+		for _, key := range tuple.StorageKeys {
+			if len(key) != 66 || key[:2] != "0x" { // 0x + 64 hex chars
+				return nil
+			}
+		}
+		
 		storageKeys := make([]common.Hash, len(tuple.StorageKeys))

Committable suggestion skipped: line range outside the PR's diff.

proto/injective/evm/v1/log.proto (1)

16-18: 🛠️ Refactor suggestion

Consider using bytes for Ethereum-specific fields

For better compatibility with Ethereum's data structures:

  • address should be bytes (20 bytes) instead of string
  • topics should be bytes (32 bytes each) instead of string

This would ensure proper handling of Ethereum addresses and topic hashes without potential encoding/decoding issues.

- string address = 1;
- repeated string topics = 2;
+ bytes address = 1 [(gogoproto.casttype) = "github.com/ethereum/go-ethereum/common.Address"];
+ repeated bytes topics = 2 [(gogoproto.casttype) = "github.com/ethereum/go-ethereum/common.Hash"];
📝 Committable suggestion

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.

  bytes address = 1 [(gogoproto.casttype) = "github.com/ethereum/go-ethereum/common.Address"];
  // topics is a list of topics provided by the contract.
  repeated bytes topics = 2 [(gogoproto.casttype) = "github.com/ethereum/go-ethereum/common.Hash"];
chain/evm/types/tracer.go (3)

32-45: ⚠️ Potential issue

Implement case for TracerFirehose

The TracerFirehose constant is defined but not handled in the switch statement.

Add implementation for TracerFirehose or remove the unused constant.


25-28: 🛠️ Refactor suggestion

Consider making debug mode configurable

Debug mode is currently hardcoded to true, which could impact performance in production environments.

Consider making it configurable:

-	logCfg := &logger.Config{
-		Debug: true,
-	}
+	logCfg := &logger.Config{
+		Debug: os.Getenv("EVM_TRACER_DEBUG") == "true",
+	}
📝 Committable suggestion

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.

	// TODO: enable additional log configuration
	logCfg := &logger.Config{
		Debug: os.Getenv("EVM_TRACER_DEBUG") == "true",
	}

37-39: 🛠️ Refactor suggestion

Avoid direct use of os.Stderr/os.Stdout

Direct use of os.Stderr and os.Stdout makes the code harder to test and less flexible.

Consider injecting io.Writer interfaces:

-func NewTracer(tracer string, msg *core.Message, rules params.Rules) *tracers.Tracer {
+func NewTracer(tracer string, msg *core.Message, rules params.Rules, output io.Writer) *tracers.Tracer {
     // ...
-    hooks = logger.NewJSONLogger(logCfg, os.Stderr)
+    hooks = logger.NewJSONLogger(logCfg, output)
     // ...
-    hooks = logger.NewMarkdownLogger(logCfg, os.Stdout).Hooks() // TODO: Stderr ?
+    hooks = logger.NewMarkdownLogger(logCfg, output).Hooks()

Committable suggestion skipped: line range outside the PR's diff.

chain/evm/types/params.go (1)

125-128: 🛠️ Refactor suggestion

Add nil check for ethConfig parameter.

The IsLondon function should handle nil config gracefully.

 func IsLondon(ethConfig *params.ChainConfig, height int64) bool {
+	if ethConfig == nil {
+		return false
+	}
 	return ethConfig.IsLondon(big.NewInt(height))
 }
📝 Committable suggestion

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.

// IsLondon returns if london hardfork is enabled.
func IsLondon(ethConfig *params.ChainConfig, height int64) bool {
	if ethConfig == nil {
		return false
	}
	return ethConfig.IsLondon(big.NewInt(height))
}
proto/injective/evm/v1/chain_config.proto (1)

33-33: ⚠️ Potential issue

Fix incorrect YAML tag for eip150_hash

The YAML tag for eip150_hash is incorrectly set to "byzantium_block" instead of "eip150_hash".

-  string eip150_hash = 5 [(gogoproto.customname) = "EIP150Hash", (gogoproto.moretags) = "yaml:\"byzantium_block\""];
+  string eip150_hash = 5 [(gogoproto.customname) = "EIP150Hash", (gogoproto.moretags) = "yaml:\"eip150_hash\""];
📝 Committable suggestion

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.

  string eip150_hash = 5 [(gogoproto.customname) = "EIP150Hash", (gogoproto.moretags) = "yaml:\"eip150_hash\""];
chain/evm/types/eth.go (1)

27-37: ⚠️ Potential issue

Check destination buffer size in MarshalTo() to prevent data truncation

In the MarshalTo() method, the serialized data bz is copied into dst without verifying if dst has enough capacity. If dst is smaller than bz, this could lead to incomplete data copying. Consider checking the length of dst before copying and return an error if it's insufficient.

Apply this diff to add a size check:

 func (tx EthereumTx) MarshalTo(dst []byte) (int, error) {
     if tx.Transaction == nil {
         return 0, nil
     }
     bz, err := tx.MarshalBinary()
     if err != nil {
         return 0, err
     }
+    if len(dst) < len(bz) {
+        return 0, fmt.Errorf("destination buffer too small: need %d bytes", len(bz))
+    }
     copy(dst, bz)
     return len(bz), nil
 }

Ensure to import the "fmt" package if it's not already imported.

📝 Committable suggestion

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.

func (tx EthereumTx) MarshalTo(dst []byte) (int, error) {
	if tx.Transaction == nil {
		return 0, nil
	}
	bz, err := tx.MarshalBinary()
	if err != nil {
		return 0, err
	}
	if len(dst) < len(bz) {
		return 0, fmt.Errorf("destination buffer too small: need %d bytes", len(bz))
	}
	copy(dst, bz)
	return len(bz), nil
}
chain/evm/types/compiled_contract.go (2)

114-116: ⚠️ Potential issue

Fix incorrect variable reference in the init function.

After unmarshalling simpleStorageJSON into SimpleStorageContract, the code incorrectly checks TestMessageCall.Bin instead of SimpleStorageContract.Bin. This will cause the check to fail even if SimpleStorageContract is loaded correctly.

Suggested change:

-	if len(TestMessageCall.Bin) == 0 {
+	if len(SimpleStorageContract.Bin) == 0 {
		panic("load contract failed")
	}
📝 Committable suggestion

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.

	if len(SimpleStorageContract.Bin) == 0 {
		panic("load contract failed")
	}

17-19: 🛠️ Refactor suggestion

Simplify the encoding in 'MarshalJSON' method for HexString.

Using hex.EncodeToString(s) is more efficient and idiomatic than fmt.Sprintf("%x", string(s)).

Suggested change:

-	return json.Marshal(fmt.Sprintf("%x", string(s)))
+	return json.Marshal(hex.EncodeToString(s))
📝 Committable suggestion

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.

func (s HexString) MarshalJSON() ([]byte, error) {
	return json.Marshal(hex.EncodeToString(s))
}
chain/evm/types/codec.go (2)

37-40: ⚠️ Potential issue

Avoid duplicate registration of MsgEthereumTx

MsgEthereumTx is registered twice as an implementation of sdk.Msg (lines 37-40 and 46-49). This duplication may lead to unexpected behavior or increased binary size. Consider removing the redundant registration.

Apply this diff to remove the duplicate registration:

 func RegisterInterfaces(registry codectypes.InterfaceRegistry) {
     registry.RegisterImplementations(
         (*sdk.Msg)(nil),
         &MsgEthereumTx{},
     )
     registry.RegisterImplementations(
         (*tx.TxExtensionOptionI)(nil),
         &ExtensionOptionsEthereumTx{},
     )
-    registry.RegisterImplementations(
-        (*sdk.Msg)(nil),
-        &MsgEthereumTx{},
-        &MsgUpdateParams{},
-    )
+    registry.RegisterImplementations(
+        (*sdk.Msg)(nil),
+        &MsgUpdateParams{},
+    )
     registry.RegisterInterface(
         "injective.evm.v1.TxData",
         (*TxData)(nil),

Also applies to: 46-49


81-91: ⚠️ Potential issue

Handle potential nil value in UnpackTxData

When unpacking Any, the GetCachedValue() method might return nil. Add a nil check before the type assertion to prevent a potential nil pointer dereference.

Apply this diff to add the nil check:

 func UnpackTxData(any *codectypes.Any) (TxData, error) {
     if any == nil {
         return nil, errorsmod.Wrap(errortypes.ErrUnpackAny, "protobuf Any message cannot be nil")
     }

+    if any.GetCachedValue() == nil {
+        return nil, errorsmod.Wrap(errortypes.ErrUnpackAny, "cached value in Any is nil")
+    }
+
     txData, ok := any.GetCachedValue().(TxData)
     if !ok {
         return nil, errorsmod.Wrapf(errortypes.ErrUnpackAny, "cannot unpack Any into TxData %T", any)
     }
📝 Committable suggestion

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.

	if any == nil {
		return nil, errorsmod.Wrap(errortypes.ErrUnpackAny, "protobuf Any message cannot be nil")
	}

	if any.GetCachedValue() == nil {
		return nil, errorsmod.Wrap(errortypes.ErrUnpackAny, "cached value in Any is nil")
	}

	txData, ok := any.GetCachedValue().(TxData)
	if !ok {
		return nil, errorsmod.Wrapf(errortypes.ErrUnpackAny, "cannot unpack Any into TxData %T", any)
	}

	return txData, nil
}
chain/evm/types/tx_data.go (1)

83-98: ⚠️ Potential issue

Avoid variable shadowing of v in DeriveChainID

In the DeriveChainID function, the variable v is redeclared in line 84 as v := v.Uint64(), which shadows the input parameter v. This can lead to confusion and potential bugs due to variable shadowing.

Consider renaming the local variable to prevent shadowing. Here's the suggested change:

 func DeriveChainID(v *big.Int) *big.Int {
     if v == nil || v.Sign() < 1 {
         return nil
     }

     if v.BitLen() <= 64 {
-        v := v.Uint64()
+        vUint64 := v.Uint64()
-        if v == 27 || v == 28 {
+        if vUint64 == 27 || vUint64 == 28 {
             return new(big.Int)
         }

-        if v < 35 {
+        if vUint64 < 35 {
             return nil
         }

         // V MUST be of the form {0,1} + CHAIN_ID * 2 + 35
-        return new(big.Int).SetUint64((v - 35) / 2)
+        return new(big.Int).SetUint64((vUint64 - 35) / 2)
     }
     v = new(big.Int).Sub(v, big.NewInt(35))
     return v.Div(v, big.NewInt(2))
 }
📝 Committable suggestion

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.

	if v.BitLen() <= 64 {
		vUint64 := v.Uint64()
		if vUint64 == 27 || vUint64 == 28 {
			return new(big.Int)
		}

		if vUint64 < 35 {
			return nil
		}

		// V MUST be of the form {0,1} + CHAIN_ID * 2 + 35
		return new(big.Int).SetUint64((vUint64 - 35) / 2)
	}
	v = new(big.Int).Sub(v, big.NewInt(35))
	return v.Div(v, big.NewInt(2))
}
chain/evm/types/interfaces.go (2)

8-8: 🛠️ Refactor suggestion

Avoid potential naming conflicts by aliasing the imported types package

Since this file is in package types, importing another package as types can cause confusion. To improve clarity, consider aliasing the imported package.

Apply this diff:

-	"github.com/cosmos/cosmos-sdk/x/bank/types"
+	banktypes "github.com/cosmos/cosmos-sdk/x/bank/types"

Then update the method signatures:

-	GetDenomMetaData(ctx context.Context, denom string) (types.Metadata, bool)
+	GetDenomMetaData(ctx context.Context, denom string) (banktypes.Metadata, bool)

-	SetDenomMetaData(ctx context.Context, denomMetaData types.Metadata)
+	SetDenomMetaData(ctx context.Context, denomMetaData banktypes.Metadata)

Also applies to: 42-43


22-29: 🛠️ Refactor suggestion

Standardize the use of context types in method signatures

The interfaces defined in this file use both context.Context and sdk.Context inconsistently for the ctx parameter. For better maintainability and to avoid confusion, please standardize on one context type across all interfaces.

Also applies to: 33-44, 48-73

chain/evm/types/logs.go (1)

117-117: 🛠️ Refactor suggestion

Inconsistent address conversion method

In NewLogFromEth, the Address field uses HexAddress(log.Address.Bytes()), whereas in ToEthereum, the conversion uses common.HexToAddress(log.Address). Ensure consistency in address conversion methods.

Consider updating the Address assignment in NewLogFromEth:

-		Address:     HexAddress(log.Address.Bytes()),
+		Address:     log.Address.Hex(),

Or ensure that HexAddress functions equivalently to common.HexToAddress.

Committable suggestion skipped: line range outside the PR's diff.

chain/evm/types/legacy_tx.go (2)

160-217: 🛠️ Refactor suggestion

Use pointer receivers for methods to prevent unintended copying

The methods Validate, Fee, Cost, EffectiveGasPrice, EffectiveFee, and EffectiveCost use value receivers:

func (tx LegacyTx) Validate() error { ... }

Using value receivers can lead to unintended copying of the LegacyTx struct, especially if it contains pointers or large amounts of data. Consider changing the receiver to a pointer to improve efficiency and maintain consistency with other methods.

Apply this diff to change the receivers:

-func (tx LegacyTx) Validate() error {
+func (tx *LegacyTx) Validate() error {

-func (tx LegacyTx) Fee() *big.Int {
+func (tx *LegacyTx) Fee() *big.Int {

-func (tx LegacyTx) Cost() *big.Int {
+func (tx *LegacyTx) Cost() *big.Int {

-func (tx LegacyTx) EffectiveGasPrice(_ *big.Int) *big.Int {
+func (tx *LegacyTx) EffectiveGasPrice(_ *big.Int) *big.Int {

-func (tx LegacyTx) EffectiveFee(_ *big.Int) *big.Int {
+func (tx *LegacyTx) EffectiveFee(_ *big.Int) *big.Int {

-func (tx LegacyTx) EffectiveCost(_ *big.Int) *big.Int {
+func (tx *LegacyTx) EffectiveCost(_ *big.Int) *big.Int {

50-62: 🛠️ Refactor suggestion

⚠️ Potential issue

Ensure deep copy of pointer fields in Copy method

In the Copy method, the fields GasPrice and Amount are pointers. Copying them directly can lead to unintended shared references between the original and copied transactions. Consider creating deep copies of these fields to prevent potential side effects if they are modified elsewhere.

Apply this diff to perform a deep copy of the pointer fields:

 func (tx *LegacyTx) Copy() TxData {
 	return &LegacyTx{
 		Nonce:    tx.Nonce,
-		GasPrice: tx.GasPrice,
+		GasPrice: tx.GasPrice.Clone(),
 		GasLimit: tx.GasLimit,
 		To:       tx.To,
-		Amount:   tx.Amount,
+		Amount:   tx.Amount.Clone(),
 		Data:     common.CopyBytes(tx.Data),
 		V:        common.CopyBytes(tx.V),
 		R:        common.CopyBytes(tx.R),
 		S:        common.CopyBytes(tx.S),
 	}
 }

Committable suggestion skipped: line range outside the PR's diff.

chain/feemarket/types/params.go (1)

49-49: ⚠️ Potential issue

Fix validator function for MinGasMultiplier parameter

In the ParamSetPairs method, the MinGasMultiplier parameter is incorrectly using validateMinGasPrice as its validation function. It should use validateMinGasMultiplier instead.

Apply this diff to fix the validator function:

-		paramtypes.NewParamSetPair(ParamStoreKeyMinGasMultiplier, &p.MinGasMultiplier, validateMinGasPrice),
+		paramtypes.NewParamSetPair(ParamStoreKeyMinGasMultiplier, &p.MinGasMultiplier, validateMinGasMultiplier),
📝 Committable suggestion

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.

		paramtypes.NewParamSetPair(ParamStoreKeyMinGasMultiplier, &p.MinGasMultiplier, validateMinGasMultiplier),
chain/evm/types/access_list_tx.go (2)

202-205: ⚠️ Potential issue

Prevent possible nil dereference when validating amount

In the Validate method, if amount is nil, calling types.IsValidInt256(amount) may result in a nil pointer dereference. Please ensure that amount is not nil before calling types.IsValidInt256(amount).

Suggested fix:

 if amount != nil && amount.Sign() == -1 {
     return errorsmod.Wrapf(ErrInvalidAmount, "amount cannot be negative %s", amount)
 }
+if amount != nil && !types.IsValidInt256(amount) {
     return errorsmod.Wrap(ErrInvalidAmount, "out of bound")
 }
📝 Committable suggestion

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.

	if amount != nil && !types.IsValidInt256(amount) {
		return errorsmod.Wrap(ErrInvalidAmount, "out of bound")
	}


68-68: 🛠️ Refactor suggestion

Perform deep copy of Accesses in Copy() method

In the Copy() method, tx.Accesses is copied by reference. To prevent unintended side effects from shared references, consider performing a deep copy of tx.Accesses.

Suggested fix:

If Accesses has a Copy() method, use it to perform a deep copy:

return &AccessListTx{
    // ... other fields ...
    Data:     common.CopyBytes(tx.Data),
-   Accesses: tx.Accesses,
+   Accesses: tx.Accesses.Copy(),
    // ... other fields ...
}

If Accesses does not have a Copy() method, you may need to implement one.

Committable suggestion skipped: line range outside the PR's diff.

chain/evm/types/tx_args.go (1)

41-52: ⚠️ Potential issue

Avoid potential panic in String() method due to nil hexutil.Big values

Formatting hexutil.Big fields that are nil can cause a panic. As noted in the TODO comment, printing nil values of hexutil.Big triggers an exception.

Consider adding nil checks before formatting or provide default values to safely handle nil values.

Apply this diff to prevent the panic:

 func (args *TransactionArgs) String() string {
-	return fmt.Sprintf("TransactionArgs{From:%v, To:%v, Gas:%v,"+
+	return fmt.Sprintf("TransactionArgs{From:%v, To:%v, Gas:%v, GasPrice:%v, MaxFeePerGas:%v, MaxPriorityFeePerGas:%v, Value:%v,"+
 		" Nonce:%v, Data:%v, Input:%v, AccessList:%v}",
 		args.From,
 		args.To,
 		args.Gas,
+		nilSafeHexutilBig(args.GasPrice),
+		nilSafeHexutilBig(args.MaxFeePerGas),
+		nilSafeHexutilBig(args.MaxPriorityFeePerGas),
+		nilSafeHexutilBig(args.Value),
 		args.Nonce,
 		args.Data,
 		args.Input,
 		args.AccessList)
 }
+
+// Helper function to safely print hexutil.Big
+func nilSafeHexutilBig(h *hexutil.Big) *big.Int {
+	if h != nil {
+		return h.ToInt()
+	}
+	return big.NewInt(0)
+}

Committable suggestion skipped: line range outside the PR's diff.

chain/evm/types/chain_config.go (3)

168-174: 🛠️ Refactor suggestion

Enhance ValidateHash to verify hash format

The current implementation of ValidateHash checks for non-empty and non-blank strings but does not verify whether the hex string is a valid hash (e.g., correct length and hexadecimal characters).

Consider updating ValidateHash to validate the hash format:

 func ValidateHash(hex string) error {
     if strings.TrimSpace(hex) == "" {
         return errorsmod.Wrap(ErrInvalidChainConfig, "hash cannot be blank")
     }
+    if !common.IsHexHash(hex) {
+        return errorsmod.Wrap(ErrInvalidChainConfig, "invalid hash format")
+    }
     return nil
 }

Ensure you have the appropriate function IsHexHash available, which checks if the string is a valid hexadecimal hash. You may need to import common from the Ethereum Go library or implement a similar validation function.

Committable suggestion skipped: line range outside the PR's diff.


93-99: ⚠️ Potential issue

Check for potential overflow when converting time to uint64

In getTimeValue, the conversion from sdkmath.Int to uint64 may result in an overflow if time exceeds the maximum value of uint64.

Consider adding a check to ensure time fits within uint64:

 func getTimeValue(time *sdkmath.Int) *uint64 {
     if time == nil || time.IsNegative() {
         return nil
     }
+    if !time.BigInt().IsUint64() {
+        return nil // or handle the error as appropriate
+    }
     t := time.BigInt().Uint64()
     return &t
 }

This ensures that only valid uint64 values are returned, preventing potential overflow issues.

Committable suggestion skipped: line range outside the PR's diff.


45-83: ⚠️ Potential issue

Include CancunTime and PragueTime in DefaultChainConfig

In DefaultChainConfig, the fields CancunTime and PragueTime are not initialized, but they are utilized in EthereumConfig. This could lead to nil values where defaults might be expected.

Apply the following changes to initialize these fields:

 shanghaiTime := sdkmath.ZeroInt()
+cancunTime := sdkmath.ZeroInt()
+pragueTime := sdkmath.ZeroInt()

 return ChainConfig{
     HomesteadBlock:      &homesteadBlock,
     DAOForkBlock:        &daoForkBlock,
     DAOForkSupport:      true,
     EIP150Block:         &eip150Block,
     EIP150Hash:          common.Hash{}.String(),
     EIP155Block:         &eip155Block,
     EIP158Block:         &eip158Block,
     ByzantiumBlock:      &byzantiumBlock,
     ConstantinopleBlock: &constantinopleBlock,
     PetersburgBlock:     &petersburgBlock,
     IstanbulBlock:       &istanbulBlock,
     MuirGlacierBlock:    &muirGlacierBlock,
     BerlinBlock:         &berlinBlock,
     LondonBlock:         &londonBlock,
     ArrowGlacierBlock:   &arrowGlacierBlock,
     GrayGlacierBlock:    &grayGlacierBlock,
     MergeNetsplitBlock:  &mergeNetsplitBlock,
     ShanghaiTime:        &shanghaiTime,
+    CancunTime:          &cancunTime,
+    PragueTime:          &pragueTime,
 }
📝 Committable suggestion

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.

func DefaultChainConfig() ChainConfig {
	homesteadBlock := sdkmath.ZeroInt()
	daoForkBlock := sdkmath.ZeroInt()
	eip150Block := sdkmath.ZeroInt()
	eip155Block := sdkmath.ZeroInt()
	eip158Block := sdkmath.ZeroInt()
	byzantiumBlock := sdkmath.ZeroInt()
	constantinopleBlock := sdkmath.ZeroInt()
	petersburgBlock := sdkmath.ZeroInt()
	istanbulBlock := sdkmath.ZeroInt()
	muirGlacierBlock := sdkmath.ZeroInt()
	berlinBlock := sdkmath.ZeroInt()
	londonBlock := sdkmath.ZeroInt()
	arrowGlacierBlock := sdkmath.ZeroInt()
	grayGlacierBlock := sdkmath.ZeroInt()
	mergeNetsplitBlock := sdkmath.ZeroInt()
	shanghaiTime := sdkmath.ZeroInt()
	cancunTime := sdkmath.ZeroInt()
	pragueTime := sdkmath.ZeroInt()

	return ChainConfig{
		HomesteadBlock:      &homesteadBlock,
		DAOForkBlock:        &daoForkBlock,
		DAOForkSupport:      true,
		EIP150Block:         &eip150Block,
		EIP150Hash:          common.Hash{}.String(),
		EIP155Block:         &eip155Block,
		EIP158Block:         &eip158Block,
		ByzantiumBlock:      &byzantiumBlock,
		ConstantinopleBlock: &constantinopleBlock,
		PetersburgBlock:     &petersburgBlock,
		IstanbulBlock:       &istanbulBlock,
		MuirGlacierBlock:    &muirGlacierBlock,
		BerlinBlock:         &berlinBlock,
		LondonBlock:         &londonBlock,
		ArrowGlacierBlock:   &arrowGlacierBlock,
		GrayGlacierBlock:    &grayGlacierBlock,
		MergeNetsplitBlock:  &mergeNetsplitBlock,
		ShanghaiTime:        &shanghaiTime,
		CancunTime:          &cancunTime,
		PragueTime:          &pragueTime,
	}
}
chain/evm/types/dynamic_fee_tx.go (1)

67-82: ⚠️ Potential issue

Ensure Deep Copy of Pointer Fields in Copy Method

The Copy() method copies pointer fields (ChainID, GasTipCap, GasFeeCap, Amount, Accesses) directly without creating new copies of the values they point to. This could lead to unintended side effects if the copied instance or the original modifies these fields, as they would share the same underlying data.

Consider creating deep copies of these pointer fields to ensure that the copied transaction is fully independent. For example:

func (tx *DynamicFeeTx) Copy() TxData {
    return &DynamicFeeTx{
-       ChainID:   tx.ChainID,
+       ChainID:   copyIntPointer(tx.ChainID),
        Nonce:     tx.Nonce,
-       GasTipCap: tx.GasTipCap,
+       GasTipCap: copyIntPointer(tx.GasTipCap),
-       GasFeeCap: tx.GasFeeCap,
+       GasFeeCap: copyIntPointer(tx.GasFeeCap),
        GasLimit:  tx.GasLimit,
        To:        tx.To,
-       Amount:    tx.Amount,
+       Amount:    copyIntPointer(tx.Amount),
        Data:      common.CopyBytes(tx.Data),
-       Accesses:  tx.Accesses,
+       Accesses:  tx.Accesses.Copy(), // Assuming Accesses has a Copy() method
        V:         common.CopyBytes(tx.V),
        R:         common.CopyBytes(tx.R),
        S:         common.CopyBytes(tx.S),
    }
}

+func copyIntPointer(i *sdkmath.Int) *sdkmath.Int {
+    if i == nil {
+        return nil
+    }
+    intCopy := sdkmath.NewIntFromBigInt(i.BigInt())
+    return &intCopy
+}

Committable suggestion skipped: line range outside the PR's diff.

chain/evm/types/utils.go (2)

230-232: ⚠️ Potential issue

Add nil checks to prevent potential nil pointer dereferences in EffectiveGasPrice

The function EffectiveGasPrice does not check if baseFee, feeCap, or tipCap are nil. If any of these inputs are nil, the function will panic due to a nil pointer dereference when performing big.Int operations.

Consider adding nil checks for the input parameters to prevent potential runtime panics. Here's a suggested fix:

func EffectiveGasPrice(baseFee *big.Int, feeCap *big.Int, tipCap *big.Int) *big.Int {
+	if baseFee == nil || feeCap == nil || tipCap == nil {
+		// Handle the nil case appropriately, for example, return nil or a default value
+		return nil
+	}
	return math.BigMin(new(big.Int).Add(tipCap, baseFee), feeCap)
}

Ensure that callers of this function handle the case where nil might be returned.

📝 Committable suggestion

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.

func EffectiveGasPrice(baseFee *big.Int, feeCap *big.Int, tipCap *big.Int) *big.Int {
	if baseFee == nil || feeCap == nil || tipCap == nil {
		// Handle the nil case appropriately, for example, return nil or a default value
		return nil
	}
	return math.BigMin(new(big.Int).Add(tipCap, baseFee), feeCap)
}

189-206: ⚠️ Potential issue

Fix incorrect error message in UnwrapEthereumMsg function

The error message returned when the message type assertion fails incorrectly references the type of tx instead of msg. It should reference msg to accurately reflect the type that failed the assertion.

Apply this diff to correct the error message:

func UnwrapEthereumMsg(tx *sdk.Tx, ethHash common.Hash) (*MsgEthereumTx, error) {
	if tx == nil {
		return nil, fmt.Errorf("invalid tx: nil")
	}

	for _, msg := range (*tx).GetMsgs() {
		ethMsg, ok := msg.(*MsgEthereumTx)
		if !ok {
-			return nil, fmt.Errorf("invalid tx type: %T", tx)
+			return nil, fmt.Errorf("invalid message type: %T", msg)
		}
		txHash := ethMsg.AsTransaction().Hash()
		if txHash == ethHash {
			return ethMsg, nil
		}
	}
	return nil, fmt.Errorf("eth tx not found: %s", ethHash)
}
📝 Committable suggestion

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.

func UnwrapEthereumMsg(tx *sdk.Tx, ethHash common.Hash) (*MsgEthereumTx, error) {
	if tx == nil {
		return nil, fmt.Errorf("invalid tx: nil")
	}

	for _, msg := range (*tx).GetMsgs() {
		ethMsg, ok := msg.(*MsgEthereumTx)
		if !ok {
			return nil, fmt.Errorf("invalid message type: %T", msg)
		}
		txHash := ethMsg.AsTransaction().Hash()
		if txHash == ethHash {
			return ethMsg, nil
		}
	}

	return nil, fmt.Errorf("eth tx not found: %s", ethHash)
}
chain/evm/types/errors.go (1)

17-18: ⚠️ Potential issue

Assign explicit value to codeErrExecutionReverted to prevent accidental changes

The constant codeErrExecutionReverted must remain with a specific code value (3) to comply with the JSON-RPC error standard. Currently, it relies on the position in the iota sequence, which can change if new error codes are added above it. To prevent unintended changes, assign an explicit value to codeErrExecutionReverted.

Suggested change:

const (
    codeErrInvalidState      = uint32(iota) + 2 // NOTE: code 1 is reserved for internal errors
-   codeErrExecutionReverted                    // IMPORTANT: Do not move this error as it complies with the JSON-RPC error standard
+   codeErrExecutionReverted = 3                // IMPORTANT: Do not change this value as it complies with the JSON-RPC error standard
    codeErrChainConfigNotFound
    codeErrInvalidChainConfig
    // ...
)

Committable suggestion skipped: line range outside the PR's diff.

chain/evm/types/msg.go (6)

253-256: ⚠️ Potential issue

Potential nil pointer dereference in GetFee method.

In the GetFee method, there's a possibility of a nil pointer dereference if tx or price is nil.

func (msg MsgEthereumTx) GetFee() *big.Int {
	tx := msg.AsTransaction()
	price := tx.GasPrice()
	return price.Mul(price, new(big.Int).SetUint64(tx.Gas()))
}

If tx is nil, tx.GasPrice() will cause a panic. Similarly, if price is nil, price.Mul(...) will panic.

Add nil checks to prevent this:

func (msg MsgEthereumTx) GetFee() *big.Int {
	tx := msg.AsTransaction()
	if tx == nil {
		return big.NewInt(0)
	}
	price := tx.GasPrice()
	if price == nil {
		return big.NewInt(0)
	}
	return price.Mul(price, new(big.Int).SetUint64(tx.Gas()))
}

260-262: ⚠️ Potential issue

Ensure GetEffectiveFee handles nil values gracefully.

Similar to GetFee, GetEffectiveFee should check for nil values to avoid panics.

func (msg MsgEthereumTx) GetEffectiveFee(baseFee *big.Int) *big.Int {
	price := msg.GetEffectiveGasPrice(baseFee)
	if price == nil {
		return big.NewInt(0)
	}
	return price.Mul(price, new(big.Int).SetUint64(msg.GetGas()))
}

296-317: ⚠️ Potential issue

Add nil check for tx in AsMessage method.

In AsMessage, tx might be nil, leading to panics when accessing its methods.

func (msg *MsgEthereumTx) AsMessage(baseFee *big.Int) *core.Message {
	tx := msg.AsTransaction()
+	if tx == nil {
+		return nil
+	}
	// existing code...
}

Also, ensure that you handle the case where AsMessage returns nil.


212-214: 🛠️ Refactor suggestion

Avoid using panic in GetSignBytes method.

The GetSignBytes method panics, which can cause the application to crash unexpectedly. It's better to return an error to handle this case gracefully.

-func (msg MsgEthereumTx) GetSignBytes() []byte {
-	panic("must use 'RLPSignBytes' with a chain ID to get the valid bytes to sign")
+func (msg MsgEthereumTx) GetSignBytes() ([]byte, error) {
+	return nil, fmt.Errorf("must use 'RLPSignBytes' with a chain ID to get the valid bytes to sign")
}

Make sure to update the method signature and handle the error where this method is called.

📝 Committable suggestion

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.

func (msg MsgEthereumTx) GetSignBytes() ([]byte, error) {
	return nil, fmt.Errorf("must use 'RLPSignBytes' with a chain ID to get the valid bytes to sign")
}

280-293: 🛠️ Refactor suggestion

Avoid silent failures by returning errors in AsTransaction.

Returning nil without an error when unpacking fails can make debugging difficult.

Modify the method to return an error:

- if err != nil {
-     return nil
+ if err != nil {
+     return nil, err
}

And update all callers to handle the error appropriately.

Committable suggestion skipped: line range outside the PR's diff.


280-293: 🛠️ Refactor suggestion

Handle nil returns in AsTransaction method.

The AsTransaction method can return nil in case of an error during unpacking, which can lead to nil pointer dereferences where it's used.

Ensure that the calling functions check if tx is nil before using it.

Alternatively, modify AsTransaction to return an error:

-func (msg *MsgEthereumTx) AsTransaction() *ethtypes.Transaction {
+func (msg *MsgEthereumTx) AsTransaction() (*ethtypes.Transaction, error) {
	// existing logic...
	if err != nil {
-		return nil
+		return nil, err
	}
	// return tx
}

And update the callers accordingly.

Committable suggestion skipped: line range outside the PR's diff.

proto/injective/evm/v1/query.proto (3)

4-4: ⚠️ Potential issue

Fix the import path for pagination.proto

The import statement at line 4 refers to "cosmos/base/query/v1beta1/pagination.proto", but this file does not exist, leading to a compile error. Please verify the correct path or ensure that the file is available at the specified location.

🧰 Tools
🪛 buf (1.47.2)

4-4: import "cosmos/base/query/v1beta1/pagination.proto": file does not exist

(COMPILE)


44-45: ⚠️ Potential issue

Update the comment for the Code RPC method

The comment incorrectly states that it queries "the balance of all coins for a single account." It should specify that it retrieves the code bytecode of a contract.

Suggested fix:

-    // Code queries the balance of all coins for a single account.
+    // Code retrieves the code bytecode for a given contract address.
📝 Committable suggestion

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.

  // Code retrieves the code bytecode for a given contract address.
  rpc Code(QueryCodeRequest) returns (QueryCodeResponse) {

39-40: ⚠️ Potential issue

Update the comment for the Storage RPC method

The comment describes querying "the balance of all coins for a single account," which doesn't align with the purpose of the Storage method. It should reflect that it queries the storage state of an account.

Suggested fix:

-    // Storage queries the balance of all coins for a single account.
+    // Storage queries the storage state of an account at a specific key.
📝 Committable suggestion

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.

  // Storage queries the storage state of an account at a specific key.
  rpc Storage(QueryStorageRequest) returns (QueryStorageResponse) {

Copy link

@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: 31

🧹 Outside diff range and nitpick comments (41)
proto/injective/evm/v1/access_tuple.proto (1)

8-16: Consider adding field constraints and validation.

While the message structure is correct, consider enhancing it with additional protobuf field options to ensure data integrity:

 message AccessTuple {
   option (gogoproto.goproto_getters) = false;
 
   // address is a hex formatted ethereum address
-  string address = 1;
+  string address = 1 [
+    (gogoproto.moretags) = "validate:\"required,eth_addr\"",
+    (gogoproto.customtype) = "github.com/ethereum/go-ethereum/common.Address"
+  ];
   // storage_keys are hex formatted hashes of the storage keys
-  repeated string storage_keys = 2 [(gogoproto.jsontag) = "storageKeys"];
+  repeated string storage_keys = 2 [
+    (gogoproto.jsontag) = "storageKeys",
+    (gogoproto.moretags) = "validate:\"dive,required,eth_hash\"",
+    (gogoproto.customtype) = "github.com/ethereum/go-ethereum/common.Hash"
+  ];
 }

This enhancement:

  1. Adds validation for Ethereum address format
  2. Adds validation for storage key hash format
  3. Uses Go-Ethereum types for better type safety
proto/injective/evm/v1/transaction_logs.proto (2)

8-10: Documentation could be improved

While the documentation explains the purpose, it contains a minor typo and could be more descriptive about the upgrade implications.

Apply this diff to improve the documentation:

-// TransactionLogs define the logs generated from a transaction execution
-// with a given hash. It it used for import/export data as transactions are not
-// persisted on blockchain state after an upgrade.
+// TransactionLogs define the logs generated from a transaction execution
+// with a given hash. It is used for import/export data since transactions
+// and their logs are not persisted in the blockchain state after an upgrade.
+// This structure ensures data continuity across chain upgrades.

1-16: Consider versioning strategy for EVM compatibility

Since this is part of copying EVM types to sdk-go, consider:

  1. Adding a version field to support future EVM upgrades
  2. Documenting the specific EVM version these types are compatible with
  3. Adding validation for Ethereum-specific hash format

This will help maintain compatibility and make future upgrades smoother.

🧰 Tools
🪛 buf (1.47.2)

4-4: import "injective/evm/v1/log.proto": file does not exist

(COMPILE)

proto/injective/evm/v1/tx_result.proto (2)

16-16: Consider adding address validation for contract_address

The contract_address field stores Ethereum addresses, which should be 20 bytes (40 hex characters) when not empty. Consider adding validation to ensure the address format is correct.

-  string contract_address = 1 [(gogoproto.moretags) = "yaml:\"contract_address\""];
+  string contract_address = 1 [
+    (gogoproto.moretags) = "yaml:\"contract_address\"",
+    (validate.rules).string = {
+      pattern: "^(0x[a-fA-F0-9]{40})?$"
+    }
+  ];

18-18: Consider adding size validation for bloom filter

The bloom field represents an Ethereum bloom filter, which should be exactly 256 bytes. Consider adding validation to ensure the correct size.

-  bytes bloom = 2;
+  bytes bloom = 2 [
+    (gogoproto.moretags) = "yaml:\"bloom\"",
+    (validate.rules).bytes = {
+      len: 256
+    }
+  ];
proto/injective/evm/v1/params.proto (1)

11-24: Consider enhancing field documentation

While the current documentation is good, consider adding more details for critical fields:

  • evm_denom: Specify expected denomination format and examples
  • enable_create/enable_call: Document security implications and use cases
  • extra_eips: List commonly used EIPs or link to documentation
  • chain_config: Reference the chain configuration documentation
 // evm_denom represents the token denomination used to run the EVM state
 // transitions.
+// Format: {denomination}, Example: "inj"
 string evm_denom = 1 [(gogoproto.moretags) = "yaml:\"evm_denom\""];
 // enable_create toggles state transitions that use the vm.Create function
+// Security: Enables/disables contract deployment functionality
 bool enable_create = 2 [(gogoproto.moretags) = "yaml:\"enable_create\""];
 // enable_call toggles state transitions that use the vm.Call function
+// Security: Enables/disables contract execution functionality
 bool enable_call = 3 [(gogoproto.moretags) = "yaml:\"enable_call\""];
 // extra_eips defines the additional EIPs for the vm.Config
+// Common EIPs: 1559 (Fee Market), 2930 (Optional Access Lists)
 repeated int64 extra_eips = 4 [(gogoproto.customname) = "ExtraEIPs", (gogoproto.moretags) = "yaml:\"extra_eips\""];
proto/injective/feemarket/v1/feemarket.proto (2)

21-22: Consider adding validation for enable_height

The enable_height parameter will trigger network-wide changes in fee calculation. Consider implementing additional safeguards:

  • Ensure this height is coordinated across all validators
  • Add checks to prevent setting this to a past height
  • Consider adding a minimum notice period before activation

8-32: Enhance documentation for parameter constraints

While the field comments are good, consider adding:

  • Valid ranges for numeric parameters
  • Implications of different parameter combinations
  • Examples of how these parameters affect transaction costs

Example documentation enhancement:

 message Params {
   // no_base_fee forces the EIP-1559 base fee to 0 (needed for 0 price calls)
+  // Setting this to true will disable EIP-1559 fee mechanics
   bool no_base_fee = 1;
   // base_fee_change_denominator bounds the amount the base fee can change
   // between blocks.
+  // Recommended range: 8-12. Lower values allow faster fee adjustments
   uint32 base_fee_change_denominator = 2;
proto/injective/evm/v1/log.proto (1)

14-37: LGTM! Complete and well-structured Log message definition.

The message includes all necessary fields for Ethereum logs with proper JSON tags and handles chain reorganization scenarios.

Consider adding field examples in the comments to help developers understand the expected format, particularly for the address and topics fields.

  // address of the contract that generated the event
+ // Example: "0x1234567890123456789012345678901234567890"
  string address = 1;
  // topics is a list of topics provided by the contract.
+ // Example: ["0xddf252ad1be2c89b69c2b068fc378daa952ba7f163c4a11628f55a4df523b3ef"]
  repeated string topics = 2;
proto/injective/evm/v1/trace_config.proto (2)

16-33: Consider adding field validation and documentation

While the core configuration fields are well-structured, consider the following improvements:

  1. The timeout field as string type might benefit from validation or a more specific duration type
  2. The reexec field could use documentation about recommended/maximum values

Consider using a more specific type for timeout:

-  string timeout = 2;
+  google.protobuf.Duration timeout = 2;

34-43: Enhance documentation for advanced configuration fields

The advanced configuration fields could benefit from additional documentation:

  1. Add a reference to the expected JSON schema for tracer_json_config
  2. Document the expected format/structure of the binary data in state_overrides and block_overrides

Would you like me to help draft the enhanced documentation?

proto/injective/feemarket/v1/query.proto (3)

5-5: Remove or uncomment the pagination import based on requirements

The commented import suggests either:

  1. Incomplete cleanup of unused imports
  2. Preparation for future pagination support

Please either remove the commented line if not needed, or uncomment if pagination will be implemented.


43-46: Consider adding validation constraints for base_fee

The base_fee field uses a custom mathematical integer type for precision, which is good. However, consider adding validation constraints (e.g., minimum value) to ensure the base fee cannot be set to invalid values.

Example constraint annotation:

-  string base_fee = 1 [(gogoproto.customtype) = "cosmossdk.io/math.Int"];
+  string base_fee = 1 [
+    (gogoproto.customtype) = "cosmossdk.io/math.Int",
+    (validate.rules).string.min_len = "1"
+  ];

53-56: Consider adding range validation for gas field

The gas field should have validation to ensure it's non-negative and within reasonable bounds.

Example constraint:

-  int64 gas = 1;
+  int64 gas = 1 [(validate.rules).int64.gte = 0];
chain/evm/types/tx_data.go (1)

19-19: Track TODO: Consider embedding ethtypes.TxData

There's a TODO comment referencing an Ethereum issue that should be tracked and addressed when possible.

Would you like me to create a GitHub issue to track this TODO?

chain/evm/types/interfaces.go (2)

32-44: Document the behavior of virtual coin operations

The interface includes virtual methods for coin operations, but their behavior and differences from non-virtual counterparts are not documented.

Add documentation to clarify:

  • What "Virtual" operations mean in this context
  • How they differ from regular operations
  • When to use virtual vs. non-virtual methods

Example documentation:

// SendCoinsFromModuleToAccountVirtual performs a virtual coin transfer from a module to an account.
// Virtual operations [explain the difference and use cases here]

52-56: Add documentation for FeeMarketKeeper interface

The interface lacks documentation explaining its purpose and responsibilities.

Add comprehensive documentation:

// FeeMarketKeeper defines the expected interface for fee market operations.
// It provides access to base fee information and fee market parameters
// which are essential for EVM transaction processing.
proto/injective/evm/v1/chain_config.proto (1)

1-117: Consider adding versioning strategy

While the current implementation is solid, consider:

  1. Adding a version field to handle future Ethereum upgrades more gracefully
  2. Documenting the versioning strategy for future fork additions
  3. Including validation rules for block/time ordering

This will help maintain backward compatibility and make future upgrades smoother.

🧰 Tools
🪛 buf (1.47.2)

4-4: import "gogoproto/gogo.proto": file does not exist

(COMPILE)

chain/evm/types/legacy_tx.go (2)

20-22: Consider storing To address as bytes instead of hex string

Converting the address to/from hex string in getters/setters is inefficient. Consider storing it in its native bytes format.

 if to := tx.To(); to != nil {
-    txData.To = to.Hex()
+    txData.To = to.Bytes()
 }

93-101: Add documentation explaining gas price equivalence

The GetGasTipCap and GetGasFeeCap methods return the same value as GetGasPrice. Please add documentation explaining that this is intentional for legacy transactions where these concepts are equivalent.

-// GetGasTipCap returns the gas price field.
+// GetGasTipCap returns the gas price field. For legacy transactions,
+// the tip cap is equivalent to the gas price.
 func (tx *LegacyTx) GetGasTipCap() *big.Int {
     return tx.GetGasPrice()
 }

-// GetGasFeeCap returns the gas price field.
+// GetGasFeeCap returns the gas price field. For legacy transactions,
+// the fee cap is equivalent to the gas price.
 func (tx *LegacyTx) GetGasFeeCap() *big.Int {
     return tx.GetGasPrice()
 }
chain/evm/types/tx_args.go (1)

113-199: Consider breaking down the complex fee calculation logic.

While the implementation is correct, the method is quite complex, particularly around fee calculations. Consider extracting the fee calculation logic into separate methods for better maintainability.

Consider this refactoring:

+func (args *TransactionArgs) calculateFees(baseFee *big.Int) (gasPrice, gasFeeCap, gasTipCap *big.Int) {
+	if baseFee == nil {
+		// If there's no basefee, then it must be a non-1559 execution
+		gasPrice = new(big.Int)
+		if args.GasPrice != nil {
+			gasPrice = args.GasPrice.ToInt()
+		}
+		return gasPrice, gasPrice, gasPrice
+	}
+	
+	// A basefee is provided, necessitating 1559-type execution
+	if args.GasPrice != nil {
+		// User specified the legacy gas field, convert to 1559 gas typing
+		gasPrice = args.GasPrice.ToInt()
+		return gasPrice, gasPrice, gasPrice
+	}
+	
+	// User specified 1559 gas fields (or none), use those
+	gasFeeCap = new(big.Int)
+	if args.MaxFeePerGas != nil {
+		gasFeeCap = args.MaxFeePerGas.ToInt()
+	}
+	gasTipCap = new(big.Int)
+	if args.MaxPriorityFeePerGas != nil {
+		gasTipCap = args.MaxPriorityFeePerGas.ToInt()
+	}
+	
+	// Backfill the legacy gasPrice for EVM execution, unless we're all zeroes
+	gasPrice = new(big.Int)
+	if gasFeeCap.BitLen() > 0 || gasTipCap.BitLen() > 0 {
+		gasPrice = math.BigMin(new(big.Int).Add(gasTipCap, baseFee), gasFeeCap)
+	}
+	return
+}

Then update the ToMessage method to use this helper:

 func (args *TransactionArgs) ToMessage(globalGasCap uint64, baseFee *big.Int) (*core.Message, error) {
 	// Reject invalid combinations of pre- and post-1559 fee styles
 	if args.GasPrice != nil && (args.MaxFeePerGas != nil || args.MaxPriorityFeePerGas != nil) {
 		return nil, errors.New("both gasPrice and (maxFeePerGas or maxPriorityFeePerGas) specified")
 	}
 	
-	// ... fee calculation logic ...
+	gasPrice, gasFeeCap, gasTipCap := args.calculateFees(baseFee)
chain/evm/types/chain_config.go (1)

13-42: Consider adding support for newer Ethereum upgrades

While the implementation is solid, consider adding support for the latest Ethereum upgrades:

  • Dencun (Cancun + Deneb)
  • Verkle
 func (cc ChainConfig) EthereumConfig(chainID *big.Int) *params.ChainConfig {
 	cfg := &params.ChainConfig{
 		// ... existing config ...
 		ShanghaiTime:            getTimeValue(cc.ShanghaiTime),
 		CancunTime:              getTimeValue(cc.CancunTime),
 		PragueTime:              getTimeValue(cc.PragueTime),
+		// Consider adding:
+		VerkleTime:              getTimeValue(cc.VerkleTime),
 	}
 	return cfg
 }
proto/injective/evm/v1/tx.proto (1)

111-111: Fix typo in comment

"dinamic" should be "dynamic" in the comment.

-// DynamicFeeTx is the data of EIP-1559 dinamic fee transactions.
+// DynamicFeeTx is the data of EIP-1559 dynamic fee transactions.
chain/evm/types/errors.go (2)

16-39: Consider grouping related error codes

While the error codes are well-defined, consider grouping them by category for better maintainability. For example:

  • State-related errors (InvalidState, ChainConfigNotFound, etc.)
  • Operation-related errors (CreateDisabled, CallDisabled)
  • Gas-related errors (InvalidGasPrice, InvalidGasFee, GasOverflow)

199-216: Consider optimizing JSON marshaling

The toJSON method could be optimized:

  1. Consider pre-allocating the JSON buffer
  2. Use a sync.Pool for the abciLogVmError struct to reduce allocations
chain/evm/types/msg.go (4)

44-116: Add documentation for transaction type selection logic.

While the implementation is correct, consider adding documentation explaining the conditions that determine which transaction type is created:

  • Dynamic fee tx (EIP-1559) when gasFeeCap is provided
  • Access list tx (EIP-2930) when only accesses is provided
  • Legacy tx as fallback
 func newMsgEthereumTx(
 	chainID *big.Int, nonce uint64, to *common.Address, amount *big.Int,
 	gasLimit uint64, gasPrice, gasFeeCap, gasTipCap *big.Int, input []byte, accesses *ethtypes.AccessList,
 ) *MsgEthereumTx {
+	// Transaction type selection:
+	// 1. Dynamic fee transaction (EIP-1559) when gasFeeCap is provided
+	// 2. Access list transaction (EIP-2930) when only accesses is provided
+	// 3. Legacy transaction as fallback
 	var txData ethtypes.TxData

141-172: Consider adding size limit validations.

While the basic validation is thorough, consider adding size limit validations for:

  • Input data size to prevent excessive gas consumption
  • Address field length validation (should be exactly 20 bytes)
 func (msg MsgEthereumTx) ValidateBasic() error {
 	if len(msg.From) == 0 {
 		return errorsmod.Wrapf(errortypes.ErrInvalidRequest, "sender address is missing")
 	}
+	if len(msg.From) != common.AddressLength {
+		return errorsmod.Wrapf(errortypes.ErrInvalidRequest, "sender address must be %d bytes", common.AddressLength)
+	}

216-244: Enhance error handling in Sign method.

Consider adding validation for nil parameters and signature length:

  • Check if ethSigner is nil
  • Check if keyringSigner is nil
  • Validate signature length (should be 65 bytes for secp256k1)
 func (msg *MsgEthereumTx) Sign(ethSigner ethtypes.Signer, keyringSigner keyring.Signer) error {
+	if ethSigner == nil {
+		return fmt.Errorf("ethSigner cannot be nil")
+	}
+	if keyringSigner == nil {
+		return fmt.Errorf("keyringSigner cannot be nil")
+	}
 	from := msg.GetFrom()

351-381: Add validation for evmDenom parameter.

Consider validating the evmDenom parameter to ensure it's not empty and follows the denomination format.

 func (msg *MsgEthereumTx) BuildTx(b client.TxBuilder, evmDenom string) (authsigning.Tx, error) {
+	if len(evmDenom) == 0 {
+		return nil, errors.New("evmDenom cannot be empty")
+	}
 	builder, ok := b.(authtx.ExtensionOptionsTxBuilder)
chain/evm/types/compiled_contract.go (2)

17-19: Simplify MarshalJSON by removing unnecessary conversion

In the MarshalJSON method of HexString, the conversion to string(s) is unnecessary. You can directly format the byte slice s without converting it to a string.

Apply this diff to simplify the code:

func (s HexString) MarshalJSON() ([]byte, error) {
-	return json.Marshal(fmt.Sprintf("%x", string(s)))
+	return json.Marshal(fmt.Sprintf("%x", s))
}

91-117: Refactor repetitive code in the init() function

The init() function contains repetitive blocks for unmarshaling JSON data and checking the Bin length for each contract. Refactoring this code into a helper function will improve readability and maintainability.

Consider applying this refactor:

func loadContract(jsonData []byte, contract *CompiledContract) {
	if err := json.Unmarshal(jsonData, contract); err != nil {
		panic(err)
	}
	if len(contract.Bin) == 0 {
		panic("load contract failed")
	}
}

func init() {
	loadContract(erc20JSON, &ERC20Contract)
	loadContract(testMessageCallJSON, &TestMessageCall)
	loadContract(simpleStorageJSON, &SimpleStorageContract)
}
chain/evm/types/params.go (2)

103-115: Ensure consistent function naming for validation functions

The function validateEIPs is unexported (starts with a lowercase letter), while similar validation functions like ValidateEVMDenom and ValidateBool are exported. For consistency, consider either exporting validateEIPs or unexporting the others if they are intended for internal use only.


13-25: Clarify comments for default parameters

The comment for DefaultAllowUnprotectedTxs could be rephrased for better clarity. Currently, it states "rejects all unprotected txs (i.e false)", which might be confusing. Consider rewording it to clearly indicate the default behavior.

Apply this diff to improve the comment:

-// DefaultAllowUnprotectedTxs rejects all unprotected txs (i.e false)
+// DefaultAllowUnprotectedTxs indicates whether unprotected transactions are allowed (false by default)
chain/feemarket/types/params.go (2)

120-122: Simplify the condition in IsBaseFeeEnabled method.

The condition can be reordered for clarity. Checking height first may improve readability.

Consider applying this diff:

 func (p Params) IsBaseFeeEnabled(height int64) bool {
-	return !p.NoBaseFee && height >= p.EnableHeight
+	return height >= p.EnableHeight && !p.NoBaseFee
 }

This does not change the logic but may enhance readability by checking the numeric condition before the boolean flag.


87-110: Aggregate validation errors in the Validate method.

Currently, the Validate method returns upon the first error encountered. Consider collecting all validation errors to provide comprehensive feedback.

Here's how you could modify the method:

 func (p Params) Validate() error {
+	var errs []error
 	if p.BaseFeeChangeDenominator == 0 {
-		return fmt.Errorf("base fee change denominator cannot be 0")
+		errs = append(errs, fmt.Errorf("base fee change denominator cannot be 0"))
 	}
 	if p.BaseFee.IsNegative() {
-		return fmt.Errorf("initial base fee cannot be negative: %s", p.BaseFee)
+		errs = append(errs, fmt.Errorf("initial base fee cannot be negative: %s", p.BaseFee))
 	}
 	if p.EnableHeight < 0 {
-		return fmt.Errorf("enable height cannot be negative: %d", p.EnableHeight)
+		errs = append(errs, fmt.Errorf("enable height cannot be negative: %d", p.EnableHeight))
 	}
 	if err := validateMinGasMultiplier(p.MinGasMultiplier); err != nil {
-		return err
+		errs = append(errs, err)
 	}
 	if p.ElasticityMultiplier == 0 {
-		return fmt.Errorf("elasticity multiplier cannot be 0")
+		errs = append(errs, fmt.Errorf("elasticity multiplier cannot be 0"))
 	}
 	if err := validateMinGasPrice(p.MinGasPrice); err != nil {
-		return err
+		errs = append(errs, err)
 	}
+	if len(errs) > 0 {
+		return fmt.Errorf("validation errors: %v", errs)
+	}
 	return nil
 }

This approach collects all validation errors before returning, providing a complete list of issues to be addressed.

chain/evm/types/access_list_tx.go (1)

184-224: Include validation for the Accesses (access list) field

Currently, the Validate() method does not validate the Accesses field. Invalid entries in the access list could lead to issues during transaction execution. Consider adding validation to ensure that each address and storage key in the access list is well-formed.

You might add validation like:

if tx.Accesses != nil {
	for _, access := range tx.Accesses.AccessList {
		if err := types.ValidateAddress(access.Address); err != nil {
			return errorsmod.Wrap(err, "invalid address in access list")
		}
		for _, key := range access.StorageKeys {
			if len(key) != 32 {
				return errorsmod.Wrapf(ErrInvalidStorageKey, "invalid storage key length: %d", len(key))
			}
		}
	}
}

This ensures that all entries in the access list are valid and conform to expected formats.

chain/evm/types/dynamic_fee_tx.go (1)

215-215: Improve error messages: use 'out of bounds'

The error messages use "out of bound"; it's more conventional to say "out of bounds".

Apply this diff to update the error messages:

-		return errorsmod.Wrap(ErrInvalidGasCap, "out of bound")
+		return errorsmod.Wrap(ErrInvalidGasCap, "out of bounds")

Similarly, update lines 230 and 239:

-		return errorsmod.Wrap(ErrInvalidGasFee, "out of bound")
+		return errorsmod.Wrap(ErrInvalidGasFee, "out of bounds")
-		return errorsmod.Wrap(ErrInvalidAmount, "out of bound")
+		return errorsmod.Wrap(ErrInvalidAmount, "out of bounds")

Also applies to: 230-230, 239-239

chain/evm/types/utils.go (3)

26-26: Consider unexporting DefaultPriorityReduction if not used outside the package.

If DefaultPriorityReduction is intended for internal use only, consider making it unexported by renaming it to defaultPriorityReduction to limit its visibility.

Apply this diff if appropriate:

-var DefaultPriorityReduction = sdk.DefaultPowerReduction
+var defaultPriorityReduction = sdk.DefaultPowerReduction

209-226: Enhance error messages for better clarity in BinSearch function.

In the BinSearch function, consider providing more descriptive error messages when returning errors. This will improve debuggability and maintainability.

For example, you might modify the error handling as follows:

-			return 0, err
+			return 0, fmt.Errorf("binary search executable function failed at gas limit %d: %w", mid, err)

235-240: Optimize HexAddress function using existing utilities.

Consider using common.BytesToAddress(a).Hex() instead of manually encoding the Ethereum address. This leverages well-tested library code and improves readability.

Apply this diff to simplify the function:

-func HexAddress(a []byte) string {
-	var buf [common.AddressLength*2 + 2]byte
-	copy(buf[:2], "0x")
-	hex.Encode(buf[2:], a)
-	return string(buf[:])
+func HexAddress(a []byte) string {
+	return common.BytesToAddress(a).Hex()
 }
proto/injective/evm/v1/query.proto (1)

88-89: Simplify repetitive gogoproto options in message definitions.

The option (gogoproto.equal) = false; and option (gogoproto.goproto_getters) = false; statements are repeated in multiple message definitions. While this is syntactically correct, it may lead to clutter and reduced readability.

Consider defining these options at the file level if they apply to all messages, or remove them from individual messages where they are not necessary. This can make the code cleaner and more maintainable.

For example, at the top of the file, specify:

option (gogoproto.equal_all) = false;
option (gogoproto.goproto_getters_all) = false;

Then, remove the individual options from each message definition.

Also applies to: 108-109, 129-130, 149-150

📜 Review details

Configuration used: .coderabbit.yaml
Review profile: CHILL

📥 Commits

Reviewing files that changed from the base of the PR and between 8e89a61 and a074c61.

⛔ Files ignored due to path filters (17)
  • chain/evm/types/access_tuple.pb.go is excluded by !**/*.pb.go
  • chain/evm/types/chain_config.pb.go is excluded by !**/*.pb.go
  • chain/evm/types/events.pb.go is excluded by !**/*.pb.go
  • chain/evm/types/genesis.pb.go is excluded by !**/*.pb.go
  • chain/evm/types/log.pb.go is excluded by !**/*.pb.go
  • chain/evm/types/params.pb.go is excluded by !**/*.pb.go
  • chain/evm/types/query.pb.go is excluded by !**/*.pb.go
  • chain/evm/types/state.pb.go is excluded by !**/*.pb.go
  • chain/evm/types/trace_config.pb.go is excluded by !**/*.pb.go
  • chain/evm/types/transaction_logs.pb.go is excluded by !**/*.pb.go
  • chain/evm/types/tx.pb.go is excluded by !**/*.pb.go
  • chain/evm/types/tx_result.pb.go is excluded by !**/*.pb.go
  • chain/feemarket/types/events.pb.go is excluded by !**/*.pb.go
  • chain/feemarket/types/feemarket.pb.go is excluded by !**/*.pb.go
  • chain/feemarket/types/genesis.pb.go is excluded by !**/*.pb.go
  • chain/feemarket/types/query.pb.go is excluded by !**/*.pb.go
  • chain/feemarket/types/tx.pb.go is excluded by !**/*.pb.go
📒 Files selected for processing (51)
  • .gitignore (1 hunks)
  • Makefile (1 hunks)
  • chain/evm/types/access_list.go (1 hunks)
  • chain/evm/types/access_list_tx.go (1 hunks)
  • chain/evm/types/chain_config.go (1 hunks)
  • chain/evm/types/codec.go (1 hunks)
  • chain/evm/types/compiled_contract.go (1 hunks)
  • chain/evm/types/dynamic_fee_tx.go (1 hunks)
  • chain/evm/types/errors.go (1 hunks)
  • chain/evm/types/eth.go (1 hunks)
  • chain/evm/types/events.go (1 hunks)
  • chain/evm/types/genesis.go (1 hunks)
  • chain/evm/types/interfaces.go (1 hunks)
  • chain/evm/types/key.go (1 hunks)
  • chain/evm/types/legacy_tx.go (1 hunks)
  • chain/evm/types/logs.go (1 hunks)
  • chain/evm/types/msg.go (1 hunks)
  • chain/evm/types/params.go (1 hunks)
  • chain/evm/types/protocol.go (1 hunks)
  • chain/evm/types/query.go (1 hunks)
  • chain/evm/types/response.go (1 hunks)
  • chain/evm/types/storage.go (1 hunks)
  • chain/evm/types/tracer.go (1 hunks)
  • chain/evm/types/tx.go (1 hunks)
  • chain/evm/types/tx_args.go (1 hunks)
  • chain/evm/types/tx_data.go (1 hunks)
  • chain/evm/types/utils.go (1 hunks)
  • chain/feemarket/types/codec.go (1 hunks)
  • chain/feemarket/types/events.go (1 hunks)
  • chain/feemarket/types/genesis.go (1 hunks)
  • chain/feemarket/types/interfaces.go (1 hunks)
  • chain/feemarket/types/keys.go (1 hunks)
  • chain/feemarket/types/msg.go (1 hunks)
  • chain/feemarket/types/params.go (1 hunks)
  • proto/injective/evm/v1/access_tuple.proto (1 hunks)
  • proto/injective/evm/v1/chain_config.proto (1 hunks)
  • proto/injective/evm/v1/events.proto (1 hunks)
  • proto/injective/evm/v1/genesis.proto (1 hunks)
  • proto/injective/evm/v1/log.proto (1 hunks)
  • proto/injective/evm/v1/params.proto (1 hunks)
  • proto/injective/evm/v1/query.proto (1 hunks)
  • proto/injective/evm/v1/state.proto (1 hunks)
  • proto/injective/evm/v1/trace_config.proto (1 hunks)
  • proto/injective/evm/v1/transaction_logs.proto (1 hunks)
  • proto/injective/evm/v1/tx.proto (1 hunks)
  • proto/injective/evm/v1/tx_result.proto (1 hunks)
  • proto/injective/feemarket/v1/events.proto (1 hunks)
  • proto/injective/feemarket/v1/feemarket.proto (1 hunks)
  • proto/injective/feemarket/v1/genesis.proto (1 hunks)
  • proto/injective/feemarket/v1/query.proto (1 hunks)
  • proto/injective/feemarket/v1/tx.proto (1 hunks)
✅ Files skipped from review due to trivial changes (1)
  • chain/feemarket/types/keys.go
🚧 Files skipped from review as they are similar to previous changes (23)
  • .gitignore
  • Makefile
  • chain/evm/types/access_list.go
  • chain/evm/types/codec.go
  • chain/evm/types/eth.go
  • chain/evm/types/events.go
  • chain/evm/types/genesis.go
  • chain/evm/types/key.go
  • chain/evm/types/logs.go
  • chain/evm/types/protocol.go
  • chain/evm/types/query.go
  • chain/evm/types/response.go
  • chain/evm/types/storage.go
  • chain/evm/types/tracer.go
  • chain/evm/types/tx.go
  • chain/feemarket/types/codec.go
  • chain/feemarket/types/events.go
  • chain/feemarket/types/genesis.go
  • chain/feemarket/types/interfaces.go
  • chain/feemarket/types/msg.go
  • proto/injective/evm/v1/events.proto
  • proto/injective/evm/v1/state.proto
  • proto/injective/feemarket/v1/events.proto
🧰 Additional context used
🪛 buf (1.47.2)
proto/injective/evm/v1/access_tuple.proto

4-4: import "gogoproto/gogo.proto": file does not exist

(COMPILE)

proto/injective/evm/v1/chain_config.proto

4-4: import "gogoproto/gogo.proto": file does not exist

(COMPILE)

proto/injective/evm/v1/genesis.proto

4-4: import "injective/evm/v1/params.proto": file does not exist

(COMPILE)

proto/injective/evm/v1/log.proto

4-4: import "gogoproto/gogo.proto": file does not exist

(COMPILE)

proto/injective/evm/v1/params.proto

4-4: import "gogoproto/gogo.proto": file does not exist

(COMPILE)

proto/injective/evm/v1/query.proto

4-4: import "cosmos/base/query/v1beta1/pagination.proto": file does not exist

(COMPILE)

proto/injective/evm/v1/trace_config.proto

4-4: import "gogoproto/gogo.proto": file does not exist

(COMPILE)

proto/injective/evm/v1/transaction_logs.proto

4-4: import "injective/evm/v1/log.proto": file does not exist

(COMPILE)

proto/injective/evm/v1/tx.proto

4-4: import "cosmos/msg/v1/msg.proto": file does not exist

(COMPILE)

proto/injective/evm/v1/tx_result.proto

4-4: import "gogoproto/gogo.proto": file does not exist

(COMPILE)

proto/injective/feemarket/v1/feemarket.proto

4-4: import "gogoproto/gogo.proto": file does not exist

(COMPILE)

proto/injective/feemarket/v1/genesis.proto

4-4: import "injective/feemarket/v1/feemarket.proto": file does not exist

(COMPILE)

proto/injective/feemarket/v1/query.proto

4-4: import "gogoproto/gogo.proto": file does not exist

(COMPILE)

proto/injective/feemarket/v1/tx.proto

4-4: import "cosmos/msg/v1/msg.proto": file does not exist

(COMPILE)

🔇 Additional comments (50)
proto/injective/evm/v1/access_tuple.proto (2)

1-7: LGTM! File header and imports are well-structured.

The protobuf configuration follows best practices with proper syntax, package naming, and import declarations.

🧰 Tools
🪛 buf (1.47.2)

4-4: import "gogoproto/gogo.proto": file does not exist

(COMPILE)


1-16: Verify integration with related EVM files.

Let's ensure this AccessTuple definition aligns with other EVM-related files and Ethereum specifications.

✅ Verification successful

Let me gather more information about the implementation details to ensure complete verification.


AccessTuple implementation is properly integrated and aligned with EIP-2930

The verification shows that:

  • The AccessTuple proto definition is correctly imported and used in tx.proto for both AccessListTx (EIP-2930) and DynamicFeeTx (EIP-1559) messages
  • The implementation in Go (access_list.go) properly converts between Ethereum core types and the proto-defined AccessTuple
  • The structure maintains compatibility with Ethereum specifications, containing the required address and storage keys fields
  • The type is used consistently across the EVM module for access list transactions
🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Check for related proto files and AccessTuple usage
echo "Checking for related proto files..."
fd -e proto | xargs rg "AccessTuple"

echo "Checking for imports of this proto..."
rg 'import.*access_tuple\.proto'

# Verify alignment with EIP-2930 access list structure
echo "Checking for EIP-2930 related files..."
rg -l "EIP-2930|AccessList|access list"

Length of output: 1130


Script:

#!/bin/bash
# Check the implementation details in Go files
echo "Checking AccessTuple implementation in Go..."
rg -A 5 "type AccessTuple" chain/evm/types/

# Check tx.proto for AccessTuple usage context
echo "Checking tx.proto content..."
cat proto/injective/evm/v1/tx.proto

# Check access list implementation
echo "Checking access list implementation..."
rg -A 5 "AccessList" chain/evm/types/access_list.go

Length of output: 9530

🧰 Tools
🪛 buf (1.47.2)

4-4: import "gogoproto/gogo.proto": file does not exist

(COMPILE)

proto/injective/evm/v1/transaction_logs.proto (2)

11-16: LGTM! Message structure follows proto3 best practices

The TransactionLogs message is well-structured with:

  • Clear field numbering
  • Appropriate use of field types (string for hash, repeated for logs)
  • Descriptive field comments

4-4: Verify the existence of the imported proto file

The static analysis indicates that the imported file injective/evm/v1/log.proto does not exist. This import is critical as it provides the Log message type used in TransactionLogs.

Let's verify if the file exists or needs to be copied as part of this PR:

✅ Verification successful

Import path is valid and file exists

The verification shows that injective/evm/v1/log.proto exists at the correct location in the repository, and it's part of a consistent set of EVM-related proto files. The import statement is correctly referencing this file.

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Check for the existence of the log.proto file and related EVM proto files

# Search for log.proto file
echo "Searching for log.proto file..."
fd --type f "log.proto$"

# Check if there are any other EVM-related proto files
echo "Checking for other EVM-related proto files..."
fd --type f ".proto$" | grep -i "evm"

Length of output: 726

🧰 Tools
🪛 buf (1.47.2)

4-4: import "injective/evm/v1/log.proto": file does not exist

(COMPILE)

proto/injective/feemarket/v1/genesis.proto (2)

10-20: LGTM! Well-structured genesis state definition

The GenesisState message is well-documented and properly structured:

  • Non-nullable params with proper gogoproto annotation
  • Clean deprecation handling for base_fee
  • Clear documentation for all fields

17-19: Verify block_gas validation in application code

While the comment indicates block_gas should be "Zero by default" (which is already guaranteed by proto3 for uint64), ensure there's proper validation logic in the application code if there are any specific constraints on this value during genesis initialization.

proto/injective/evm/v1/tx_result.proto (2)

9-28: LGTM! Well-structured message definition

The TxResult message is well-designed with appropriate field types and clear documentation. The use of non-nullable for tx_logs and the inclusion of essential transaction result fields like gas_used and reverted is good practice.


4-4: Verify gogoproto dependency setup

The import looks correct, but please ensure that the gogoproto dependency is properly set up in the project's build system and protocol buffer generation workflow.

✅ Verification successful

gogoproto dependency is properly configured

The gogoproto import is valid and correctly used throughout the codebase:

  • The dependency is properly declared in go.mod (github.com/gogo/protobuf v1.3.2)
  • The import pattern is consistently used across 65+ proto files in the project
  • The usage in tx_result.proto follows the same pattern as other proto files in the codebase
🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Check if gogoproto is properly set up in the project

# Check for buf.yaml configuration
if [ -f "buf.yaml" ]; then
    echo "Checking buf.yaml for gogoproto dependency..."
    cat buf.yaml
fi

# Check for other common proto dependency configurations
fd -t f "go.mod|go.sum" -x grep -l "gogo/protobuf"

Length of output: 90


Script:

#!/bin/bash
# Let's check the actual content of go.mod and buf.yaml for gogoproto dependency

# Check go.mod content
echo "=== go.mod content ==="
cat go.mod | grep -A 2 "gogo/protobuf"

# Check if buf.yaml exists and its content
if [ -f "buf.yaml" ]; then
    echo -e "\n=== buf.yaml content ==="
    cat buf.yaml
fi

# Check for other .proto files using gogoproto to verify consistent usage
echo -e "\n=== Other .proto files using gogoproto ==="
rg "import.*gogoproto/gogo.proto" "proto/"

Length of output: 5576

🧰 Tools
🪛 buf (1.47.2)

4-4: import "gogoproto/gogo.proto": file does not exist

(COMPILE)

proto/injective/evm/v1/genesis.proto (2)

10-16: LGTM! Well-structured genesis state definition

The GenesisState message is well-defined with clear field descriptions and appropriate use of gogoproto options for non-nullable fields.


4-6: Verify the availability of imported proto files

The static analysis indicates that params.proto is missing. This dependency is critical as it's required for the Params type used in GenesisState.

🧰 Tools
🪛 buf (1.47.2)

4-4: import "injective/evm/v1/params.proto": file does not exist

(COMPILE)

proto/injective/evm/v1/params.proto (2)

1-8: LGTM! File setup follows protobuf best practices

The package declaration, imports, and go_package option are properly configured.

🧰 Tools
🪛 buf (1.47.2)

4-4: import "gogoproto/gogo.proto": file does not exist

(COMPILE)


22-24: Verify security implications of allow_unprotected_txs

The allow_unprotected_txs flag could expose the system to replay attacks if enabled. Please ensure this is thoroughly documented and that appropriate warnings are in place.

Let's check for any existing documentation or usage patterns:

✅ Verification successful

Let me gather more information about the security implications by checking for any EVM transaction handling code and configuration:


Based on the search results, I can now generate the final response:

Security implications of allow_unprotected_txs are properly documented and controlled

The codebase shows proper handling of unprotected transactions through:

  • Clear documentation in proto definition stating these are "non EIP155 signed" transactions
  • Integration with chain configuration that defines EIP155 block activation
  • Proper validation in transaction handling code that enforces chain ID checks
  • Default protection through EIP-155 replay protection unless explicitly allowed

The flag serves a legitimate purpose for backward compatibility while having appropriate security controls in place.

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Search for documentation or usage of allow_unprotected_txs
rg -A 5 "allow_unprotected_txs" 

# Look for any security-related comments or docs
rg -A 5 "replay attack|transaction replay|unprotected transaction"

Length of output: 2205


Script:

#!/bin/bash
# Search for EVM transaction handling code and security checks
rg -A 10 "func.*ProcessTransaction|func.*ApplyTransaction|func.*ValidateTransaction" 

# Look for EIP-155 related code and configuration
rg -A 5 "EIP155|ChainID"

# Check for any security documentation in README or docs
fd -e md | xargs rg -l "security|transaction|evm"

Length of output: 34747

proto/injective/feemarket/v1/tx.proto (3)

19-31: LGTM! Well-structured message definitions

The message definitions follow protobuf best practices with:

  • Appropriate use of protobuf options
  • Clear documentation
  • Proper request/response structure
  • Standard governance parameter update pattern

4-4: Verify the import path for cosmos msg proto

The static analysis indicates that cosmos/msg/v1/msg.proto file is missing. This could cause compilation issues.

✅ Verification successful

Import path cosmos/msg/v1/msg.proto is valid and widely used

The import is correct and consistently used across multiple proto files in the codebase. The search results show that this import is used in many other tx.proto files:

  • proto/injective/wasmx/v1/tx.proto
  • proto/injective/tokenfactory/v1beta1/tx.proto
  • proto/injective/evm/v1/tx.proto
  • proto/injective/oracle/v1beta1/tx.proto
  • proto/injective/exchange/v1beta1/tx.proto
    And several others following the same pattern.
🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Check if the cosmos msg proto file exists in the repository or its dependencies

# Search for the file in the repository
fd --type f "msg.proto" 

# Check if there are any other cosmos proto imports in the codebase
rg --type proto "import.*cosmos/msg"

Length of output: 92


Script:

#!/bin/bash
# Search for any .proto files in the repository
fd -e proto

# Search for cosmos/msg import pattern in all files (without file type restriction)
rg "import.*cosmos/msg"

# Search for other cosmos-related proto imports to understand the import pattern
rg "import.*cosmos/" -A 1

Length of output: 13077

🧰 Tools
🪛 buf (1.47.2)

4-4: import "cosmos/msg/v1/msg.proto": file does not exist

(COMPILE)


1-31: Verify completeness of the implementation

According to the AI summary, this file should include several additional message types that are currently missing:

  • MsgEthereumTx
  • LegacyTx
  • AccessListTx
  • DynamicFeeTx
  • MsgEthereumTxResponse

Please verify if these types should be included in this file or if they will be added in a separate PR.

🧰 Tools
🪛 buf (1.47.2)

4-4: import "cosmos/msg/v1/msg.proto": file does not exist

(COMPILE)

proto/injective/feemarket/v1/feemarket.proto (2)

4-4: Verify gogoproto dependency is properly configured

The import statement requires the gogoproto package. Please ensure it's properly configured in your build system.

✅ Verification successful

Import of gogoproto/gogo.proto is properly configured and widely used

The import of gogoproto/gogo.proto is consistent with the codebase pattern, as evidenced by its usage across 63 other proto files in the repository, including related feemarket proto files. This is a standard dependency in the project's protobuf ecosystem.

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Check if buf.yaml or similar proto config files exist and contain gogoproto
fd -e yaml -e yml . | xargs grep -l "gogoproto"

# Check if other proto files also use gogoproto
fd -e proto . | xargs grep -l "gogoproto/gogo.proto"

Length of output: 3114

🧰 Tools
🪛 buf (1.47.2)

4-4: import "gogoproto/gogo.proto": file does not exist

(COMPILE)


24-31: Verify numeric type precision requirements

The use of cosmossdk.io/math.Int and cosmossdk.io/math.LegacyDec for financial calculations is appropriate. However, please verify:

  • That math.Int provides sufficient precision for base_fee
  • The implications of using LegacyDec vs newer alternatives
✅ Verification successful

Based on the search results, I can provide a final response since we have sufficient information about the usage of these numeric types in the codebase:

Numeric type choices are appropriate for the fee market context

The usage of math.Int for base_fee and math.LegacyDec for gas price parameters is consistent with their requirements:

  • math.Int is used extensively throughout the codebase for block numbers, fees, and amounts where whole number precision is needed
  • math.LegacyDec is used consistently for gas prices, rates, and multipliers where decimal precision is required
  • The LegacyDec type, while marked as legacy, is still the standard decimal type used throughout the exchange, oracle and other core modules
🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Check for other usages of these types in the codebase
rg "cosmossdk.io/math.Int" -A 2
rg "cosmossdk.io/math.LegacyDec" -A 2

# Look for any migration notes or discussions about LegacyDec
fd . -e md | xargs rg "LegacyDec"

Length of output: 102679

proto/injective/evm/v1/log.proto (2)

8-13: LGTM! Well-documented message purpose and field types.

The documentation clearly distinguishes between consensus and derived fields, which is crucial for developers working with the Log message.


4-4: Verify gogoproto dependency availability

Ensure that the gogoproto dependency is properly set up in the sdk-go repository.

✅ Verification successful

Gogoproto dependency is properly configured

The verification shows that gogoproto is correctly set up in the repository:

  • The dependency is properly declared in go.mod: github.com/cosmos/gogoproto v1.5.0
  • The import is consistently used across multiple proto files in the codebase
  • The file proto/injective/evm/v1/log.proto follows the same import pattern as other proto files
🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Check if gogoproto is properly set up
fd -t f "gogo.proto" 

Length of output: 20


Script:

#!/bin/bash
# Check for go.mod dependencies related to gogoproto
grep -i "gogo" go.mod

# Check for proto files importing gogoproto
rg "import.*gogoproto/gogo.proto"

# Look for any references to gogoproto in build or dependency files
fd -t f "go.mod|go.sum|*.toml|*.yaml|*.yml" --exec grep -l "gogo"

Length of output: 5812

🧰 Tools
🪛 buf (1.47.2)

4-4: import "gogoproto/gogo.proto": file does not exist

(COMPILE)

proto/injective/evm/v1/trace_config.proto (2)

9-15: LGTM! Well-structured deprecation handling

The deprecation of disable_memory and disable_return_data fields is properly handled using the reserved keyword, and the documentation clearly indicates the migration path to the new enable_* fields.


1-8: Verify gogoproto dependency availability

The import paths and package declaration look correct. However, let's ensure the gogoproto dependency is properly set up.

✅ Verification successful

Gogoproto dependency is properly configured

The import of gogoproto/gogo.proto is valid as the project correctly depends on buf.build/cosmos/gogo-proto in both buf.yaml and buf.lock files. This is a standard setup in Cosmos SDK-based projects, and the dependency is properly versioned and locked.

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Check if gogoproto is properly configured in the project
# Expected: Find buf.yaml or similar config files that include gogoproto

# Check for buf configuration
fd -t f "buf\.(yaml|json|lock)"

# Check for other common proto config files
fd -t f "(buf\.gen|protoc)\.yaml"

Length of output: 99


Script:

#!/bin/bash
# Check the content of buf.yaml and buf.lock to verify gogoproto dependency
echo "=== buf.yaml content ==="
cat proto/buf.yaml

echo -e "\n=== buf.lock content ==="
cat proto/buf.lock

# Check if gogoproto files exist in the proto directory
echo -e "\n=== Searching for gogoproto files ==="
fd "gogo\.proto" proto/

Length of output: 1394

🧰 Tools
🪛 buf (1.47.2)

4-4: import "gogoproto/gogo.proto": file does not exist

(COMPILE)

proto/injective/feemarket/v1/query.proto (1)

12-27: LGTM! Well-structured Query service definition

The Query service is well-designed with:

  • Clear method documentation
  • Proper HTTP GET mappings
  • Logical endpoint paths
chain/evm/types/tx_data.go (4)

1-8: LGTM!

The imports are clean and appropriate for the functionality being implemented.


10-14: LGTM! Good use of compile-time interface compliance checking.

The type assertions ensure that all transaction types properly implement the TxData interface, catching any implementation issues at compile time.


18-48: LGTM! Well-designed interface covering all Ethereum transaction aspects.

The interface provides a comprehensive set of methods for handling Ethereum transactions, including:

  • Basic transaction data access
  • Signature management
  • Fee calculation
  • Validation

70-98: LGTM! Well-implemented EIP-155 chain ID derivation.

The function correctly implements the chain ID derivation according to EIP-155 with proper input validation and clear documentation.

chain/evm/types/interfaces.go (2)

67-74: LGTM! Well-documented parameter migration types

The types are well-defined and their purpose for x/params migration is clearly documented.


61-65: Verify PostTxProcessing error handling in implementations

The comment indicates that returning an error will revert the whole transaction. This is a critical behavior that needs careful implementation.

proto/injective/evm/v1/chain_config.proto (3)

76-78: LGTM! Proper handling of deprecated fields

The deprecated fields are correctly handled by:

  1. Using the reserved keyword for both field numbers and names
  2. Including clear documentation about the deprecation
  3. Following proto3 best practices

Also applies to: 89-91


4-4: Verify the gogoproto import path

The static analysis reports that "gogoproto/gogo.proto" file is missing. Please ensure that:

  1. The gogoproto dependency is properly installed
  2. The import path is correct in your development environment
✅ Verification successful

The gogoproto import is correctly used across the codebase

The import of "gogoproto/gogo.proto" is consistently used across multiple proto files in the codebase, including other files in the same evm/v1 package. This indicates that the import path is correct and the dependency is properly set up in the development environment.

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Check if gogoproto is properly set up
fd -e proto | xargs grep -l "gogoproto/gogo.proto"

Length of output: 3064

🧰 Tools
🪛 buf (1.47.2)

4-4: import "gogoproto/gogo.proto": file does not exist

(COMPILE)


8-10: Verify the impact of using sdkmath.Int

The switch from *big.Int to *sdkmath.Int is a significant change. Please ensure that:

  1. All dependent code is updated to handle sdkmath.Int
  2. There are no precision or compatibility issues with existing Ethereum implementations
✅ Verification successful

Let me gather more information about the usage and conversion between these types.


Let me check one final thing to verify the conversion between types.


Let me check the conversion helper function to complete the verification.


The switch to sdkmath.Int is properly handled

The codebase shows a well-implemented conversion between types:

  • The proto definition correctly uses cosmossdk.io/math.Int for all block numbers
  • The EthereumConfig method properly converts from sdkmath.Int to big.Int using BigIntMut()
  • The getBlockValue helper function handles nil and negative cases appropriately
🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Search for big.Int usage that might need updating
rg --type go "big\.Int.*ChainConfig" 

Length of output: 147


Script:

#!/bin/bash
# Check the implementation of ChainConfig in Go
ast-grep --pattern 'type ChainConfig struct {
  $$$
}'

# Check for sdkmath.Int usage with ChainConfig
rg --type go "sdkmath\.Int.*ChainConfig" -A 3

# Look at the actual proto definition
cat proto/injective/evm/v1/chain_config.proto

Length of output: 12507


Script:

#!/bin/bash
# Check the EthereumConfig method implementation to see how the conversion is handled
rg -A 10 "func.*EthereumConfig.*big\.Int.*ChainConfig" 

Length of output: 1017


Script:

#!/bin/bash
# Check the getBlockValue implementation
ast-grep --pattern 'func getBlockValue($_) $_ {
  $$$
}'

Length of output: 439

chain/evm/types/legacy_tx.go (2)

204-217: Implementation of effective price/fee methods looks good

The effective gas price, fee, and cost methods are correctly implemented for legacy transactions, maintaining compatibility with the interface while properly documenting that they return the same values as their non-effective counterparts.


146-157: Verify the ignored chainId parameter in SetSignatureValues

The first parameter (chainId) is ignored in the implementation. If this is intentional, please document why. If not, consider if it should be used to validate the signature values.

✅ Verification successful

Intentionally ignored chainId in LegacyTx is correct

The implementation is correct as is. Looking at the codebase:

  • The TxData interface in tx_data.go defines SetSignatureValues(chainID, v, r, s *big.Int)
  • Both DynamicFeeTx and AccessListTx implementations use the chainID parameter
  • Only LegacyTx explicitly ignores it with _

This is intentional because:

  1. Legacy transactions handle chainId differently - it's encoded within the v value itself as per EIP-155
  2. Other transaction types (Dynamic Fee and Access List) are post-EIP-155 and handle chainId separately
🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Search for other implementations of SetSignatureValues to understand the expected usage of chainId
ast-grep --pattern 'SetSignatureValues($CHAIN_ID, $_, $_, $_) {
  $$$
}'

Length of output: 74


Script:

#!/bin/bash
# Let's search for any references to SetSignatureValues and chainId to understand the context better
rg -A 5 "SetSignatureValues" 

# Also search for any interfaces or types that might define this method
ast-grep --pattern 'interface $_ {
  $$$
  SetSignatureValues($$$)
  $$$
}'

# Look for any tests that might show the intended usage
rg -A 5 "SetSignatureValues.*test"

Length of output: 2751

chain/evm/types/tx_args.go (3)

15-38: LGTM! Well-documented struct definition.

The TransactionArgs struct is well-designed, covering all necessary fields for both legacy and EIP-1559 transactions. The source of duplication and backward compatibility considerations are properly documented.


201-207: LGTM! Safe handling of nil From address.

The method correctly handles the nil case by returning a zero address.


209-218: LGTM! Correct implementation of backward compatibility.

The method properly implements the backward compatibility by prioritizing the Input field over Data, as documented in the struct definition.

chain/evm/types/chain_config.go (2)

1-11: LGTM!

The package structure and imports are well-organized, using appropriate dependencies.


162-164: Verify fork order implementation

Let's verify that the fork order check is working as expected.

✅ Verification successful

Based on the information gathered, I can now provide a final response:

Fork order check is properly implemented through go-ethereum dependency

The code correctly implements fork order validation by:

  1. Converting the chain configuration to Ethereum's native format via EthereumConfig()
  2. Utilizing go-ethereum's built-in CheckConfigForkOrder() from the params package
  3. Properly mapping all fork blocks (HomesteadBlock, DAOForkBlock, EIP150Block, etc.) in the conversion

The implementation is safe as it relies on the well-tested upstream go-ethereum validation logic rather than reimplementing it.

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Search for CheckConfigForkOrder implementation and tests
# to ensure proper fork order validation

# Look for CheckConfigForkOrder implementation
echo "Searching for CheckConfigForkOrder implementation..."
rg -A 10 "CheckConfigForkOrder"

# Look for related tests
echo "Searching for related tests..."
fd -e go -e _test.go | xargs rg "TestChainConfig|TestValidate"

Length of output: 942


Script:

#!/bin/bash
# Let's search for the EthereumConfig method implementation and related fork order checks

# Search for EthereumConfig implementation
echo "Searching for EthereumConfig implementation..."
ast-grep --pattern 'func (cc $_) EthereumConfig($_) $_'

# Search for fork-related configurations and validations
echo "Searching for fork-related configurations..."
rg -A 5 "Fork.*Block" chain/evm/types/

# Search for test files specifically in chain/evm/types directory
echo "Searching for test files..."
fd -e _test.go . chain/evm/types/

Length of output: 7396


Script:

#!/bin/bash
# Let's check the params package for CheckConfigForkOrder implementation
# since EthereumConfig returns *params.ChainConfig

# Search for CheckConfigForkOrder in go.mod to find the ethereum package
echo "Searching for ethereum package in go.mod..."
rg "github.com/ethereum/go-ethereum" go.mod

# Search for CheckConfigForkOrder in vendor directory
echo "Searching for CheckConfigForkOrder implementation in vendor..."
rg -A 10 "func.*CheckConfigForkOrder" vendor/

# Search for chain config tests
echo "Searching for chain config tests..."
rg -A 10 "func Test.*ChainConfig" chain/evm/types/

Length of output: 546

proto/injective/evm/v1/tx.proto (3)

15-25: LGTM! Well-structured service definition

The service definition follows best practices with:

  • Clear documentation for each RPC method
  • Proper HTTP endpoint configuration for EthereumTx
  • Governance-controlled parameter updates

28-189: LGTM! Well-structured message definitions

The message definitions follow Protocol Buffer best practices:

  • Proper use of custom types for blockchain values
  • Clear interface implementations
  • Consistent field types across messages
  • Well-documented fields and deprecations
  • Proper governance controls for parameter updates

4-4: Verify the import path for cosmos message types

The import path "cosmos/msg/v1/msg.proto" appears to be invalid. This could indicate a missing dependency or incorrect import path.

✅ Verification successful

Let me gather more information to verify if this import is actually valid and being used correctly in other files.


Let me check the buf.yaml configuration to understand the proto dependencies setup.


Import path "cosmos/msg/v1/msg.proto" is valid and correctly configured

The import is valid because:

  1. The project correctly depends on cosmos-sdk proto files through buf dependency buf.build/cosmos/cosmos-sdk:v0.50.5
  2. Multiple files in the codebase successfully use this import
  3. The import is consistently used across various transaction proto files for the cosmos message service option
🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Check if the cosmos proto files are available in the repository
# and verify the correct import path

# Search for cosmos proto files
fd -e proto -x dirname {} \; | sort -u | grep -i cosmos

# Check if there are any references to the correct import path
rg -l "cosmos/msg/v1/msg.proto" -g "*.proto"

Length of output: 587


Script:

#!/bin/bash
# Check the content of some of the files that use this import to see if it's working correctly
# and how it's being used

# Look at a few of the files that use this import
echo "=== Content of feemarket tx.proto ==="
cat proto/injective/feemarket/v1/tx.proto | head -n 20

echo -e "\n=== Content of tokenfactory tx.proto ==="
cat proto/injective/tokenfactory/v1beta1/tx.proto | head -n 20

# Also check if there are any buf.yaml or similar proto config files
echo -e "\n=== Proto build configuration files ==="
fd buf.yaml
fd -e yaml | grep -i proto

Length of output: 2009


Script:

#!/bin/bash
# Check the buf.yaml configuration and other related files

echo "=== Content of buf.yaml ==="
cat proto/buf.yaml

echo -e "\n=== Checking for cosmos proto dependencies ==="
# Look for any cosmos-sdk or cosmos proto references in the workspace
rg -l "cosmos-sdk|cosmos/msg" proto/

Length of output: 1716

🧰 Tools
🪛 buf (1.47.2)

4-4: import "cosmos/msg/v1/msg.proto": file does not exist

(COMPILE)

chain/evm/types/errors.go (3)

1-14: LGTM! Well-organized imports

The package structure and imports are clean and well-organized, with clear separation between standard library and external dependencies.


110-120: LGTM! Well-defined interface

The VmError interface is well-documented and provides a comprehensive set of methods for error handling.


222-252: Add input validation for NewVmErrorWithRet

Consider adding validation for the input parameters:

  1. Check if hash is a valid hex string
  2. Validate that gasUsed is not zero when vmErr indicates execution

Additionally, verify that all callers handle the returned error appropriately.

chain/evm/types/msg.go (3)

29-42: LGTM: Interface implementations and type constants are well-defined.

The compile-time interface checks ensure type safety and the constant follows naming conventions.


251-272: LGTM: Fee calculation implements EIP-1559 correctly.

The implementation properly handles both legacy and dynamic fee calculations, with correct usage of big integer operations and bounds checking.


383-395: LGTM: Parameter update validation is well-implemented.

The validation properly checks the authority address and parameters, with appropriate error wrapping.

chain/feemarket/types/params.go (1)

77-84: Verify default values from the params package in DefaultParams.

The DefaultParams function uses default values params.DefaultBaseFeeChangeDenominator and params.DefaultElasticityMultiplier from the imported params package. Ensure these defaults align with the intended values for the fee market parameters.

Run the following script to check the default values:

Expected Result: Confirm that the values match the desired defaults for BaseFeeChangeDenominator and ElasticityMultiplier.

✅ Verification successful

From the code, I can see that these parameters are imported from the Ethereum go-ethereum params package ("github.com/ethereum/go-ethereum/params"). Since these are well-established parameters from the Ethereum codebase, I can now generate the final response:

Default values from go-ethereum params package are appropriate

The DefaultBaseFeeChangeDenominator and DefaultElasticityMultiplier values are imported from the official go-ethereum params package, which provides the canonical EIP-1559 fee market parameters. This is the correct and intended source for these values, ensuring compatibility with Ethereum's fee market mechanism.

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Verify the default values of BaseFeeChangeDenominator and ElasticityMultiplier from the params package.

# Retrieve the default values from the params package.
ast-grep --pattern $'
package params {
	$$$
	const (
		DefaultBaseFeeChangeDenominator = $_
		DefaultElasticityMultiplier     = $_
		$$$
	)
}'

Length of output: 143


Script:

#!/bin/bash
# Let's try a different approach to find these parameters
# First, let's find all files that might contain these parameters
fd -t f "params.go" | xargs rg -l "DefaultBaseFeeChangeDenominator|DefaultElasticityMultiplier"

# Then let's look at the content of these files
fd -t f "params.go" | xargs rg "DefaultBaseFeeChangeDenominator|DefaultElasticityMultiplier" -B2 -A2

Length of output: 740


Script:

#!/bin/bash
# Let's try to find where these parameters are defined in the imported params package
rg -l "package params" | xargs rg "DefaultBaseFeeChangeDenominator.*=|DefaultElasticityMultiplier.*=" -B1 -A1

# Also check for any imports in the feemarket params.go to find the correct params package
rg -A5 "^import.*\(" chain/feemarket/types/params.go

Length of output: 282


Script:

#!/bin/bash
# Let's check the content of the file to see where these params are imported from
rg -B2 -A2 'import.*"params"' chain/feemarket/types/params.go

# Let's also check if these constants are defined in the same file
rg "const.*\(" -A10 chain/feemarket/types/params.go

Length of output: 117


Script:

#!/bin/bash
# Let's look at all imports and the entire content of the params.go file
cat chain/feemarket/types/params.go

# Also check for any other files that might contain these default values
rg "DefaultBaseFeeChangeDenominator.*=|DefaultElasticityMultiplier.*=" --type go

Length of output: 5991

chain/evm/types/utils.go (1)

243-252: Verify the use of IsLondon function and its impact on base fee calculation.

Ensure that the IsLondon function correctly determines the activation of the London hard fork, as it affects the base fee retrieval in GetBaseFee.

Run the following script to check where IsLondon is defined and confirm its implementation:

✅ Verification successful

Base fee calculation and London hardfork checks are correctly implemented

The implementation is verified to be correct:

  • The IsLondon function correctly checks the London hardfork activation using the chain configuration
  • Base fee calculation in GetBaseFee follows the proper flow:
    1. Checks London hardfork activation first
    2. Gets base fee from feemarket params
    3. Returns appropriate values based on the hardfork state and params

The code properly handles the EIP-1559 fee market mechanism introduced in the London hardfork.

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Find the definition and usage of the IsLondon function.

# Search for the IsLondon function definition.
rg -A 5 -B 2 'func IsLondon\('

# Find all usages of IsLondon.
rg 'IsLondon\('

Length of output: 569


Script:

#!/bin/bash
# Let's check the implementation of IsLondon in the Ethereum params package
# and its usage context in the codebase

# Find the ChainConfig.IsLondon implementation
rg -A 5 "func.*IsLondon" chain/evm/params/

# Check the context of GetBaseFee usage
rg -A 5 -B 5 "GetBaseFee"

# Look for any tests related to London hardfork and base fee
rg -l "london.*test|test.*london" -i

Length of output: 3347


Script:

#!/bin/bash
# Let's check the go.mod to find the ethereum dependency and then look for the IsLondon implementation

# Check go.mod for ethereum dependency
cat go.mod

# Look for the params package and chain config
fd params.go

# Check for any test files related to base fee and London hardfork
fd -e go -x grep -l "London\|BaseFee" {}

Length of output: 12770


Script:

#!/bin/bash
# Let's examine the chain config and London hardfork implementation

# Check the chain config implementation
rg -A 10 "type ChainConfig struct" chain/evm/types/

# Look for London hardfork related code in chain config
rg -A 5 "London" chain/evm/types/chain_config.go

# Check the base fee implementation in feemarket
cat chain/feemarket/types/params.go

Length of output: 8358

proto/injective/evm/v1/query.proto (1)

337-337: Verify the custom type for base_fee.

The base_fee field is defined as a string with a custom type of cosmossdk.io/math.Int. This may cause serialization issues or type mismatches.

Please ensure that the base_fee field is correctly typed. If cosmossdk.io/math.Int is intended to represent an integer value, consider changing the field type from string to cosmos.base.v1beta1.Int or the appropriate numeric type.

Alternatively, if using a custom type is necessary, confirm that the serialization and code generation tools handle gogoproto.customtype correctly.

syntax = "proto3";
package injective.feemarket.v1;

import "injective/feemarket/v1/feemarket.proto";
Copy link

Choose a reason for hiding this comment

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

⚠️ Potential issue

Fix missing import dependency

The static analysis indicates that "injective/feemarket/v1/feemarket.proto" file is missing. This will prevent proper compilation of the proto files.

Please ensure that:

  1. The file exists in the correct location
  2. The import path is correct relative to the proto root
  3. The file is properly copied during the build process
🧰 Tools
🪛 buf (1.47.2)

4-4: import "injective/feemarket/v1/feemarket.proto": file does not exist

(COMPILE)

Comment on lines +18 to +28
// GenesisAccount defines an account to be initialized in the genesis state.
// Its main difference between with Geth's GenesisAccount is that it uses a
// custom storage type and that it doesn't contain the private key field.
message GenesisAccount {
// address defines an ethereum hex formated address of an account
string address = 1;
// code defines the hex bytes of the account code.
string code = 2;
// storage defines the set of state key values for the account.
repeated State storage = 3 [(gogoproto.nullable) = false, (gogoproto.castrepeated) = "Storage"];
}
Copy link

Choose a reason for hiding this comment

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

💡 Codebase verification

Address and storage validation already implemented, code validation could be enhanced

Based on the codebase analysis:

  1. Address validation is properly implemented:

    • GenesisAccount.Validate() uses chaintypes.ValidateAddress
    • The validation ensures proper Ethereum hex address format using common.IsHexAddress
    • Duplicate addresses are checked in genesis state validation
  2. Storage validation is implemented:

    • GenesisAccount.Validate() calls Storage.Validate()
    • Genesis state includes checks for duplicate accounts

However, there's no explicit validation for the code field's hex format and size. Consider adding validation to ensure the contract bytecode is properly formatted.

🔗 Analysis chain

Consider adding field validation and enhancing documentation

The GenesisAccount message is well-structured, but consider the following suggestions:

  1. Add field validation:
    • Ensure the address field follows the correct Ethereum hex format (0x prefix, 20 bytes)
    • Validate the code field for proper hex formatting and reasonable size limits
  2. Enhance documentation:
    • Add examples of valid address and code formats
    • Document any size limitations for the storage field
🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Check if there are any validation implementations in the codebase
rg -A 5 "func.*Validate.*Genesis" 

Length of output: 35


Script:

#!/bin/bash
# Let's check for any validation related to genesis accounts or EVM genesis
rg -A 5 "ValidateGenesis|ValidateEVMGenesis|ValidateGenesisAccount"

# Also search for any validation in Go files near the proto definition
fd "genesis\.go" --exec rg -A 5 "Validate"

# Check if there are any existing validators for hex addresses
rg -A 5 "validate.*[Hh]ex.*[Aa]ddress"

# Look for any existing size/format constraints on code or storage
rg -A 5 "validate.*code|validate.*storage"

Length of output: 2970


Script:

#!/bin/bash
# Let's check the implementation of chaintypes.ValidateAddress which is used in GenesisAccount validation
rg -A 10 "func.*ValidateAddress"

# Also check for Storage validation implementation
ast-grep --pattern 'func (Storage) Validate() error {
  $$$
}'

# Look for any existing hex validation utilities
rg -A 5 "IsHexAddress|ValidateHexString"

Length of output: 1755

Comment on lines +11 to +17
// Msg defines the erc20 Msg service.
service Msg {
option (cosmos.msg.v1.service) = true;
// UpdateParams defined a governance operation for updating the x/feemarket module parameters.
// The authority is hard-coded to the Cosmos SDK x/gov module account
rpc UpdateParams(MsgUpdateParams) returns (MsgUpdateParamsResponse);
}
Copy link

Choose a reason for hiding this comment

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

⚠️ Potential issue

Update service documentation and verify completeness

  1. The service comment incorrectly states "erc20 Msg service" but this is in the feemarket module.
  2. According to the AI summary, this service should also include an EthereumTx RPC method, but it's not present in the code.

Please update the documentation and verify if the EthereumTx RPC method should be added:

-// Msg defines the erc20 Msg service.
+// Msg defines the feemarket Msg service.
📝 Committable suggestion

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.

Suggested change
// Msg defines the erc20 Msg service.
service Msg {
option (cosmos.msg.v1.service) = true;
// UpdateParams defined a governance operation for updating the x/feemarket module parameters.
// The authority is hard-coded to the Cosmos SDK x/gov module account
rpc UpdateParams(MsgUpdateParams) returns (MsgUpdateParamsResponse);
}
// Msg defines the feemarket Msg service.
service Msg {
option (cosmos.msg.v1.service) = true;
// UpdateParams defined a governance operation for updating the x/feemarket module parameters.
// The authority is hard-coded to the Cosmos SDK x/gov module account
rpc UpdateParams(MsgUpdateParams) returns (MsgUpdateParamsResponse);
}


import "gogoproto/gogo.proto";

option go_package = "github.com/InjectiveLabs/injective-core/injective-chain/modules/evm/types";
Copy link

Choose a reason for hiding this comment

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

⚠️ Potential issue

Update go_package path to match sdk-go repository

The go_package option currently points to the injective-core repository, but this file is being copied to sdk-go. The path should be updated to reflect the new location.

-option go_package = "github.com/InjectiveLabs/injective-core/injective-chain/modules/evm/types";
+option go_package = "github.com/InjectiveLabs/sdk-go/chain/evm/types";
📝 Committable suggestion

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.

Suggested change
option go_package = "github.com/InjectiveLabs/injective-core/injective-chain/modules/evm/types";
option go_package = "github.com/InjectiveLabs/sdk-go/chain/evm/types";

Comment on lines +113 to +123
func fee(gasPrice *big.Int, gas uint64) *big.Int {
gasLimit := new(big.Int).SetUint64(gas)
return new(big.Int).Mul(gasPrice, gasLimit)
}

func cost(fee, value *big.Int) *big.Int {
if value != nil {
return new(big.Int).Add(fee, value)
}
return fee
}
Copy link

Choose a reason for hiding this comment

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

🛠️ Refactor suggestion

Add input validation for fee and cost calculations

While the implementations are correct, they should validate input parameters to prevent panics.

Add input validation:

 func fee(gasPrice *big.Int, gas uint64) *big.Int {
+    if gasPrice == nil {
+        return new(big.Int)
+    }
     gasLimit := new(big.Int).SetUint64(gas)
     return new(big.Int).Mul(gasPrice, gasLimit)
 }

 func cost(fee, value *big.Int) *big.Int {
+    if fee == nil {
+        fee = new(big.Int)
+    }
     if value != nil {
         return new(big.Int).Add(fee, value)
     }
     return fee
 }
📝 Committable suggestion

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.

Suggested change
func fee(gasPrice *big.Int, gas uint64) *big.Int {
gasLimit := new(big.Int).SetUint64(gas)
return new(big.Int).Mul(gasPrice, gasLimit)
}
func cost(fee, value *big.Int) *big.Int {
if value != nil {
return new(big.Int).Add(fee, value)
}
return fee
}
func fee(gasPrice *big.Int, gas uint64) *big.Int {
if gasPrice == nil {
return new(big.Int)
}
gasLimit := new(big.Int).SetUint64(gas)
return new(big.Int).Mul(gasPrice, gasLimit)
}
func cost(fee, value *big.Int) *big.Int {
if fee == nil {
fee = new(big.Int)
}
if value != nil {
return new(big.Int).Add(fee, value)
}
return fee
}

// Validate performs a stateless validation of the tx fields.
func (tx DynamicFeeTx) Validate() error {
if tx.GasTipCap == nil {
return errorsmod.Wrap(ErrInvalidGasCap, "gas tip cap cannot nil")
Copy link

Choose a reason for hiding this comment

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

⚠️ Potential issue

Typographical error in error message

The error message should read "gas tip cap cannot be nil" instead of "gas tip cap cannot nil".

Apply this diff to fix the typo:

-		return errorsmod.Wrap(ErrInvalidGasCap, "gas tip cap cannot nil")
+		return errorsmod.Wrap(ErrInvalidGasCap, "gas tip cap cannot be nil")
📝 Committable suggestion

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.

Suggested change
return errorsmod.Wrap(ErrInvalidGasCap, "gas tip cap cannot nil")
return errorsmod.Wrap(ErrInvalidGasCap, "gas tip cap cannot be nil")

Comment on lines +269 to +271
func (tx *DynamicFeeTx) EffectiveGasPrice(baseFee *big.Int) *big.Int {
return EffectiveGasPrice(baseFee, tx.GasFeeCap.BigInt(), tx.GasTipCap.BigInt())
}
Copy link

Choose a reason for hiding this comment

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

⚠️ Potential issue

Potential nil pointer dereference in EffectiveGasPrice

Accessing tx.GasFeeCap.BigInt() and tx.GasTipCap.BigInt() without checking if they are nil could lead to a nil pointer dereference.

Consider adding nil checks before calling .BigInt():

func (tx *DynamicFeeTx) EffectiveGasPrice(baseFee *big.Int) *big.Int {
-		return EffectiveGasPrice(baseFee, tx.GasFeeCap.BigInt(), tx.GasTipCap.BigInt())
+		var gasFeeCapBigInt, gasTipCapBigInt *big.Int
+		if tx.GasFeeCap != nil {
+			gasFeeCapBigInt = tx.GasFeeCap.BigInt()
+		}
+		if tx.GasTipCap != nil {
+			gasTipCapBigInt = tx.GasTipCap.BigInt()
+		}
+		return EffectiveGasPrice(baseFee, gasFeeCapBigInt, gasTipCapBigInt)
}
📝 Committable suggestion

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.

Suggested change
func (tx *DynamicFeeTx) EffectiveGasPrice(baseFee *big.Int) *big.Int {
return EffectiveGasPrice(baseFee, tx.GasFeeCap.BigInt(), tx.GasTipCap.BigInt())
}
func (tx *DynamicFeeTx) EffectiveGasPrice(baseFee *big.Int) *big.Int {
var gasFeeCapBigInt, gasTipCapBigInt *big.Int
if tx.GasFeeCap != nil {
gasFeeCapBigInt = tx.GasFeeCap.BigInt()
}
if tx.GasTipCap != nil {
gasTipCapBigInt = tx.GasTipCap.BigInt()
}
return EffectiveGasPrice(baseFee, gasFeeCapBigInt, gasTipCapBigInt)
}

for _, msg := range (*tx).GetMsgs() {
ethMsg, ok := msg.(*MsgEthereumTx)
if !ok {
return nil, fmt.Errorf("invalid tx type: %T", tx)
Copy link

Choose a reason for hiding this comment

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

⚠️ Potential issue

Correct the error message to reference 'msg' instead of 'tx'.

In the UnwrapEthereumMsg function, the error message incorrectly references tx when it should reference msg. This could lead to confusion during debugging.

Apply this diff to fix the error message:

-			return nil, fmt.Errorf("invalid tx type: %T", tx)
+			return nil, fmt.Errorf("invalid msg type: %T", msg)
📝 Committable suggestion

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.

Suggested change
return nil, fmt.Errorf("invalid tx type: %T", tx)
return nil, fmt.Errorf("invalid msg type: %T", msg)

syntax = "proto3";
package injective.evm.v1;

import "cosmos/base/query/v1beta1/pagination.proto";
Copy link

Choose a reason for hiding this comment

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

⚠️ Potential issue

Fix the missing import statement for pagination.

The import at line 4 references a file that does not exist: "cosmos/base/query/v1beta1/pagination.proto". This will cause a compilation error.

Please ensure that the pagination.proto file exists at the specified path or update the import path to the correct location. If pagination features are not used in this file, consider removing this import and any related pagination code.

🧰 Tools
🪛 buf (1.47.2)

4-4: import "cosmos/base/query/v1beta1/pagination.proto": file does not exist

(COMPILE)

Comment on lines +39 to +41
// Storage queries the balance of all coins for a single account.
rpc Storage(QueryStorageRequest) returns (QueryStorageResponse) {
option (google.api.http).get = "/injective/evm/v1/storage/{address}/{key}";
Copy link

Choose a reason for hiding this comment

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

⚠️ Potential issue

Correct the inaccurate comments for the Storage and Code RPC methods.

The comments for the Storage and Code RPC methods incorrectly state that they "query the balance of all coins for a single account." This is misleading and does not reflect the actual functionality of these methods.

Please update the comments to accurately describe each method:

  • For the Storage method (lines 39-41), update the comment to:

    // Storage queries the storage value of a key for a specific Ethereum account.
  • For the Code method (lines 44-46), update the comment to:

    // Code retrieves the code bytecode for a specific Ethereum account.

Also applies to: 44-46

Copy link

@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: 3

🧹 Outside diff range and nitpick comments (3)
chain/types/validation.go (3)

11-14: Add input validation to prevent panics

While the implementation is correct, it could panic if the input string is not a valid hex string. Consider adding validation before conversion.

 func IsEmptyHash(hash string) bool {
+    if !common.IsHexAddress(hash) {
+        return false
+    }
     return bytes.Equal(common.HexToHash(hash).Bytes(), common.Hash{}.Bytes())
 }

16-19: Add input validation to prevent panics

Similar to IsEmptyHash, this function should validate the input before conversion to prevent potential panics.

 func IsZeroAddress(address string) bool {
+    if !common.IsHexAddress(address) {
+        return false
+    }
     return bytes.Equal(common.HexToAddress(address).Bytes(), common.Address{}.Bytes())
 }

21-30: Complete the function documentation

The function comment is incomplete and should describe the full validation behavior.

-// ValidateAddress returns an error if the provided string is either not a hex formatted string address
+// ValidateAddress returns an error if the provided string is not a valid hex formatted Ethereum address
📜 Review details

Configuration used: .coderabbit.yaml
Review profile: CHILL

📥 Commits

Reviewing files that changed from the base of the PR and between a074c61 and afaf354.

⛔ Files ignored due to path filters (1)
  • go.sum is excluded by !**/*.sum
📒 Files selected for processing (6)
  • chain/evm/types/ERC20Contract.json (1 hunks)
  • chain/evm/types/SimpleStorageContract.json (1 hunks)
  • chain/evm/types/TestMessageCall.json (1 hunks)
  • chain/types/int.go (2 hunks)
  • chain/types/validation.go (1 hunks)
  • go.mod (8 hunks)
✅ Files skipped from review due to trivial changes (2)
  • chain/evm/types/SimpleStorageContract.json
  • chain/evm/types/TestMessageCall.json
🔇 Additional comments (13)
chain/types/validation.go (3)

1-9: LGTM! Clean package structure and imports

The package structure is well-organized with clear import aliases and necessary dependencies.


32-42: LGTM! Well-structured validation function

The function is well-implemented with:

  • Proper composition using existing validation functions
  • Clear error messages
  • Efficient validation order (checks zero address before format)

1-42: Verify consistent usage of address validation

These validation functions are critical for security. Let's verify they're used consistently across the codebase.

✅ Verification successful

Address validation functions are used consistently across critical paths

Based on the search results, the validation functions are properly utilized in key areas:

  • All EVM transaction types (Legacy, AccessList, DynamicFee) validate destination addresses using ValidateAddress
  • Log entries validate addresses and check for empty hashes
  • Genesis account addresses are validated
  • Direct HexToAddress usage appears in safe contexts (after validation or in internal type conversions)

Key validation points:

  • chain/evm/types/: Consistent validation across all transaction types
  • chain/peggy/types/: Uses equivalent validation via gethcommon.IsHexAddress
  • chain/oracle/types/: Properly validates publisher addresses
🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Search for direct Ethereum address handling that might bypass these validation functions
rg -g '!{vendor,node_modules}/**' 'common\.HexToAddress|common\.IsHexAddress' --type go

# Search for potential usage points of these validation functions
rg -g '!{vendor,node_modules}/**' 'ValidateAddress|ValidateNonZeroAddress|IsEmptyHash|IsZeroAddress' --type go

Length of output: 4046

go.mod (4)

38-41: Verify security package updates

Critical security-related packages have been updated:

  • golang.org/x/crypto v0.25.0
  • google.golang.org/protobuf v1.34.2
  • google.golang.org/grpc v1.64.1

These updates include important security fixes and should be maintained.

✅ Verification successful

Let me check the security advisories for the other packages as well to provide a complete verification.


Security package updates verified - Important fixes included

The updated versions are safe and include critical security fixes:

  • golang.org/x/crypto v0.25.0 (from v0.24.0): Above all known vulnerability ranges
  • google.golang.org/protobuf v1.34.2 (from v1.33.0): Addresses the infinite loop vulnerability in protojson.Unmarshal
  • google.golang.org/grpc v1.64.1 (from v1.63.2): Fixes the private token logging issue in v1.64.0

These updates are necessary as they patch several security vulnerabilities:

  • HIGH severity: Protobuf DoS vulnerability
  • MODERATE severity: Protojson unmarshaling infinite loop
  • LOW severity: gRPC private token logging issue
🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Check for any security advisories for the updated packages
gh api graphql -f query='
{
  securityVulnerabilities(first: 5, ecosystem: GO, package: "golang.org/x/crypto") {
    nodes {
      advisory {
        summary
        severity
      }
      vulnerableVersionRange
    }
  }
}
'

Length of output: 1124


Script:

#!/bin/bash
# Check security advisories for protobuf and grpc
gh api graphql -f query='
{
  securityVulnerabilities(first: 5, ecosystem: GO, package: "google.golang.org/protobuf") {
    nodes {
      advisory {
        summary
        severity
      }
      vulnerableVersionRange
    }
  }
}
'

gh api graphql -f query='
{
  securityVulnerabilities(first: 5, ecosystem: GO, package: "google.golang.org/grpc") {
    nodes {
      advisory {
        summary
        severity
      }
      vulnerableVersionRange
    }
  }
}
'

# Let's also check the previous versions in go.mod
git show HEAD^:go.mod | grep -E "crypto|protobuf|grpc"

Length of output: 2092


27-27: Verify Ethereum dependency compatibility

The ethereum/go-ethereum dependency has been updated to v1.14.12 and is being replaced with a custom fork. This is a significant version jump that might introduce breaking changes.

Consider:

  1. Documenting the reason for using a custom fork
  2. Adding integration tests for Ethereum-specific functionality
  3. Monitoring for any performance impacts from this update

Also applies to: 258-258

✅ Verification successful

Let me gather more information about the Ethereum dependency usage and changes.


Let me check one more aspect to understand if there are any breaking changes in the Ethereum types being used.


Custom fork is properly configured with minimal impact

The update to ethereum/go-ethereum v1.14.12 is properly managed through a custom fork (InjectiveLabs/go-ethereum) as shown in the replace directive. The codebase primarily uses stable Ethereum types and utilities (common, crypto, core) with no direct dependency on eth.Block, eth.Transaction, or eth.Header that could introduce breaking changes. The usage is concentrated in type definitions and utility functions rather than core blockchain operations.

Key observations:

  • Custom fork is pinned to specific version: github.com/InjectiveLabs/go-ethereum v1.9.22-0.20240923100242-5e28e23d353e
  • Usage is limited to stable packages like common, crypto, and core types
  • No direct geth API dependencies found that could be affected by breaking changes
🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Check for any Ethereum-specific type usage that might be affected
rg -l "eth\." | xargs rg "eth\.(Block|Transaction|Header)"

# Check for any direct geth API usage
ast-grep --pattern 'eth.$_'

Length of output: 1408


Script:

#!/bin/bash
# Check the go.mod history for ethereum dependency
git log -p -- go.mod | grep -A 5 -B 5 "ethereum/go-ethereum"

# Find all imports of ethereum packages
rg -l "github.com/ethereum/go-ethereum"

# Check for replace directives in go.mod
grep -A 5 "replace" go.mod

# Look for any ethereum types or methods usage
rg "eth\." -A 2 -B 2

Length of output: 5995


Script:

#!/bin/bash
# Check the specific ethereum package imports to understand usage
rg "github.com/ethereum/go-ethereum/(\w+)" --only-matching | sort | uniq

# Look for any ethereum-specific configuration or parameters
rg -l "github.com/ethereum/go-ethereum" | xargs rg "eth\.Config|eth\.Params|eth\.ChainConfig"

# Check for any replace directives specifically for ethereum
cat go.mod | grep -A 1 "github.com/ethereum/go-ethereum"

Length of output: 8047


3-5: ⚠️ Potential issue

Verify toolchain compatibility

The toolchain version (go1.23.3) is higher than the Go version (1.22.2) specified. This might cause compatibility issues or unexpected behavior.

Consider aligning the toolchain version with the Go version or documenting the reason for this specific combination.


243-256: Verify replace directive consistency

The replace directives are pointing to custom forks with specific versions. This is a critical part of the dependency management that needs careful verification.

Consider:

  1. Documenting the rationale for each custom fork
  2. Setting up automated dependency update checks
  3. Maintaining a compatibility matrix
✅ Verification successful

Replace directives are properly used and consistent with imports

The verification shows that:

  1. All replaced modules are actively used in imports across the codebase
  2. The replace directives point to custom forks with specific versions that align with the project's requirements
  3. Each replaced module serves a clear purpose:
    • Core SDK components (cosmos-sdk, store, evidence, feegrant, etc.)
    • Smart contract support (wasmd)
    • Consensus and networking (cometbft)
    • IBC functionality (ibc-go, ibc-hooks)
    • External integrations (bandchain-packet)
🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Check if all replaced modules are actually used
for module in $(awk '/^replace/ {print $2}' go.mod); do
  if [[ $module != "=>" ]]; then
    rg -l "$module"
  fi
done

# Verify that replaced versions are consistent with main dependencies
for module in $(awk '/^replace/ {print $2}' go.mod); do
  if [[ $module != "=>" ]]; then
    echo "Checking $module..."
    rg "require.*$module" go.mod
  fi
done

Length of output: 417


Script:

#!/bin/bash
# Check if all replaced modules are actually used
while IFS= read -r line; do
  if [[ $line =~ ^[[:space:]]*([^[:space:]]+)[[:space:]]=\> ]]; then
    module="${BASH_REMATCH[1]}"
    echo "Checking usage of $module"
    rg -l "$module" || true
  fi
done < go.mod

# Check require statements for these modules
echo -e "\nChecking require statements:"
while IFS= read -r line; do
  if [[ $line =~ ^[[:space:]]*([^[:space:]]+)[[:space:]]=\> ]]; then
    module="${BASH_REMATCH[1]}"
    echo -e "\nRequire entries for $module:"
    rg "require.*$module" go.mod || true
  fi
done < go.mod

# Get the main module name
echo -e "\nMain module name:"
rg "^module" go.mod

Length of output: 66009


Script:

#!/bin/bash
# Check if replaced modules are actually used in imports
echo "Checking imports for replaced modules:"
for module in \
    "cosmossdk.io/store" \
    "cosmossdk.io/x/evidence" \
    "cosmossdk.io/x/feegrant" \
    "cosmossdk.io/x/tx" \
    "cosmossdk.io/x/upgrade" \
    "github.com/CosmWasm/wasmd" \
    "github.com/bandprotocol/bandchain-packet" \
    "github.com/cometbft/cometbft" \
    "github.com/cosmos/cosmos-sdk" \
    "github.com/cosmos/ibc-apps/modules/ibc-hooks/v8" \
    "github.com/cosmos/ibc-go/v8"; do
    echo -e "\nChecking imports of $module"
    rg "\"$module" --type go || true
done

# Check version consistency between require and replace
echo -e "\nChecking version consistency:"
grep -A1 "^require" go.mod
echo -e "\nReplace directives:"
grep "=>" go.mod

Length of output: 72246

chain/evm/types/ERC20Contract.json (1)

1-4: Verify contract source and compilation

The contract appears to be compiled with Solidity 0.5.17. For security and maintainability:

Recommendations:

  1. Include the original Solidity source code in the repository for transparency
  2. Consider upgrading to a more recent Solidity version (0.8.x) for better security features
  3. If this is from OpenZeppelin, specify the exact version in documentation
✅ Verification successful

Contract is used for testing purposes - no security concerns

Based on the code analysis, this ERC20 contract is embedded as a test contract in the codebase. The compiled_contract.go file clearly shows it's used alongside other test contracts (SimpleStorage, TestMessageCall) and is loaded during initialization for testing purposes. The contract's source code absence is not a security concern in this context since it's not meant for production deployment.

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Verify if the contract source is available and matches the bytecode

# Look for potential Solidity source files
echo "Searching for potential source files..."
fd -e sol -e solidity . -x echo "Found potential source: {}"

# Check if this contract is imported from a known package
echo "Checking package.json for relevant dependencies..."
fd package.json -x jq -r '.dependencies + .devDependencies | keys[]' {} | grep -i "openzeppelin\|erc20"

Length of output: 370


Script:

#!/bin/bash
# Let's try a broader search to understand the context of this contract

# Search for any references to this contract file
echo "Searching for references to ERC20Contract.json..."
rg -l "ERC20Contract.json"

# Look for related test files
echo "Searching for related test files..."
fd -t f -e test.js -e spec.js -e test.ts -e spec.ts . -x echo "Found test: {}"

# Search for any build or contract artifacts directory
echo "Searching for contract build directories..."
fd -t d "build|artifacts|contracts" -x echo "Found contracts directory: {}"

# Look for hardhat or truffle config
echo "Searching for contract framework configs..."
fd "hardhat.config|truffle-config" -x echo "Found config: {}"

Length of output: 1112


Script:

#!/bin/bash
# Let's check the Go file that references this contract to understand its usage

echo "Checking compiled_contract.go content..."
cat chain/evm/types/compiled_contract.go

# Also search for any ERC20-related code or tests
echo -e "\nSearching for ERC20 related files..."
rg -l "ERC20" --type go --type rust

# Look for any contract deployment or testing code
echo -e "\nSearching for contract deployment patterns..."
rg -l "DeployContract|ContractDeployment" --type go

Length of output: 3269

chain/types/int.go (5)

45-51: LGTM!

The SafeInt64 function correctly handles potential overflows when converting uint64 to int64.


62-67: LGTM!

The SafeNewIntFromBigInt function properly constructs sdkmath.Int from *big.Int with appropriate overflow checks.


70-75: LGTM!

The SaturatedNewInt function correctly handles overflows by saturating values exceeding 256 bits to MaxInt256.


78-80: LGTM!

The IsValidInt256 function effectively checks whether a *big.Int is within the 256-bit limit.


84-93: LGTM!

The bigIntOverflows function efficiently determines if a *big.Int exceeds the 256-bit limit by optimizing the check using word length before bit length.

Comment on lines +1 to +4
{
"abi": "[{\"inputs\":[{\"internalType\":\"address\",\"name\":\"initialAccount\",\"type\":\"address\"},{\"internalType\":\"uint256\",\"name\":\"initialBalance\",\"type\":\"uint256\"}],\"payable\":false,\"stateMutability\":\"nonpayable\",\"type\":\"constructor\"},{\"anonymous\":false,\"inputs\":[{\"indexed\":true,\"internalType\":\"address\",\"name\":\"owner\",\"type\":\"address\"},{\"indexed\":true,\"internalType\":\"address\",\"name\":\"spender\",\"type\":\"address\"},{\"indexed\":false,\"internalType\":\"uint256\",\"name\":\"value\",\"type\":\"uint256\"}],\"name\":\"Approval\",\"type\":\"event\"},{\"anonymous\":false,\"inputs\":[{\"indexed\":false,\"internalType\":\"address\",\"name\":\"sender\",\"type\":\"address\"},{\"indexed\":false,\"internalType\":\"uint256\",\"name\":\"i\",\"type\":\"uint256\"}],\"name\":\"TestLog\",\"type\":\"event\"},{\"anonymous\":false,\"inputs\":[{\"indexed\":true,\"internalType\":\"address\",\"name\":\"from\",\"type\":\"address\"},{\"indexed\":true,\"internalType\":\"address\",\"name\":\"to\",\"type\":\"address\"},{\"indexed\":false,\"internalType\":\"uint256\",\"name\":\"value\",\"type\":\"uint256\"}],\"name\":\"Transfer\",\"type\":\"event\"},{\"constant\":true,\"inputs\":[{\"internalType\":\"address\",\"name\":\"_owner\",\"type\":\"address\"},{\"internalType\":\"address\",\"name\":\"_spender\",\"type\":\"address\"}],\"name\":\"allowance\",\"outputs\":[{\"internalType\":\"uint256\",\"name\":\"\",\"type\":\"uint256\"}],\"payable\":false,\"stateMutability\":\"view\",\"type\":\"function\"},{\"constant\":false,\"inputs\":[{\"internalType\":\"address\",\"name\":\"_spender\",\"type\":\"address\"},{\"internalType\":\"uint256\",\"name\":\"_value\",\"type\":\"uint256\"}],\"name\":\"approve\",\"outputs\":[{\"internalType\":\"bool\",\"name\":\"\",\"type\":\"bool\"}],\"payable\":false,\"stateMutability\":\"nonpayable\",\"type\":\"function\"},{\"constant\":true,\"inputs\":[{\"internalType\":\"address\",\"name\":\"_owner\",\"type\":\"address\"}],\"name\":\"balanceOf\",\"outputs\":[{\"internalType\":\"uint256\",\"name\":\"\",\"type\":\"uint256\"}],\"payable\":false,\"stateMutability\":\"view\",\"type\":\"function\"},{\"constant\":false,\"inputs\":[{\"internalType\":\"uint256\",\"name\":\"n\",\"type\":\"uint256\"}],\"name\":\"benchmarkLogs\",\"outputs\":[],\"payable\":false,\"stateMutability\":\"nonpayable\",\"type\":\"function\"},{\"constant\":false,\"inputs\":[{\"internalType\":\"address\",\"name\":\"_spender\",\"type\":\"address\"},{\"internalType\":\"uint256\",\"name\":\"_subtractedValue\",\"type\":\"uint256\"}],\"name\":\"decreaseApproval\",\"outputs\":[{\"internalType\":\"bool\",\"name\":\"\",\"type\":\"bool\"}],\"payable\":false,\"stateMutability\":\"nonpayable\",\"type\":\"function\"},{\"constant\":false,\"inputs\":[{\"internalType\":\"address\",\"name\":\"_spender\",\"type\":\"address\"},{\"internalType\":\"uint256\",\"name\":\"_addedValue\",\"type\":\"uint256\"}],\"name\":\"increaseApproval\",\"outputs\":[{\"internalType\":\"bool\",\"name\":\"\",\"type\":\"bool\"}],\"payable\":false,\"stateMutability\":\"nonpayable\",\"type\":\"function\"},{\"constant\":false,\"inputs\":[{\"internalType\":\"address\",\"name\":\"account\",\"type\":\"address\"},{\"internalType\":\"uint256\",\"name\":\"amount\",\"type\":\"uint256\"}],\"name\":\"mint\",\"outputs\":[],\"payable\":false,\"stateMutability\":\"nonpayable\",\"type\":\"function\"},{\"constant\":true,\"inputs\":[],\"name\":\"totalSupply\",\"outputs\":[{\"internalType\":\"uint256\",\"name\":\"\",\"type\":\"uint256\"}],\"payable\":false,\"stateMutability\":\"view\",\"type\":\"function\"},{\"constant\":false,\"inputs\":[{\"internalType\":\"address\",\"name\":\"_to\",\"type\":\"address\"},{\"internalType\":\"uint256\",\"name\":\"_value\",\"type\":\"uint256\"}],\"name\":\"transfer\",\"outputs\":[{\"internalType\":\"bool\",\"name\":\"\",\"type\":\"bool\"}],\"payable\":false,\"stateMutability\":\"nonpayable\",\"type\":\"function\"},{\"constant\":false,\"inputs\":[{\"internalType\":\"address\",\"name\":\"_from\",\"type\":\"address\"},{\"internalType\":\"address\",\"name\":\"_to\",\"type\":\"address\"},{\"internalType\":\"uint256\",\"name\":\"_value\",\"type\":\"uint256\"}],\"name\":\"transferFrom\",\"outputs\":[{\"internalType\":\"bool\",\"name\":\"\",\"type\":\"bool\"}],\"payable\":false,\"stateMutability\":\"nonpayable\",\"type\":\"function\"}]",
"bin": "608060405234801561001057600080fd5b506040516114543803806114548339818101604052604081101561003357600080fd5b810190808051906020019092919080519060200190929190505050806000808473ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff168152602001908152602001600020819055508060028190555050506113ab806100a96000396000f3fe608060405234801561001057600080fd5b506004361061009e5760003560e01c80636618846311610066578063661884631461022957806370a082311461028f578063a9059cbb146102e7578063d73dd6231461034d578063dd62ed3e146103b35761009e565b8063095ea7b3146100a357806318160ddd1461010957806323b872dd1461012757806340c10f19146101ad57806357807d7f146101fb575b600080fd5b6100ef600480360360408110156100b957600080fd5b81019080803573ffffffffffffffffffffffffffffffffffffffff1690602001909291908035906020019092919050505061042b565b604051808215151515815260200191505060405180910390f35b61011161051d565b6040518082815260200191505060405180910390f35b6101936004803603606081101561013d57600080fd5b81019080803573ffffffffffffffffffffffffffffffffffffffff169060200190929190803573ffffffffffffffffffffffffffffffffffffffff16906020019092919080359060200190929190505050610527565b604051808215151515815260200191505060405180910390f35b6101f9600480360360408110156101c357600080fd5b81019080803573ffffffffffffffffffffffffffffffffffffffff169060200190929190803590602001909291905050506108dc565b005b6102276004803603602081101561021157600080fd5b810190808035906020019092919050505061098e565b005b6102756004803603604081101561023f57600080fd5b81019080803573ffffffffffffffffffffffffffffffffffffffff16906020019092919080359060200190929190505050610a18565b604051808215151515815260200191505060405180910390f35b6102d1600480360360208110156102a557600080fd5b81019080803573ffffffffffffffffffffffffffffffffffffffff169060200190929190505050610ca8565b6040518082815260200191505060405180910390f35b610333600480360360408110156102fd57600080fd5b81019080803573ffffffffffffffffffffffffffffffffffffffff16906020019092919080359060200190929190505050610cf0565b604051808215151515815260200191505060405180910390f35b6103996004803603604081101561036357600080fd5b81019080803573ffffffffffffffffffffffffffffffffffffffff16906020019092919080359060200190929190505050610f0c565b604051808215151515815260200191505060405180910390f35b610415600480360360408110156103c957600080fd5b81019080803573ffffffffffffffffffffffffffffffffffffffff169060200190929190803573ffffffffffffffffffffffffffffffffffffffff169060200190929190505050611108565b6040518082815260200191505060405180910390f35b600081600160003373ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002060008573ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff168152602001908152602001600020819055508273ffffffffffffffffffffffffffffffffffffffff163373ffffffffffffffffffffffffffffffffffffffff167f8c5be1e5ebec7d5bd14f71427d1e84f3dd0314c0f7b2291e5b200ac8c7c3b925846040518082815260200191505060405180910390a36001905092915050565b6000600254905090565b60008060008573ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff1681526020019081526020016000205482111561057457600080fd5b600160008573ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002060003373ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff168152602001908152602001600020548211156105fd57600080fd5b600073ffffffffffffffffffffffffffffffffffffffff168373ffffffffffffffffffffffffffffffffffffffff16141561063757600080fd5b610688826000808773ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff1681526020019081526020016000205461118f90919063ffffffff16565b6000808673ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff1681526020019081526020016000208190555061071b826000808673ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff1681526020019081526020016000205461128390919063ffffffff16565b6000808573ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff168152602001908152602001600020819055506107ec82600160008773ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002060003373ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff1681526020019081526020016000205461118f90919063ffffffff16565b600160008673ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002060003373ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff168152602001908152602001600020819055508273ffffffffffffffffffffffffffffffffffffffff168473ffffffffffffffffffffffffffffffffffffffff167fddf252ad1be2c89b69c2b068fc378daa952ba7f163c4a11628f55a4df523b3ef846040518082815260200191505060405180910390a3600190509392505050565b61092d816000808573ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff1681526020019081526020016000205461128390919063ffffffff16565b6000808473ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff168152602001908152602001600020819055506109848160025461128390919063ffffffff16565b6002819055505050565b60008090505b81811015610a14577fb2abdf6dca7f5665e93ea2262744f2159b5c45ff1a9dacadb090ceb00c2a302f3382604051808373ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff1681526020018281526020019250505060405180910390a18080600101915050610994565b5050565b600080600160003373ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002060008573ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff168152602001908152602001600020549050808310610b28576000600160003373ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002060008673ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002081905550610bbc565b610b3b838261118f90919063ffffffff16565b600160003373ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002060008673ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff168152602001908152602001600020819055505b8373ffffffffffffffffffffffffffffffffffffffff163373ffffffffffffffffffffffffffffffffffffffff167f8c5be1e5ebec7d5bd14f71427d1e84f3dd0314c0f7b2291e5b200ac8c7c3b925600160003373ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002060008873ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff168152602001908152602001600020546040518082815260200191505060405180910390a3600191505092915050565b60008060008373ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff168152602001908152602001600020549050919050565b60008060003373ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002054821115610d3d57600080fd5b600073ffffffffffffffffffffffffffffffffffffffff168373ffffffffffffffffffffffffffffffffffffffff161415610d7757600080fd5b610dc8826000803373ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff1681526020019081526020016000205461118f90919063ffffffff16565b6000803373ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002081905550610e5b826000808673ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff1681526020019081526020016000205461128390919063ffffffff16565b6000808573ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff168152602001908152602001600020819055508273ffffffffffffffffffffffffffffffffffffffff163373ffffffffffffffffffffffffffffffffffffffff167fddf252ad1be2c89b69c2b068fc378daa952ba7f163c4a11628f55a4df523b3ef846040518082815260200191505060405180910390a36001905092915050565b6000610f9d82600160003373ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002060008673ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff1681526020019081526020016000205461128390919063ffffffff16565b600160003373ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002060008573ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff168152602001908152602001600020819055508273ffffffffffffffffffffffffffffffffffffffff163373ffffffffffffffffffffffffffffffffffffffff167f8c5be1e5ebec7d5bd14f71427d1e84f3dd0314c0f7b2291e5b200ac8c7c3b925600160003373ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002060008773ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff168152602001908152602001600020546040518082815260200191505060405180910390a36001905092915050565b6000600160008473ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002060008373ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002054905092915050565b6000828211156040518060400160405280601281526020017f4d4154485f5355425f554e444552464c4f57000000000000000000000000000081525090611271576040517f08c379a00000000000000000000000000000000000000000000000000000000081526004018080602001828103825283818151815260200191508051906020019080838360005b8381101561123657808201518184015260208101905061121b565b50505050905090810190601f1680156112635780820380516001836020036101000a031916815260200191505b509250505060405180910390fd5b50600082840390508091505092915050565b6000808284019050838110156040518060400160405280601181526020017f4d4154485f4144445f4f564552464c4f570000000000000000000000000000008152509061136b576040517f08c379a00000000000000000000000000000000000000000000000000000000081526004018080602001828103825283818151815260200191508051906020019080838360005b83811015611330578082015181840152602081019050611315565b50505050905090810190601f16801561135d5780820380516001836020036101000a031916815260200191505b509250505060405180910390fd5b50809150509291505056fea265627a7a723158201835ad3fdb84f43ad0d79c6875a0f5521dc5110fc373c9f0597547aff6d9971764736f6c63430005110032"
}
Copy link

Choose a reason for hiding this comment

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

🛠️ Refactor suggestion

Implement additional security measures

The contract implementation could benefit from modern security practices.

Consider implementing these security enhancements:

  1. Add pausable functionality for emergency situations
  2. Implement permit functionality (EIP-2612) for gasless approvals
  3. Add explicit overflow checks (although implicit in Solidity >=0.8.0)
  4. Add events for mint operations

Example permit extension:

{
  "inputs": [
    {"internalType": "address", "name": "owner", "type": "address"},
    {"internalType": "address", "name": "spender", "type": "address"},
    {"internalType": "uint256", "name": "value", "type": "uint256"},
    {"internalType": "uint256", "name": "deadline", "type": "uint256"},
    {"internalType": "uint8", "name": "v", "type": "uint8"},
    {"internalType": "bytes32", "name": "r", "type": "bytes32"},
    {"internalType": "bytes32", "name": "s", "type": "bytes32"}
  ],
  "name": "permit",
  "outputs": [],
  "stateMutability": "nonpayable",
  "type": "function"
}

Comment on lines +1 to +2
{
"abi": "[{\"inputs\":[{\"internalType\":\"address\",\"name\":\"initialAccount\",\"type\":\"address\"},{\"internalType\":\"uint256\",\"name\":\"initialBalance\",\"type\":\"uint256\"}],\"payable\":false,\"stateMutability\":\"nonpayable\",\"type\":\"constructor\"},{\"anonymous\":false,\"inputs\":[{\"indexed\":true,\"internalType\":\"address\",\"name\":\"owner\",\"type\":\"address\"},{\"indexed\":true,\"internalType\":\"address\",\"name\":\"spender\",\"type\":\"address\"},{\"indexed\":false,\"internalType\":\"uint256\",\"name\":\"value\",\"type\":\"uint256\"}],\"name\":\"Approval\",\"type\":\"event\"},{\"anonymous\":false,\"inputs\":[{\"indexed\":false,\"internalType\":\"address\",\"name\":\"sender\",\"type\":\"address\"},{\"indexed\":false,\"internalType\":\"uint256\",\"name\":\"i\",\"type\":\"uint256\"}],\"name\":\"TestLog\",\"type\":\"event\"},{\"anonymous\":false,\"inputs\":[{\"indexed\":true,\"internalType\":\"address\",\"name\":\"from\",\"type\":\"address\"},{\"indexed\":true,\"internalType\":\"address\",\"name\":\"to\",\"type\":\"address\"},{\"indexed\":false,\"internalType\":\"uint256\",\"name\":\"value\",\"type\":\"uint256\"}],\"name\":\"Transfer\",\"type\":\"event\"},{\"constant\":true,\"inputs\":[{\"internalType\":\"address\",\"name\":\"_owner\",\"type\":\"address\"},{\"internalType\":\"address\",\"name\":\"_spender\",\"type\":\"address\"}],\"name\":\"allowance\",\"outputs\":[{\"internalType\":\"uint256\",\"name\":\"\",\"type\":\"uint256\"}],\"payable\":false,\"stateMutability\":\"view\",\"type\":\"function\"},{\"constant\":false,\"inputs\":[{\"internalType\":\"address\",\"name\":\"_spender\",\"type\":\"address\"},{\"internalType\":\"uint256\",\"name\":\"_value\",\"type\":\"uint256\"}],\"name\":\"approve\",\"outputs\":[{\"internalType\":\"bool\",\"name\":\"\",\"type\":\"bool\"}],\"payable\":false,\"stateMutability\":\"nonpayable\",\"type\":\"function\"},{\"constant\":true,\"inputs\":[{\"internalType\":\"address\",\"name\":\"_owner\",\"type\":\"address\"}],\"name\":\"balanceOf\",\"outputs\":[{\"internalType\":\"uint256\",\"name\":\"\",\"type\":\"uint256\"}],\"payable\":false,\"stateMutability\":\"view\",\"type\":\"function\"},{\"constant\":false,\"inputs\":[{\"internalType\":\"uint256\",\"name\":\"n\",\"type\":\"uint256\"}],\"name\":\"benchmarkLogs\",\"outputs\":[],\"payable\":false,\"stateMutability\":\"nonpayable\",\"type\":\"function\"},{\"constant\":false,\"inputs\":[{\"internalType\":\"address\",\"name\":\"_spender\",\"type\":\"address\"},{\"internalType\":\"uint256\",\"name\":\"_subtractedValue\",\"type\":\"uint256\"}],\"name\":\"decreaseApproval\",\"outputs\":[{\"internalType\":\"bool\",\"name\":\"\",\"type\":\"bool\"}],\"payable\":false,\"stateMutability\":\"nonpayable\",\"type\":\"function\"},{\"constant\":false,\"inputs\":[{\"internalType\":\"address\",\"name\":\"_spender\",\"type\":\"address\"},{\"internalType\":\"uint256\",\"name\":\"_addedValue\",\"type\":\"uint256\"}],\"name\":\"increaseApproval\",\"outputs\":[{\"internalType\":\"bool\",\"name\":\"\",\"type\":\"bool\"}],\"payable\":false,\"stateMutability\":\"nonpayable\",\"type\":\"function\"},{\"constant\":false,\"inputs\":[{\"internalType\":\"address\",\"name\":\"account\",\"type\":\"address\"},{\"internalType\":\"uint256\",\"name\":\"amount\",\"type\":\"uint256\"}],\"name\":\"mint\",\"outputs\":[],\"payable\":false,\"stateMutability\":\"nonpayable\",\"type\":\"function\"},{\"constant\":true,\"inputs\":[],\"name\":\"totalSupply\",\"outputs\":[{\"internalType\":\"uint256\",\"name\":\"\",\"type\":\"uint256\"}],\"payable\":false,\"stateMutability\":\"view\",\"type\":\"function\"},{\"constant\":false,\"inputs\":[{\"internalType\":\"address\",\"name\":\"_to\",\"type\":\"address\"},{\"internalType\":\"uint256\",\"name\":\"_value\",\"type\":\"uint256\"}],\"name\":\"transfer\",\"outputs\":[{\"internalType\":\"bool\",\"name\":\"\",\"type\":\"bool\"}],\"payable\":false,\"stateMutability\":\"nonpayable\",\"type\":\"function\"},{\"constant\":false,\"inputs\":[{\"internalType\":\"address\",\"name\":\"_from\",\"type\":\"address\"},{\"internalType\":\"address\",\"name\":\"_to\",\"type\":\"address\"},{\"internalType\":\"uint256\",\"name\":\"_value\",\"type\":\"uint256\"}],\"name\":\"transferFrom\",\"outputs\":[{\"internalType\":\"bool\",\"name\":\"\",\"type\":\"bool\"}],\"payable\":false,\"stateMutability\":\"nonpayable\",\"type\":\"function\"}]",
Copy link

Choose a reason for hiding this comment

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

⚠️ Potential issue

Review non-standard ERC20 methods for security implications

The contract includes non-standard methods that require careful consideration:

  1. benchmarkLogs: This method emits test events which could pollute the event log.
  2. mint: Allows creation of new tokens without access control.

Consider implementing the following security measures:

  • Add access control (e.g., Ownable) to the mint function
  • Remove or restrict benchmarkLogs to testing environments only
  • Add a cap to total supply to prevent infinite minting
- "mint": Allows creation of new tokens without access control.
+ "mint": {
+   "inputs": [
+     {"internalType": "address","name": "account","type": "address"},
+     {"internalType": "uint256","name": "amount","type": "uint256"}
+   ],
+   "name": "mint",
+   "outputs": [],
+   "payable": false,
+   "stateMutability": "nonpayable",
+   "type": "function",
+   "modifiers": [{"name": "onlyOwner"}]
+ }

Committable suggestion skipped: line range outside the PR's diff.

Comment on lines +53 to +59
func SafeInt(value uint) (int, error) {
if value > uint(math.MaxInt64) {
return 0, errorsmod.Wrapf(errortypes.ErrInvalidHeight, "uint value %v cannot exceed %v", value, int(math.MaxInt64))
}

return int(value), nil
}
Copy link

Choose a reason for hiding this comment

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

⚠️ Potential issue

Fix potential overflow in SafeInt function on 32-bit systems

The SafeInt function casts a uint to an int, assuming int is at least 64 bits. On 32-bit systems, int is 32 bits, which can lead to overflow when value exceeds math.MaxInt32. The current check against math.MaxInt64 is insufficient for 32-bit systems.

Apply the following fix to ensure compatibility across different architectures:

-func SafeInt(value uint) (int, error) {
-	if value > uint(math.MaxInt64) {
-		return 0, errorsmod.Wrapf(errortypes.ErrInvalidHeight, "uint value %v cannot exceed %v", value, int(math.MaxInt64))
+func SafeInt(value uint) (int, error) {
+	var maxInt uint
+	if ^uint(0) == uint(^uint32(0)) { // Detect 32-bit systems
+		maxInt = uint(math.MaxInt32)
+	} else {
+		maxInt = uint(math.MaxInt64)
+	}
+	if value > maxInt {
+		return 0, errorsmod.Wrapf(errortypes.ErrInvalidHeight, "uint value %v cannot exceed %v", value, int(maxInt))
	}

	return int(value), nil
}
📝 Committable suggestion

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.

Suggested change
func SafeInt(value uint) (int, error) {
if value > uint(math.MaxInt64) {
return 0, errorsmod.Wrapf(errortypes.ErrInvalidHeight, "uint value %v cannot exceed %v", value, int(math.MaxInt64))
}
return int(value), nil
}
func SafeInt(value uint) (int, error) {
var maxInt uint
if ^uint(0) == uint(^uint32(0)) { // Detect 32-bit systems
maxInt = uint(math.MaxInt32)
} else {
maxInt = uint(math.MaxInt64)
}
if value > maxInt {
return 0, errorsmod.Wrapf(errortypes.ErrInvalidHeight, "uint value %v cannot exceed %v", value, int(maxInt))
}
return int(value), nil
}

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.

1 participant