refactor: replace interface{} with any for clarity and modernization

[weifangc]

This change replaces occurrences of interface{} with the predeclared identifier any, introduced in Go 1.18 as an alias for interface{}.

As noted in the Go 1.18 Release Notes:
This improves readability and aligns the codebase with modern Go conventions.

Summary by CodeRabbit

• Refactor

  • Updated type system across multiple modules for Go 1.18+ compatibility with no functional impact.

• Bug Fixes

  • Enhanced parameter validations in blockchain modules to enforce stricter minimum value requirements and address validation constraints.

_{✏️ Tip: You can customize this high-level summary in your review settings.}

[coderabbitai]

Walkthrough

The changes replace interface{} with any (Go 1.18+ alias) across multiple Go files for type parameters, return types, struct fields, and map declarations. Additionally, validator functions in the peggy and wasmx modules introduce new validation constraints including minimum value checks and range validations.

Changes

Cohort / File(s)	Summary
Type and parameter validation functions chain/evm/types/errors.go, chain/evm/types/params.go, chain/exchange/types/params.go, chain/oracle/types/params.go, chain/peggy/types/params.go, chain/wasmx/types/params.go	Replaced parameter type interface{} with any in validator function signatures. Also introduces new validation constraints: peggy validators enforce minimum values (TargetBatchTimeout ≥ 60000, block times ≥ 100) and bridge address validation; wasmx validators enforce non-zero constraints and gas limit range checks.
Struct field and type declarations chain/exchange/types/paramset.go, chain/wasmx/types/custom_execution.go	Updated struct field types and type alias definitions from interface{} to any (e.g., ParamSetPair.Value, ExecutionData.Args, ValueValidatorFn).
Map type declarations chain/exchange/types/common_order.go, chain/exchange/types/spot_orders.go, client/chain/chain.go, client/chain/chain_v2.go, eip712_cosmos.go, examples/chain/11_DecodeTx/37_decode_tx.go	Changed map type literals from map[string]interface{} to map[string]any in order hash computations and data structures.
Method signatures ethereum/util/amounts.go, ethereum/util/contract.go	Updated method signatures to use any instead of interface{} (e.g., Wei.Scan(), BoundContract.Transact()).

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~12 minutes

• The majority of changes are homogeneous type replacements (interface{} → any), which are syntactic updates with no runtime behavior changes.
• Special attention recommended for:
  • chain/peggy/types/params.go: New minimum value constraints on TargetBatchTimeout (60000), AverageBlockTime (100), AverageEthereumBlockTime (100), and bridge address validation logic.
  • chain/wasmx/types/params.go: New non-zero constraints on MaxBeginBlockTotalGas and MinGasPrice; range check for MaxContractGasLimit ≥ MinExecutionGasLimit.

Poem

🐰 From interface{} to any we go,
A modern Go refactor's gentle flow,
With validations tightened, constraints made clear,
The types are aligned, the logic sincere.
Hop along with these changes, oh so neat!

Pre-merge checks and finishing touches

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 3.17% which is insufficient. The required threshold is 80.00%.	You can run @coderabbitai generate docstrings to improve docstring coverage.

