# OVM 2.0 Changeset
During the next regenesis (Early October on Kovan, End of October on the main network), we will have a series of breaking changes as a part of an upgrade to the OVM. Fundamentally, this will drastically reduce the differences between the OVM and EVM so that developers can implement their contracts with mostly just one target in mind, instead of managing OVM idiosyncrasies with separate contracts. Thus the changes can be viewed as a reversion to most things listed on this page https://community.optimism.io/docs/protocol/evm-comparison.html. Here is the list of key breaking changes to watch for:
Contracts whose source code has been verified will be recompiled with the standard Solidity compiler. As a result of this:
CODESIZEof every contract will change. Any hardcoded values will break.
- The address generated by
CREATE2may be different (it depends on the constructor code).
- Code size will no longer be increased during compilation. Any custom OVM work that required reducing code size could now be reverted.
- Uniswap pools will be moved to their L1-equivalent
addresses corresponding to
CREATE2with the new bytecode. For more detail, see the Uniswap section below
ETH will no longer be ERC20 compatible.
- Users will no longer be able to transfer and interact with ETH
as an ERC20 located at
- Please let us know if you rely on this functionality on Optimistic Ethereum mainnet currently as we will have to migrate those balances to a standard WETH9 contract which will be deployed to a new TBD address
Transferevent currently emitted on ETH fee payment will be removed
- Users will no longer be able to transfer and interact with ETH as an ERC20 located at
Our fee scheme will be altered. See here for details
EOAs will no longer be contract wallets
- Currently, every new EOA in Optimistic Ethereum deploys a proxy contract to that address, making every EOA a contract account.
- After the upgrade, every known contract account will be reverted to an EOA with no code.
- To best handle the upgrade, we recommend you write your contracts to handle normal EOAs and to make no assumptions around EOAs having code or additional OVM-specific functionality.
Gas usage will decrease to be the same as on L1 Ethereum.
- Currently, the OVM results in an increase in gas usage because of compiled OVM opcodes, sometimes inflating gas costs by up to 10x the costs on L1 Ethereum.
- With this OVM upgrade, gas usage on Optimistic Ethereum should now exactly match the expected gas usage from a deployment to (L1) pre-London Ethereum in almost all cases.
Certain opcodes will have updated functionality:
block.numberin L2 will now correspond to the L2 block number, not “Last finalized L1 block number” like it used to. Any project currently using
block.numbermust check that this will not break their implementation. The L1 Block number will be made accessible via a new predeployed contract.
COINBASEis set by the sequencer. For the near-term future, it will return the
DIFFICULTYwill return 0
BLOCKHASHwill return the L2 block hash. Note that this value can be manipulated by the sequencer and is not a safe source of randomness.
SELFDESTRUCTwill now work just as it currently works in the EVM.
GASPRICEwill now return the l2GasPrice
BASEFEEwill be unsupported - execution will revert if it is used.
ORIGINwill be supported normally.
Certain OVM system contracts will be wiped from the state. We will remove:
All other OVM predeploys will remain at the same addresses as before the regenesis
TIMESTAMPwill function the same as before, updating with each new deposit or after 5 minutes if there has not been a deposit.
TIMESTAMPwill still correspond to "Last Finalized L1 Timestamp" - See here for details
As bytecode is updated, the codeHash for Uniswap pools will be altered, as will be their CREATE2 addresses. This means we will be shifting all Uniswap pools to new CREATE2 addresses corresponding to the updated pool bytecode.
We will also be migrating the ERC20 balances of each Uniswap pool to their new CREATE2'ed addresses.
If your contracts rely on Uniswap pool addresses, ensure that
you calculate them using the
As with all regenesis-es, all historical transactions and logs will be inaccessible from the new chain, and the new chain will start from Block #0. The old chain data will not be accessible except under extreme circumstances. Applications like Dune Analytics, Tenderly, Etherscan, and the Graph will not support access to transactions or logs from before the regenesis.