[bysomeone]

What

Fixes the EVM-internal CREATE address derivation described in #1351.

opCreate derived the address from hash(txHash || origin), so every internal CREATE in a transaction got the same address. EVM.Create additionally accepted an existing account, so a second child silently overwrote the first while the transaction still reported success.

How

New dapp fork ForkEVMContractCreateV2. Like ForkEVMTransferRevert, it is registered at MaxHeight (off by default) and the templates set -1, so every chain opts in with a concrete height in its deployment configuration. Enabling it from genesis on an existing chain would rewrite historical execution. Fork-off execution is unchanged.

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.
• CREATE / CREATE2 return ErrContractAddressCollision and consume the forwarded gas when the target already has a nonce or code.
• ErrCodeStoreOutOfGas rolls the creation back instead of keeping the account and pushing its address.
• CREATE / CREATE2 forward 63/64 of the remaining gas (EIP-150). CREATE2 no longer halves the gas and converts value precision for ETH-signed transactions the same way CREATE does.

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/...
• New tests cover:
  • fork-off: the address is exactly hash(txHash||origin) and no nonce is written to contract state
  • fork-on: addresses checked against crypto.CreateAddress, twice in one transaction
  • CREATE2 collision returns zero
  • nonce persistence across transactions and executor instances
  • a failed CREATE still consumes a nonce
• 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).

• Enable it at the same height as ForkEVMTransferRevert. This fork keeps the nonce of a failed CREATE; only the transfer-revert fork rolls back the value attached to it, so 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.

[bysomeone]

Superseded by #1354, which folds the CREATE fix, the missing opcodes (#1352) and the gas model into a single fork, ForkEVMCompat, behind one activation height.