refactor: upgrade cosmos-sdk and ethermint versions

[zakir-code]

Summary by CodeRabbit

• New Features

  • Introduced a new configuration parameter header_hash_num in the EVM settings, enhancing block header processing.

• Bug Fixes

  • Improved error handling in the EVM block processing logic, ensuring more robust management of header hashes.

• Version Updates

  • Updated CometBFT binary version to 0.38.12 across multiple configuration files.
  • Incremented version numbers in various configuration files to reflect the latest updates.

• Dependency Updates

  • Updated several dependencies to their latest versions, ensuring compatibility and potential bug fixes.

[coderabbitai]

Walkthrough

The pull request introduces several changes across multiple files, primarily focusing on the Ethereum Virtual Machine (EVM) configuration and upgrade processes. Notably, a new parameter header_hash_num is added to the evm section in the app/genesis.json file. The upgrade.go file is modified to include a new migration function for EVM parameters. Additionally, various dependency versions are updated in the go.mod file, and the CometBFT binary version is incremented in multiple configuration files.

Changes

File	Change Summary
app/genesis.json	Added parameter header_hash_num: "256" in params of evm section.
app/upgrades/v8/upgrade.go	Added method migrateEvmParams. Updated CreateUpgradeHandler to include EVM migration.
go.mod	Updated multiple dependency versions and replace directives for various packages.
public/mainnet/config.toml	Updated CometBFT version from 0.38.11 to 0.38.12.
public/testnet/config.toml	Updated CometBFT version from 0.38.11 to 0.38.12.
server/config/data/config.json	Updated version from "0.38.11" to "0.38.12".
x/evm/keeper/abci.go	Enhanced BeginBlock method for better error handling and streamlined header hash management.

Possibly related PRs

• refactor(precompile): remove evm keeper and format code #468: Involves the removal of the EvmKeeper parameter in various functions, potentially related to the new parameters in the evm section.
• perf(crosschain): simplify code and module references #726: Discusses the removal of the EthKeeper from the crosschainprecompile.NewPrecompiledContract function, aligning with changes in the evm section.
• refactor(gov): migrate gov module to v8 #735: Migration of the governance module to v8, which may relate to structural changes in the application, including the evm section.
• chore: migrate bridge balances #760: Migration of bridge balances and new imports for crosschain types, connecting with changes in the evm section.
• refactor: migrate erc20 module's bridge and ibc token to crosschain module #768: Migration of ERC20 tokens to the crosschain module, indicating broader integration of token management related to the evm section.

🐰 In the code we hop and play,
New settings here, a brighter day.
With header hashes set just right,
Upgrades gleam, a joyful sight!
Dependencies fresh, we leap with glee,
In our digital burrow, we’re fancy and free! 🌟

---

📜 Recent review details

Configuration used: CodeRabbit UI
Review profile: CHILL

📥 Commits

Files that changed from the base of the PR and between 9ec7942 and f4b1949.

⛔ Files ignored due to path filters (1)

