为 Optimism Rollup上开发 Dapp 准备的脚手架

Optimism 的 Optimistic Rollup 主网发布在即！ 我们在热切的期待中，因此我们为 Optimisim 的早期参与者准备了一个 scaffold-eth（脚手架）的专门分支（分支名为：local-optimism），脚手架包含以下内容：

• 运行本地链(L1)与 Optimistic Rollup (L2)。
• L1 和 L2 交互
• 在 L1 和 L2 之间移动 ETH
• 在 L2 部署智能合约
• 创建自己的 ERC20 代币桥接！

这些工作仍在进行中：这是在一个全新的协议上的全新的构建方式，所以预计一切都会发展和变化：），欢迎反馈！

如果你想直奔主题， 代码在这里(步骤在 README 中)。

关于 Optimism 的 Rollup 是如何工作的，其他人已经写了更详细的。 这篇文章的重点是我们可以在乐观的以太坊上做什么，如何运行和开发...

我们开始吧！

运行一个具有 Rollup 的本地链

你需要安装 Docker!

在本地几条链，让他们互相交互，不是件容易的事。 值得庆幸的是，Optimism 团队提供了一个开箱即用的集成仓库，包含了运行所需的六个 Docker 容器。 这是 local-optimism 分支的一部分，作为 Git 子模块提供。 当你把 repo 拉下来的时候，你需要启动&更新子模块，然后就是一个命令就可以把整个东西创建起来。

cd docker/optimism-integration && make up

启动并运行

有点像飞船起飞的感觉！

看日志可以很实际的感受到 Optimism 的工作原理--首先初始化一个 L1 链，并部署 Optimism 核心合约，然后初始化几个在 L1 和 L2 之间传递信息服务，最后启动 L2 geth 实现。

如果一切顺利，我们就可以开始了！

Rollup 与本地链交互

Optimism 实现的真正优势之一是与 EVM 的兼容性 -- 在很多方面，它就像改变 RPC URL 和 chain ID 一样简单。

l1Local: { rpc: "http://localhost:9545", chainId: 31337 }

l2Local: { rpc: "http://localhost:9545", chainId: 420 }

l2Kovan: { rpc: "https://kovan.optimism.io", chainId: 69 }

当然，也有一些需要考虑的差异，这里让我们边走边讲。

从用户和开发者的角度来看，需要考虑的主要问题之一是如何处理 L1 和 L2 网络，哪些要呈现给用户，以及如何确保钱包连接到正确的网络。

使用自定义网络 API，可以很好的解决后一个问题(在这个分支中还没有实现--欢迎 PR!)

在这个分支中，我们实例化了两个 provider(提供者)和两个 singer(签名者)，因为我们要支持与本地链和 Rollup 的交互。

一个钱包有两个余额!

在 L1 和 L2 之间转移 ETH

本地 Rollup 和目前在 Kovan 上的部署不需要任何交易费用，但这将是主网的一个关键过渡。 我们有一个简单的 OptimisticETHBridge 组件，它可以显示用户在 L1 和 L2 的余额，并允许他们存款到 L2 或从 L2 取款。

L1/L2桥

存款是指在 L1ETHGateway 合约上调用 payable deposit 函数，存入你想存入的数量。该合约作为 Optimism 初始化的一部分进行部署，在本地设置上的部署地址总是相同的（可以检查一下部署日志），但在 Kovan 上是不同的。

在 Optimism 上，没有原生的 ETH，ETH 只是一个 ERC20 的代币（虽然是部署在预部署地址的代币，在任何 Rollup 上都是一样的），提现是转入到 ERC20 合约中。

await l2Tx(L2ETHGatewayContract.withdraw(
            parseEther(values.amount.toString())))

该组件还为 L1 和 L2 内置了简单的 Send 功能。

Optimism 团队短期内正在研究的难题：

• 目前 L2 还不支持用 { value } 发送的交易，所以我们实例化一个 ethers.js 合约，并调用 transfer。
• 目前在 L2 上实现的 geth 版本并不像在 L1 上那样抛出 transactionResponse，需要 wait() 等待 transactionReceipt。 在 scaffold-eth 中，这意味着要给我们的 Transactor helper 增加一行。