✅ Passed checks (2 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title clearly and specifically describes the main change: replacing interface{} with any throughout the codebase for modernization and clarity.

✨ Finishing touches

• 📝 Generate docstrings

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[coderabbitai]

Actionable comments posted: 0

🧹 Nitpick comments (1)

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

183-194: Avoid error‑string matching in validateBridgeContractAddress

The special‑casing of empty addresses by checking strings.Contains(err.Error(), "empty") couples behavior to the error message text from ValidateEthAddress, which is brittle and inconsistent with validateCosmosCoinErc20Contract (which just checks v == "").

Consider simplifying to an explicit empty‑string guard and delegating to ValidateEthAddress otherwise:

-func validateBridgeContractAddress(i any) error {
-	v, ok := i.(string)
-	if !ok {
-		return fmt.Errorf("invalid parameter type: %T", i)
-	}
-	if err := ValidateEthAddress(v); err != nil {
-		if !strings.Contains(err.Error(), "empty") {
-			return err
-		}
-	}
-	return nil
-}
+func validateBridgeContractAddress(i any) error {
+	v, ok := i.(string)
+	if !ok {
+		return fmt.Errorf("invalid parameter type: %T", i)
+	}
+	if v == "" {
+		// empty address is allowed
+		return nil
+	}
+	return ValidateEthAddress(v)
+}

This is clearer and robust to future changes in ValidateEthAddress’s error text.

📜 Review details

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 386021c and 76922de.

📒 Files selected for processing (16)

• chain/evm/types/errors.go (1 hunks)
• chain/evm/types/params.go (3 hunks)
• chain/exchange/types/common_order.go (1 hunks)
• chain/exchange/types/params.go (21 hunks)
• chain/exchange/types/paramset.go (1 hunks)
• chain/exchange/types/spot_orders.go (1 hunks)
• chain/oracle/types/params.go (1 hunks)
• chain/peggy/types/params.go (10 hunks)
• chain/wasmx/types/custom_execution.go (1 hunks)
• chain/wasmx/types/params.go (5 hunks)
• client/chain/chain.go (2 hunks)
• client/chain/chain_v2.go (2 hunks)
• eip712_cosmos.go (3 hunks)
• ethereum/util/amounts.go (1 hunks)
• ethereum/util/contract.go (1 hunks)
• examples/chain/11_DecodeTx/37_decode_tx.go (1 hunks)

🧰 Additional context used

🧬 Code graph analysis (2)

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

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

• ValidateBool (618-624)

chain/exchange/types/params.go (2)

chain/exchange/types/v2/params.go (1)

• ValidateAtomicMarketOrderAccessLevel (274-283)

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

• ValidateBool (125-131)

🔇 Additional comments (16)

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

88-103: Use of any in validatePythContract is safe and consistent

Switching the validator arg to any is a no-op semantically and keeps compatibility with the params framework.

chain/wasmx/types/custom_execution.go (1)

15-19: ExecutionData.Args change to any is benign

Args remains an unconstrained JSON payload; using any is idiomatic and does not alter marshaling or call sites.

client/chain/chain_v2.go (1)

2741-2782: EIP-712 message / OrderInfo maps now use map[string]any – no behavioral change

The switch to map[string]any in both spot and derivative branches preserves the TypedData structure and hashing; EIP-712 order hash computation remains identical.

Also applies to: 2784-2825

client/chain/chain.go (1)

2925-2966: Consistent any usage in ComputeOrderHashes maps

Updating the spot and derivative TypedData message / OrderInfo maps to map[string]any keeps the EIP‑712 payload shape identical and just modernizes the type spelling.

Also applies to: 2968-3009

examples/chain/11_DecodeTx/37_decode_tx.go (1)

11-14: parserMap refactor to map[string]any is fine

The map still holds concrete message prototypes and the type switch logic is unaffected.

chain/exchange/types/common_order.go (1)

132-144: Adopting any in EIP‑712 order message and GetOrderIdentifier

Using map[string]any for the EIP‑712 message/OrderInfo and returning any from GetOrderIdentifier preserves existing behavior while aligning with modern Go style.

Also applies to: 198-204

ethereum/util/amounts.go (1)

25-46: Wei.Scan now takes any – implementation and interface compatibility intact

The Scan logic is unchanged and still matches scanner expectations; this is a purely cosmetic alias change.

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

295-297: RevertError.ErrorData return type switched to any with no behavior change

Error data remains the hex string revert reason; this just updates the return type spelling to any.

eip712_cosmos.go (1)

122-143: map[string]any refactor here is behavior‑preserving

Using any as an alias for interface{} in txData and ctx keeps JSON (un)marshalling and the fee type assertion semantics unchanged, so this is a safe readability/modernization tweak. Just ensure the module’s go version is 1.18+ in go.mod so any is available.

Also applies to: 213-220

ethereum/util/contract.go (1)

90-99: Transact ...any signature is source‑compatible

Switching the variadic parameter to ...any is type‑identical to ...interface{} and keeps both the direct BoundContract.Transact call and the ABI packing path behaving the same, while modernizing the API surface. Just confirm the repo targets Go 1.18+.

chain/exchange/types/paramset.go (1)

4-18: ParamSet APIs updated to any with no semantic change

Using any for ValueValidatorFn, ParamSetPair.Value, and NewParamSetPair keeps behavior identical while aligning with modern Go style. Public API remains type‑compatible since any is just an alias for interface{}.

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

153-181: New minimums for time‑related params change validation behavior

validateTargetBatchTimeout, validateAverageBlockTime, and validateAverageEthereumBlockTime now enforce lower bounds (>= 60000 and >= 100 respectively). That will cause param sets or proposals with smaller values that previously passed ValidateBasic to start failing. Given the PR is described as a refactor to any, please double‑check that tightening these constraints in this PR (and at this magnitude) is intentional and acceptable for existing deployments.

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

116-153: EVM param validators now enforce stricter semantics

Beyond the any refactor, validateEIPs now rejects non‑activateable EIPs via vm.ValidEip, and ValidateChainConfig delegates to cfg.Validate(). That’s a behavioral tightening: some ExtraEIPs or ChainConfig values that previously passed will now cause Params.Validate() to error. Please confirm that this stricter validation is desired in this PR (vs. being split into a separate, explicitly behavior‑changing change).

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

105-149: New gas constraints materially tighten wasmx parameter validation

validateMaxBeginBlockTotalGas, validateMaxContractGasLimit, and validateMinGasPrice now enforce non‑zero and minimum‑limit checks (including MaxContractGasLimit >= MinExecutionGasLimit). This is beneficial from a safety perspective but will cause Params.Validate() and param proposals with 0 or very low values that previously passed to start failing.

Since the PR is framed as a type‑alias refactor, please confirm that introducing these new constraints here is intentional and that no existing networks rely on 0 or sub‑MinExecutionGasLimit values as sentinels.

chain/exchange/types/spot_orders.go (1)

33-44: LGTM! Map type declarations modernized consistently.

The map type declarations have been updated from map[string]interface{} to map[string]any for both the top-level message and the nested OrderInfo payload. This is consistent with the broader refactoring effort and improves code readability without any functional changes.

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

241-624: Refactoring approved—Go version supports any alias.

The project requires Go 1.23.9, which exceeds the minimum 1.18 requirement for the any type alias. All validator function signature updates are safe and idiomatic.

[weifangc]

@aarmoa Hi, Could you please review this PR at your convenience? Thank you very much.