[Flow EVM] Optimize EVM and Cross-VM Bridge

[fxamacker]

Look into optimizing EVM and Cross-VM Bridge. This issue can be used to track some ideas for potential optimizations and progress.

So far, I looked into reducing conversion overhead and will look into other areas for potential optimizations.

Reduce Conversion Overhead

We can reduce conversion overhead between EVM functions and internal EVM functions.

I listed potential optimizations on Slack about reducing conversion overhead between EVM functions and EVM internal functions.

• Optimize internal function calls that receive EVMAddress as Cadence ArrayValue by using a different data type. An ArrayValue with 20 elements requires 20 individual conversions.

• [Flow EVM] Optimize by creating wrapper functions to reduce conversion overhead #8405

  • Create a wrapper EVM function to combine EVM.encodeABIWithSignature and CadenceOwnedAccount.call.
  • Create a wrapper EVM function to combine dryCall /call and EVM.decodeABI.

• @m-Peter Modify contracts to use the optimized functions introduced by [Flow EVM] Optimize by creating wrapper functions to reduce conversion overhead #8405.

• Optimize copying of Cadence ArrayValue representing a Go byte slice under the hood.  There are other internal EVM functions that create an ArrayValue from a Go byte slice or copy an ArrayValue representing a Go byte slice.  We can optimize these types of operations in Atree and Cadence.

  • Atree: Add two new functions to optimize atree array and Go []byte conversions atree#629
  • Cadence: Optimize Cadence ArrayValue and Go []byte conversions (up to 13.7x faster and 8x less memory) cadence#4443
  • Atree: Add support for faster copying of array and map atree#633
  • Cadence: Optimize transferring array, dict, and composite (e.g., 2x faster for byte arrays) cadence#4448

See "Quick Hits" (below) and for other optimizations (low-hanging fruit and self-explanatory).

Quick Hits

These quick-hits are less complex optimizations that I referred to as "low-hanging fruit" and didn't list individually on Friday morning (Feb 6, 2026).

Additional quick-hits I found after Feb 6, 2026 are marked with 🆕.

• PR [Flow EVM] Optimize EVMDecodeABI by removing an ArrayValue iteration #8397
• PR [Flow EVM] Optimize EVMEncodeABI by removing an ArrayValue iteration #8398
• PR [Flow EVM] Optimize EVMEncodeABI by creating Go reflect types at startup and reusing them #8399
• PR [Flow EVM] Optimize EVM dryCall by removing RLP encoding/decoding #8400
• 🆕 PR [Flow EVM] Optimize and reduce computation cost of four EVM functions #8434

Other Optimizations

Other optimizations for us to look into:

• [Flow EVM] Optimize block formation #6958 (thanks @bluesign!)

Non-Optimization Work

The Cadence team needs to update or add new metering kinds as needed.

I think @janezpodhostnik will need to assign weights to newly added metering kinds.

Caveats

Some optimizations will involve native Go code. As @janezpodhostnik noted in Feb 9 Execution Meeting, if an optimization uses native Go code, we need to recalibrate for fees to reflect the improved efficiency.

Schedule

On February 20, 2026, I was asked to pause this work to help with a more time-sensitive project due at the end of February 2026.

[bluesign]

I think DeltaView rewrite would be the big hit. ( for quick fix: at least to iterate it like @m-Peter did [0] for accesslist but reverse in statedb )

[0]

flow-go/fvm/evm/emulator/state/stateDB.go

Lines 347 to 370 in 4cdbeb0

	func (db *StateDB) SlotInAccessList(addr gethCommon.Address, key gethCommon.Hash) (addressOk bool, slotOk bool) {
	slotKey := types.SlotAddress{Address: addr, Key: key}
	// For each static call / call / delegate call, the EVM will create
	// a snapshot, so that it can revert to it in case of execution errors,
	// such as out of gas etc, using `Snapshot` & `RevertToSnapshot`.
	// This can create a long list of views, in the order of 4K for certain
	// large transactions. To avoid performance issues with DeltaView checking parents,
	// which causes deep stacks and function call overhead, we use a plain for-loop instead.
	// We iterate through the views in ascending order (from lowest to highest) as an optimization.
	// Since slots are typically added to the AccessList early during transaction execution,
	// this allows us to return early when the needed slots are found in the initial views.
	addressFound := false
	end := len(db.views)
	for i := range end {
	view := db.views[i]
	addressFound, slotFound := view.SlotInAccessList(slotKey)
	if slotFound {
	return addressFound, true
	}
	}
	return addressFound, false
	}

[fxamacker]

Quick update:

• Friday afternoon, February 20: I was asked to help review more urgent work in unfamiliar code base, and pause work on these optimizations starting Monday, Feb 23.

• Saturday and Sunday Feb 21-22: I implemented some of the in-progress optimization work and estimated impact (15-20% on the open yield vault transaction). It only used a subset of optimizations found so far.

• Feb 23-27: As requested, mostly paused work on this optimization project to prioritize reviewing, modifying, or debugging other projects. For example, PR 8419, PR 8467, PR 8424, PR 4442, and branch leo/v0.44.1-token-movements-inspect.1.

• Friday, Feb 27, Jan mentioned in the public sprint kickoff doc that this project showed 15-20% improvement in FYV transaction cost.

NOTE: Amount of improvement will be different for various transactions. Also, the 15-20% improvement (that I benchmarked without recalibration using open yield vault) is only for a subset of the optimizations found so far.