[bysomeone]

What

Two EVM incompatibilities, both gated by one new dapp fork, ForkEVMCompat:

1. Internal CREATE derived a colliding address (EVM 合约内部 create（Solidity new）地址冲突：同一笔交易内 factory 创建的多个子合约地址相同，后者覆盖前者，且交易显示成功 #1351). opCreate used hash(txHash || origin), so every internal create in a transaction received the same address, and EVM.Create accepted an existing account: a second child silently overwrote the first while the transaction still reported success.
2. PUSH0 (0x5f) and BASEFEE (0x48) were missing (evm: PUSH0 (0x5f) and other Shanghai/Cancun opcodes are missing from the instruction set #1352). Solidity 0.8.20 and later emit PUSH0 by default, so a contract compiled with a current solc cannot be deployed at all.

How

ForkEVMCompat is registered at MaxHeight (off by default) and the templates keep it at -1, so each chain opts in with a concrete height. Enabling it from genesis on an existing chain would rewrite historical execution.

Fork on:

• CREATE address = CreateAddress(executing account, its nonce). The caller nonce is incremented before any create snapshot and persisted in contract state, so it survives across transactions and failed creates. New contracts start at nonce 1 (EIP-161), an account with a nonce is no longer treated as non-existent, and CREATE / CREATE2 return ErrContractAddressCollision when the target already has a nonce or code.
• CREATE / CREATE2 forward 63/64 of the remaining gas (EIP-150), forward value with the same precision conversion CREATE uses, and roll back on ErrCodeStoreOutOfGas instead of keeping the account.
• PUSH0 pushes zero and BASEFEE returns zero, both at 2 gas. The chain has no base-fee mechanism.

Fork off, execution is unchanged: the previous CREATE address derivation, the Berlin instruction set, the gas constants and the refund handling are untouched.

Address construction for the new path bypasses the chain33 address driver: a btc-format driver cannot parse a 0x hex string and produced an all-zero raw address.

Testing

• go test ./plugin/dapp/evm/... (bn256/cloudflare fails on macOS with a dyld: missing LC_UUID load command error; the package does not depend on anything here)
• New tests cover, for fork off and fork on:
  • the CREATE address matching crypto.CreateAddress, twice in one transaction; nonce persistence across transactions and executor instances; a failed CREATE still consuming a nonce
  • CREATE2 collision returning zero
  • PUSH0 / BASEFEE being invalid opcode when off and executing when on
  • the fork being registered off by default, and the value a failed CREATE keeps when only ForkEVMCompat is on
• go test ./plugin/dapp/evm/executor/ -shuffle=<seed> is order-independent; a pre-existing global address-driver leak from query_test.go was fixed for that.

Deployment note

The fork has to be enabled with a real height in the deployment repository; the templates here keep it off (-1). Every existing chain configuration must list ForkEVMCompat once this release is deployed — the fork is registered in code, and a configuration that omits it fails the fork check at startup.

• Enable it at the same height as ForkEVMTransferRevert. That fork rolls back the value attached to a failed CREATE, which this one alone does not do; the full Ethereum semantics need both.
• Chains that accept ETH-signed transactions must configure [exec.sub.evm] addressDriver="eth". The internal CREATE path here does not depend on the driver, but the pre-existing top-level ETH-signed deploy path still does.
• Contracts deployed before the fork have no nonce record (treated as 0), so their first post-fork internal CREATE does not match Ethereum exactly; contracts deployed after the fork match exactly.

Not covered

No gas metering changes: cold/warm access accounting, net SSTORE metering and EIP-3529 refunds are not part of this fork, so gas numbers differ from Ethereum for contracts that are sensitive to them. MCOPY, TLOAD/TSTORE, DIFFICULTY/PREVRANDAO, the precompile table and the SELFDESTRUCT pricing are unchanged.