compatibility between Optimism & Ethereum Layer1

网络情况

Optimism Kovan将要被弃用，取而代之的是 Optimism Goerli，目前Alchemy、Infura都已经支持了 Optimism Goerli

10 月 5 日，Optimism Kovan 将全面退役<div id="refer-anchor-1"></div>

EVM等效性

Optimism 客户端软件，是一个几乎完全是原版的Geth. 这意味着 Optimism 在本质上与以太坊几乎相同。特别是Optimism 共享同一个以太坊虚拟机，相同的账户和状态结构，以及相同的燃气计量机制和收费表. 我们将此架构称为“EVM 等效”这意味着大多数以太坊工具（即使是最复杂的工具）“只适用于”Optimism。

In a multi-chain world, “write once, deploy everywhere” becomes critical.

修改的操作码

import { iOVM_L1BlockNumber } from "@eth-optimism/contracts/L2/predeploys/iOVM_L1BlockNumber.sol";
import { Lib_PredeployAddresses } from "@eth-optimism/contracts/libraries/constants/Lib_PredeployAddresses.sol";

contract MyContract {
  function myFunction() public {
     uint256 l1BlockNumber = iOVM_L1BlockNumber(
         Lib_PredeployAddresses.L1_BLOCK_NUMBER // located at 0x4200000000000000000000000000000000000013
     ).getL1BlockNumber();
  }
}

为什么需要 Address Alias

对于 L1->L2 消息，如果 msg.sender 为合约，那么在 L2 执行时，Origin 会被加上偏移。这是出于安全考虑，举例如下：

首先，攻击者在 L2 构造一个开放源码的合约，如 Uniswap pair，并诱导用户对合约授权 (approve())

然后，攻击者在 L1 同一地址部署恶意合约，并通过该恶意合约向 L2 传递攻击消息，取出用户授权的 ERC20 token；参数如下：

解决方案：

经过讨论：What should the value of tx.origin and msg.sender be for L1 to L2 transactions? #1480，决定参考 Arbitrum 的方案，通过 Address Alias 对msg.sender 地址做了偏移；由于哈希的抗碰撞性，攻击者无法计算相关参数 (如 Create nonce 或 Create2 salt)，因此无法将合约部署在偏移前的地址。

案例：2000万OP被盗背后

Gas Fee

L2交易

在L2上发生的交易由两部分费用，一部分是L2交易执行费，另外一部分是L1数据费，也就是数据同步到L1层上链的费用

估算 L2 执行费用

可以通过将 gas_price * gas_limit 来估算 L2 执行费用，就像在以太坊上一样。

估算 L1 数据费用

可以使用 SDK GasPriceOracle或者可以使用位于以下位置的预部署智能合约估算 L1 数据费用0x420000000000000000000000000000000000000F . 合约_GasPriceOracle 位于每个 Optimism 网络（主网和测试网）上的相同地址。为此，请调用GasPriceOracle.getL1Fee(<unsigned RLP encoded transaction>)。

参考