feat(x/vm): apply stack-based StateDB snapshot mechamism for precompile call

[cloudgray]

Description

Summary

• Applying the stack-based snapshot mechanism achieves the same effect as a deep copy of the original store.
• Benchmark results show that the stack-based snapshot mechanism uses about 1.4× more memory than CacheMultiStore, but far less than a deep copy—and the gap grows larger as the load increases.

Stack-based Snapshot Mechanism

• When executing a precompile, a new store layer is added to the top of the stack, and state writes are performed on this new layer.
• If a revert occurs during execution, the invalid store layers are popped off the stack to ensure that a valid store layer remains at the top.
• When committing changes, the writes are propagated sequentially from the top of the stack down to the bottom and applied to the initialStore.
• The Snapshot() method of the new store uses approximately 1.4 times more memory than the previously used CacheMultiStore(), but it provides a more robust structure that avoids edge cases.

Benchmark

The benchmark results show that the new Snapshot() method uses significantly less memory than a deep copy, and the gap widens as the number of iterations increases.

Like CacheMultiStore(), the new Snapshot() method exhibits linear memory growth with increasing iterations, using approximately 1.4× more memory than CacheMultiStore()

Closes: #225

---

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

[zsystm]

@cloudgray
Since the actual type of s.cacheCtx.MultiStore() at this point is *snapshotmulti.Store, I think it's clearer to cast it explicitly rather than going through the storetypes.CacheMultiStore interface.

While *snapshotmulti.Store does implement CacheMultiStore, making that implicit assumption here could lead to confusion for future maintainers who aren’t aware of the underlying implementation. Being explicit improves readability and reduces ambiguity in understanding what store we’re operating on.

I checked that there are no errors after the suggested change.

[zsystm]

Suggested change

	s.cacheCtx.MultiStore().(storetypes.CacheMultiStore).Write()
	s.cacheCtx.MultiStore().(*snapshotmulti.Store).Write()

[zsystm]

Suggested change

	s.cacheCtx.MultiStore().(storetypes.CacheMultiStore).Write()
	snapshotStore.Write()

[zsystm]

Just curious — what’s the purpose of benchSink here?

[zsystm]

Minor naming suggestion: would it be possible to rename the cms variable to something like ss or snapshotStore?

Since cms often refers to CacheMultiStore in the SDK context, it might be a bit misleading here, especially if it’s actually a snapshotmulti.Store. Renaming it could help reduce confusion for readers familiar with the SDK naming conventions.

[zsystm]

@cloudgray
Left a couple of nits, but overall LGTM — nice work!