• go.sum is excluded by !**/*.sum

📒 Files selected for processing (7)

• app/genesis.json (1 hunks)
• app/upgrades/v8/upgrade.go (4 hunks)
• go.mod (9 hunks)
• public/mainnet/config.toml (1 hunks)
• public/testnet/config.toml (1 hunks)
• server/config/data/config.json (1 hunks)
• x/evm/keeper/abci.go (1 hunks)

✅ Files skipped from review due to trivial changes (3)

• public/mainnet/config.toml
• public/testnet/config.toml
• server/config/data/config.json

🧰 Additional context used

🔇 Additional comments (14)

x/evm/keeper/abci.go (3)

5-5: LGTM!

The ethermint types import is correctly added and necessary for the new safe conversion functions.

---

11-14: LGTM!

The configuration retrieval is well-structured with proper error handling and caching of the config for reuse.

---

15-26: ⚠️ Potential issue

Consider improving error handling and adding documentation.

The header hash management logic has several areas for improvement:

1. Using panic in production code is risky. Consider returning errors instead.
2. The code assumes headerHashNum is positive without validation.
3. The purpose and implications of header hash cleanup are not documented.

Consider applying these improvements:

 func (k *Keeper) BeginBlock(ctx sdk.Context) error {
     cfg, err := k.EVMBlockConfig(ctx, k.ChainID())
     if err != nil {
         return err
     }
     k.SetHeaderHash(ctx)
     headerHashNum, err := ethermint.SafeInt64(cfg.Params.GetHeaderHashNum())
     if err != nil {
-        panic(err)
+        return err
+    }
+    // Validate headerHashNum is within reasonable range
+    if headerHashNum <= 0 {
+        return fmt.Errorf("headerHashNum must be positive, got %d", headerHashNum)
     }
     if i := ctx.BlockHeight() - headerHashNum; i > 0 {
         h, err := ethermint.SafeUint64(i)
         if err != nil {
-            panic(err)
+            return err
         }
         k.DeleteHeaderHash(ctx, h)
     }
     return nil
 }

Also, please add documentation explaining:

• The purpose of header hash cleanup
• Why we keep only the last N header hashes
• The implications of the chosen headerHashNum value

Let's verify the usage of header hash in the codebase:

app/upgrades/v8/upgrade.go (3)

19-19: LGTM: Required imports added for EVM functionality.

The new imports are correctly placed and necessary for the EVM parameter migration functionality.

Also applies to: 28-28

---

48-50: LGTM: EVM params migration properly integrated.

The migration is correctly placed before store modifications and follows the established error handling pattern.

Let's verify that all required EVM parameter migrations are included:

---

76-80: 🛠️ Refactor suggestion

Consider enhancing the EVM params migration.

While the implementation is functional, consider these improvements:

1. Add logging to track the parameter change for better debugging.
2. Verify that setting HeaderHashNum to the default value won't impact existing chains.

Let's verify the default value's compatibility:

Consider adding logging:

 func migrateEvmParams(ctx sdk.Context, evmKeeper *fxevmkeeper.Keeper) error {
 	params := evmKeeper.GetParams(ctx)
+	oldHeaderHashNum := params.HeaderHashNum
 	params.HeaderHashNum = evmtypes.DefaultHeaderHashNum
+	ctx.Logger().Info("migrating evm params", 
+		"old_header_hash_num", oldHeaderHashNum,
+		"new_header_hash_num", params.HeaderHashNum)
 	return evmKeeper.SetParams(ctx, params)
 }

✅ Verification successful

Let me gather more information about the DefaultHeaderHashNum value and its usage.

---

Let me try one more search with different patterns to find the default value and its usage.

---

Let me try one final search to find the specific EVM types default values.

---

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

The EVM params migration is safe and well-implemented

The code review concern can be addressed based on the following findings:

1. The HeaderHashNum parameter is only used in block processing to maintain a window of historical block hashes, as seen in x/evm/keeper/abci.go.
2. The migration preserves all existing params and only updates the HeaderHashNum field, which is appropriate for an upgrade.
3. While logging would be nice-to-have, it's not critical since this is a one-time upgrade migration.

The suggestion to add logging is optional since:

• The parameter change is part of a planned upgrade
• The change is straightforward and affects only one field
• The value is set to a well-defined default constant

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Check the current HeaderHashNum value in existing chains
ast-grep --pattern 'HeaderHashNum = $_'

# Search for any existing usage of HeaderHashNum
rg -A 5 "HeaderHashNum"

Length of output: 786

---

Script:

#!/bin/bash
# Check the DefaultHeaderHashNum definition and any related constants
ast-grep --pattern 'DefaultHeaderHashNum = $_'

# Look for any HeaderHashNum related tests or validations
rg "HeaderHashNum" -A 5 --glob "**/*test*.go"

# Check for any HeaderHashNum parameter validation
ast-grep --pattern 'func (p Params) Validate() error {
  $$$
  HeaderHashNum
  $$$
}'

Length of output: 182

---

Script:

#!/bin/bash
# Search for DefaultHeaderHashNum constant definition
rg "DefaultHeaderHashNum" -B 2 -A 2

# Search for any param validation related to HeaderHashNum
rg "HeaderHashNum.*validate" -i -A 5

# Look for any param files that might contain the default value
fd "params.go" --exec cat {}

Length of output: 10741

---

Script:

#!/bin/bash
# Search for EVM types default values and params
fd "evm.*types.go" --exec cat {}

# Search specifically for HeaderHashNum in EVM related files
rg -B 5 -A 5 "HeaderHashNum" --glob "**/evm/**"

Length of output: 613

go.mod (6)

20-22: Verify CometBFT upgrade impact.

The upgrade from v0.38.11 to a pre-release version v0.38.13-0.20240920204745-fdf90d16f608 requires careful consideration:

1. This is a pre-release version which might have stability issues
2. CometBFT is a critical consensus component

#!/bin/bash
# Check for any consensus-related changes or breaking changes
rg -A 5 "consensus|breaking.*change" $(fd -g "CHANGELOG.md" | rg "cometbft")

# Look for CometBFT version usage across the codebase
rg -l "cometbft" --type go

---

255-256: Review implications of using crypto-org-chain forks.

The replacement of official cosmos-sdk repositories with crypto-org-chain forks needs careful review:

1. Verify the fork is up-to-date with upstream
2. Ensure custom changes don't introduce security risks
3. Consider long-term maintenance implications

#!/bin/bash
# Compare fork with upstream
echo "Checking crypto-org-chain/cosmos-sdk fork..."
gh api repos/crypto-org-chain/cosmos-sdk/commits/d78d66e74712 | jq -r '.commit.message'
gh api repos/cosmos/cosmos-sdk/compare/v0.50.6...crypto-org-chain:d78d66e74712 | jq -r '.behind_by, .ahead_by'

