Upgrade: v1.16.9

[tomaszslabon]

References: https://linear.app/thesis-co/issue/MEZO-4003/geth-fork-update

Introduction

This PR upgrades mezo-org/go-ethereum to version 1.16.9 of ethereum/go-ethereum.
All the Mezo-specific features are applied as the last commit in the repo.

Changes

To upgrade cleanly, we first reverted the Mezo-specific features (custom precompile support), then merged with 1.16.9. The Mezo-specific features are be applied on top of the merge commit and are visible as a single commit.

Commands executed:

1. Revert the commits with Mezo-specific features:

git revert 962df8ac8  # Revert "Fixed STATICCALL precompile execution"
git revert 7aac5baf1  # Revert "Added precompile context unit tests"
git revert 2836c12d6  # Revert "fix precompiles addresses"
git revert 3d0e225ba  # Revert "Adding custom precompiled support"

2. Merge upstream ethereum/go-ethereum v1.16.9:

git merge v1.16.9

3. Replay the reverted commits and solve conflicts:

git cherry-pick 3d0e225ba
git cherry-pick 2836c12d6
git cherry-pick 7aac5baf1
git cherry-pick 962df8ac8

Compilation can be quickly verified with: go test ./... -run '^$' after each cherrry-pick.

4. Sqush all Mezo-specific commit into one commit - see the very last commit.

5. Try using in mezod - use the version from this branch.

Testing

• Run unit tests

go test -timeout 900s ./...

• Run system tests / manual testing with mezd that uses the upgraded library (see PR).

[lukasz-zimnoch]

While we're reshaping this layer, worth looking at whether we can cut the Mezo-specific surface down to the minimum and lean on upstream v1.16.9 for the rest. Right now we're carrying several things that duplicate or shadow what geth already provides:

• DefaultPrecompiles(rules) duplicates upstream's ActivePrecompiledContracts(rules).
• DefaultActivePrecompiles(rules) is upstream's ActivePrecompiles(rules) renamed.
• WithPrecompiles(map, slice) + the activePrecompiles field carry redundant state — the slice is always maps.Keys(precompiles), and they can desync (already do in SetPrecompiles).
• ValidatePrecompiles only exists to check that the slice matches the map.
• EVM.ActivePrecompiles(rules) returns the cached slice.

All of that can collapse into two additions:

// WithCustomPrecompiles overlays customs on top of the precompile set the EVM
// already holds. Panics if a custom precompile collides with an existing entry.
func (evm *EVM) WithCustomPrecompiles(customs map[common.Address]PrecompiledContract) {
    // Clone before mutating. On a freshly constructed EVM, evm.precompiles is
    // a reference to a package-level map (PrecompiledContractsOsaka,
    // PrecompiledContractsPrague, etc.) shared across every EVM in the
    // process. Writing to it in place would corrupt the global and race with
    // concurrent transaction processing.
    merged := maps.Clone(evm.precompiles)
    for addr, pc := range customs {
        if _, exists := merged[addr]; exists {
            panic(fmt.Sprintf("custom precompile %s shadows an existing precompile", addr))
        }
        merged[addr] = pc
    }
    evm.precompiles = merged
}

// Precompiles returns the precompile map of this EVM instance.
func (evm *EVM) Precompiles() map[common.Address]PrecompiledContract {
    return evm.precompiles
}

Why the clone is required

Upstream NewEVM does evm.precompiles = activePrecompiledContracts(chainRules), which returns a reference to a package-level map (PrecompiledContractsOsaka, PrecompiledContractsPrague, etc.). Every EVM in the process shares that map. Mutating it in place would corrupt the global and produce concurrent map writes crashes under concurrent transaction processing — exactly what the comment at mezod/x/evm/keeper/state_transition.go:101 warns about today. Cloning inside WithCustomPrecompiles is what lets us layer customs safely.

What gets deleted

• DefaultPrecompiles, DefaultActivePrecompiles — callers use upstream's ActivePrecompiledContracts and ActivePrecompiles (same semantics, built-ins only).
• WithPrecompiles, ValidatePrecompiles, the activePrecompiles field, and the EVM.ActivePrecompiles(rules) method.
• EVM.Precompile(addr) can be unexported back to evm.precompile(addr) — nothing in mezod calls it directly. Please double check though - there is a chance this may be used in other packages of go-ethereum.

What stays

• SetPrecompiles(map) (upstream already has it; used by the RPC state-override path).
• The PrecompiledContract interface extension (Address() + Run(evm, contract, readonly)).
• Per-built-in Address() implementations.
• evm.readOnly propagation for STATICCALL.

Required changes in mezod

• x/evm/types/tracer.go:62: vm.DefaultActivePrecompiles(rules) → vm.ActivePrecompiles(rules).
• x/evm/keeper/state_transition.go:107-124: the ~20-line clone + merge + WithPrecompiles(map, slice) block collapses to evm.WithCustomPrecompiles(customs). The maps.Clone(vm.DefaultPrecompiles(...)) call goes away — the library handles the clone internally.
• x/evm/keeper/state_transition.go:487: evm.ActivePrecompiles(rules) → maps.Keys(evm.Precompiles()).

Consequences

We preserve upstream's split between global-shared (default) and instance-owned (customized) precompile maps. An EVM that never calls WithCustomPrecompiles keeps pointing at the package-level global (no allocation); only EVMs that inject customs pay for a per-instance clone. That mirrors the behavior upstream's SetPrecompiles path already establishes.

Customs remain visible only through the EVM instance — rule-based resolvers (ActivePrecompiles, ActivePrecompiledContracts) continue to describe built-ins only. No tracer or access-list migration is involved here; the existing split is preserved.

Two method additions on top of upstream, no parallel bookkeeping.

[tomaszslabon]

I updated the implementation as suggested.
I also used the latest commit in mezod and checked that system tests pass.