deps: Remove SDK Fork

[Eric-Warehime]

Description

Removes the fork of the cosmos sdk--only dependency here is the Copy function.

Closes: #XXXX

---

Author Checklist

All items are required. Please add a note to the item if the item is not applicable and
please add links to any relevant follow up issues.

I have...

• tackled an existing issue or discussed with a team member
• left instructions on how to review the changes
• targeted the main branch

Reviewers Checklist

All items are required.
Please add a note if the item is not applicable
and please add your handle next to the items reviewed
if you only reviewed selected items.

I have...

• added a relevant changelog entry to the Unreleased section in CHANGELOG.md
• confirmed all author checklist items have been addressed
• confirmed that this PR does not change production code
• reviewed content
• tested instructions (if applicable)
• confirmed all CI checks have passed

[Pitasi]

x/evm limits the number of precompiles call made from a contract to the arbitrary number 7:

evm/x/vm/types/call.go

Lines 12 to 15 in a48a796

	// MaxPrecompileCalls is the maximum number of precompile
	// calls within a transaction. We want to limit this because
	// for each precompile tx we're creating a cached context
	const MaxPrecompileCalls uint8 = 7

I think the comment is related to this (I might be wrong though).

Does this change make it any better, or does it not impact this at all? I don't know if changing from Copy() to CacheMultiStore() affects performances.

[Eric-Warehime]

x/evm limits the number of precompiles call made from a contract to the arbitrary number 7:

evm/x/vm/types/call.go

Lines 12 to 15 in a48a796

	// MaxPrecompileCalls is the maximum number of precompile
	// calls within a transaction. We want to limit this because
	// for each precompile tx we're creating a cached context
	const MaxPrecompileCalls uint8 = 7

I think the comment is related to this (I might be wrong though).

Does this change make it any better, or does it not impact this at all? I don't know if changing from Copy() to CacheMultiStore() affects performances.

It seems like the number of precompile calls within a given txn is tracked at the StateDb object level here but the change away from using Copy should improve performance because we're using the SDK's branching contexts now instead of doing a deep copy of the store.

[vladjdk]

Looks fine to me - I read the test that breaks if you don't use Copy() or CacheMultiStore(), and it seems like either method would fix it. I don't think we need to be making a deep copy of the store, using CacheMultiStore on a CacheMultiStore-generated object looks like it works. Should be more efficient too :)

// Would probably want more tests on this eventually though.

[zsystm]

@Eric-Warehime @vladjdk

One key difference I've confirmed between CacheMultiStore() and Copy() is especially critical when reasoning about cache layering and ephemeral state behavior.

CacheMultiStore()

• Creates a new cache layer on top of the current store.
• The parent and child share the same ephemeral (in-memory) state.
• Updates made in the parent store—even after the child cache is created—are visible to the child (in our environment, even after the parent Commit()).
• Conversely, updates made in the child will be merged back into the parent when childCMS.Write() is called.
• When chaining multiple layers (e.g. grandchild), changes flow upward only when .Write() is called at each layer.

Copy()

• Produces a fully isolated snapshot of the current ephemeral state.
• The copy does not see any future updates from the original store.
• Changes made in the copy are not reflected in the original.
• Calling copyCMS.Write() merges changes directly to the parent KVStore, bypassing any intermediate cache layers (e.g., the original CMS).

This distinction is subtle but has significant implications.
Replacing Copy() with CacheMultiStore() changes the behavior in critical ways:

• Original cache changes will now affect the new layer.
  Previously, the copied store was isolated. With CacheMultiStore(), any new writes in the parent cache will be reflected in the child, which could unintentionally override expected state.
• Child writes now propagate upward
  In the Copy() version, writes only touched the parent KVStore. With CacheMultiStore(), calling .Write() will modify the original cache’s ephemeral state—potentially overwriting intermediate values.
• Unexpected interactions between layers.
  Cache hierarchy behavior becomes more complex, and unexpected state mutations may occur if the layering and write flow aren't clearly understood.

Unless shared cache behavior is explicitly intended and carefully controlled, this change can introduce non-obvious side effects. I’d recommend reviewing whether this change is safe across all usage paths—especially in areas where .Write() is involved.

Reference test cases:

• TestCacheMultiStore_SharedEphemeralState_GrandChild: Demonstrates how ephemeral state is shared across parent → child → grandchild caches, and how .Write() propagates changes up the hierarchy.

• TestCacheMultiStore_Copy_IsIndependent: confirms that Copy() produces a fully isolated snapshot that does not reflect parent changes, nor merges its own changes back into the original cache.