---

266-266: Verify impact of switching ethermint fork.

The change from functionx/ethermint to pundiai/ethermint fork requires thorough review:

1. This is a significant change in dependency source
2. Version v0.6.1-0.20241022071115-5e0afc7c501c is a pre-release

#!/bin/bash
# Compare the two forks
echo "Comparing ethermint forks..."
gh api repos/functionx/ethermint/commits/master | jq -r '.commit.message'
gh api repos/pundiai/ethermint/commits/5e0afc7c501c | jq -r '.commit.message'

# Look for ethermint usage in the codebase
rg "github.com/evmos/ethermint" --type go

---

98-101: Verify btcd-related updates compatibility.

The updates to btcd and related packages should be reviewed for compatibility:

• btcd: v0.23.4 → v0.24.2
• btcd/btcec/v2: updated
• btcd/btcutil: updated
• btcd/chaincfg/chainhash: added

#!/bin/bash
# Check for any breaking changes in btcd updates
rg -i "breaking.*change|incompatib" $(fd -g "CHANGELOG.md" | rg "btcd")

# Look for btcd usage in the codebase
rg "github.com/btcsuite/btcd" --type go

---

199-201: Verify Prometheus monitoring updates.

The updates to Prometheus client and common packages should be reviewed:

• client_golang: v1.19.1 → v1.20.1
• common: v0.55.0 → v0.57.0

#!/bin/bash
# Check for breaking changes in Prometheus updates
rg -i "breaking.*change|incompatib" $(fd -g "CHANGELOG.md" | rg "prometheus")

# Look for Prometheus metric usage
rg "prometheus" --type go | rg "NewCounter|NewGauge|NewHistogram"

---

7-7: Verify compatibility between core SDK components.

The updates to core SDK components should be verified for compatibility:

• client/v2: beta.3 → beta.5
• store: 1.1.0 → 1.1.1
• tx: 0.13.5 → custom commit

Also applies to: 12-12, 16-16

✅ Verification successful

Let me generate new shell scripts to better verify the compatibility between core SDK components.

This script will help us:

1. Check for breaking changes in commits between the version upgrades
2. Look at the commit messages to understand the nature of changes
3. Verify any specific version constraints in our go.mod file

---

Based on the output from the shell scripts, I can now provide a final response about the compatibility of the core SDK components:

Core SDK component updates appear compatible and safe to upgrade

The changes between versions show:

• client/v2 beta.3 → beta.5: Mostly improvements and fixes (e.g., encoder additions, output format fixes, version filtering)
• store 1.1.0 → 1.1.1: Only dependency bumps and non-breaking improvements
• No critical breaking changes or incompatibilities were found in the commit history

The updates are primarily focused on:

• Bug fixes and improvements to existing functionality
• Performance enhancements
• Documentation updates
• Dependency version bumps

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Check for any compatibility issues mentioned in changelogs or release notes
rg -i "breaking.*change|deprecat|incompatib" $(fd -g "CHANGELOG.md|RELEASE*.md")

# Look for version constraints in go.mod files of these dependencies
for repo in "cosmos-sdk" "ethermint"; do
  echo "Checking $repo version constraints..."
  gh api repos/cosmos/$repo/contents/go.mod --ref v0.50.9 | jq -r '.content' | base64 -d | rg "cosmossdk.io/(client/v2|store|x/tx)"
done

Length of output: 25949

---

Script:

#!/bin/bash
# Check for any breaking changes or compatibility issues in the recent commits of core SDK components
# Look for version constraints and breaking changes in recent commits

# Check client/v2 changes between beta.3 and beta.5
gh api repos/cosmos/cosmos-sdk/compare/client/v2/v2.0.0-beta.3...client/v2/v2.0.0-beta.5 | jq -r '.commits[].commit.message'

# Check store changes between 1.1.0 and 1.1.1
gh api repos/cosmos/cosmos-sdk/compare/store/v1.1.0...store/v1.1.1 | jq -r '.commits[].commit.message'

# Check tx module changes
gh api repos/cosmos/cosmos-sdk/compare/tx/v0.13.0...tx/v0.13.5 | jq -r '.commits[].commit.message'

# Look for any dependency constraints in the current repository
rg -A 5 "require\s+cosmossdk.io/(client/v2|store|tx)" go.mod

Length of output: 17754

app/genesis.json (2)

302-302: LGTM: Secure default for transaction protection.

The allow_unprotected_txs parameter is correctly set to false, which enforces transaction signing and enhances security.

---

303-303: Verify the header hash number configuration.

The new header_hash_num parameter is set to "256". While this is a common value for block history depth, please verify:

1. That this aligns with ethermint's recommended settings
2. The impact on node performance and state growth

---

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

• X
• Mastodon
• Reddit
• LinkedIn

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

CodeRabbit Configuration File (.coderabbit.yaml)

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

Documentation and Community

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