result = await signer.sendTransaction(tx);
await result.wait()

在 Optimism 上进行部署合约。

Optimism 的主要关注点之一是转移性，从 EVM 到 OVM。 因此，我们只需要做一些小的改动，就可以使我们的现有 scaffold-eth 上的合约在 L2 上可行--我们只需要在我们的 hardhat 配置中导入 Optimism 编译器(然后编译所有合约，除非有 //@unsupported: ovm 标志的合约)，然后使用 Optimism ethers variant 来部署我们的合约。

const { l2ethers } = require("hardhat");

...

contractArtifacts = await l2ethers.getContractFactory(contractName, signerProvider);
const deployed = await contractArtifacts.deploy(...contractArgs, overrides);
await deployed.deployTransaction.wait()

请注意前面提到的 wait()!

有一些细微的差别--我们不能使用内置的 Hardhat 网络，必须实例化我们自己的提供者和签名者。

我们不需要对合约做任何修改，尽管可能不一定是这样，例如对 .balance 的调用会在编译时抛出一个错误。 一般来说，编译器的错误对追踪问题都很有帮助。

我们确实做了一些改动，在 Optimism 上出块时间 block.timestamp 确实存在，但却是对 L1 时间的引用。 有两件动作会更新了 L2 上的时间： 从 L1 到 L2 的桥接信息，以及按设定频率( 心跳)定期更新 L2 时间。

这确实给处理 L2 上的时间时产生了一些有趣的挑战，因为获取的 block.timestamp 总是过去的。 以后还会有更多的思考...

在一个非常实际的问题上，这意味着在本地开发中，你需要定期在本地链上进行交易，以保持你的 L2 时间的更新！

在 Optimism 的桥接：古英语 ERC20

虽然对于很多使用场景来说，使用他人部署的 ETH 桥和代币桥 可以满足大部分 L1 到 L2 桥接的需求，但我们也想了解如何将自己的 L1 ERC20 转移到 L2，以及如何返回。

幸运的是，Optimism 团队在他们合约包 提供了一些参考合约，再加上有用的教程，所以我们能够把它们拉到我们的分支中，我们将部署三个合约：

• ERC20.sol：在 L1 上，这是 真理之源---- 一个简单的 ERC20 实现，有一个 mint(value) 函数，允许任何人自己铸造一些代币。
• L1ERC20Gateway.sol：也是在 L1 上，这允许我们向 L2 存款，同时锁定代币。
• L2DepositedERC20.sol：该合约部署在 L2 上，它也是一个 ERC20 的实现，当新的代币从 L1 存入时，它就将其铸成新的代币，当它们被提取时，就将其销毁。

部署顺序很重要，因为 L1ERC20Gateway 需要知道 ERC20 地址和 L2DepositedERC20 地址，然后需要通过 init() 与 L1ERC20Gateway 地址激活 L2DepositedERC20 合约，完成连接。 我们部署的合约分别与 L1Messenger 和 L2Messenger 进行通信，以进行存款和提款。

部署完成后，我们就可以测试桥接功能了，可以在前端应用中测试，也可以在直接在部署脚本中测试。

L1ERC20Gateway 必须经过批准才能转移代币，才能启动整个事情。

目前有在进行一个想法，希望有一个通用的用于 ERC20 代币的桥接，这样的桥接在生产中可能不需要，但它仍然是一个有益的概念验证，以方便本地开发。

显然，下一步的关键是上测试网（然后上主网！）local-optimism 分支包含了去 Kovan 部署 Optimism 的配置选项，就像更新 App.js 中的 selectedNetwork，以及从 Hardhat 部署时的 defaultNetwork 或 --network 参数一样简单。

但更大的问题是，在 Optimism 上构建什么！

我们将在未来几周内发布更多的试运行、概念验证，甚至可能是成熟的产品。欢迎关注。

如果你还没有- 获取分支， 那就赶快尝试一下吧。

非常感谢来自 Optimism 的 Ben 和 Kevin 的有益回答，以及 Austin Griffith的帮助、努力和支持！

---

本翻译由 Cell Network 赞助支持。