Deploying to Ethereum Layer 2 Networks

Hello! Welcome to the first lesson in our module on the multi-chain ecosystem. Given your extensive background in development, you're likely familiar with the concept of deploying applications to different environments. In the world of blockchain, this often means deploying to different networks.

Today, we'll focus on a critical part of the modern Ethereum landscape: Layer 2 (L2) networks. Our goal is to learn how to deploy and verify a smart contract on an L2, specifically using Arbitrum and Optimism as our examples.

We'll cover:

• The role of L2s in scaling Ethereum.
• The importance of contract verification for transparency and trust.
• The practical steps to configure your development environment (Hardhat and Foundry) for L2 deployment.
• The process of deploying a contract and verifying it on an L2 block explorer like Arbiscan.

This lesson will build a practical foundation for the rest of the module, where we'll explore how these different chains can communicate with one another.

Why Deploy to Layer 2?

Before we jump into the "how," let's briefly touch on the "why." As Ethereum has grown in popularity, the demand for block space has led to higher transaction fees (gas costs) and slower confirmation times. Layer 2 solutions are designed to address this by processing transactions "off-chain" (on their own separate, faster chain) and then periodically submitting a summary of those transactions back to the main Ethereum blockchain (Layer 1).

For a quick and clear overview of how Arbitrum fits into the Ethereum ecosystem, please read the short section below from the official Arbitrum documentation.

In essence, by deploying on an L2, you offer your users significantly lower fees and faster interactions while still benefiting from the security of the underlying Ethereum network.

The Importance of Contract Verification

Once a contract is deployed, its bytecode is publicly visible on the blockchain, but it's not human-readable. Verification is the process of linking that bytecode back to the original Solidity source code.

Why is this essential?

• Trust and Transparency: It proves that the deployed code does exactly what the source code claims. Users and other developers can inspect the code to check for vulnerabilities or malicious logic.
• Interoperability: A verified contract provides a clean Application Binary Interface (ABI) on the block explorer, allowing anyone to easily read its state and call its functions directly from the explorer's UI.

To see the difference firsthand, watch the first minute of the following video. It clearly demonstrates the user experience of an unverified contract versus a verified one.

Now that we understand the what and why, let's get hands-on.

Deploying to Arbitrum with Hardhat

We'll start by deploying a contract to the Arbitrum Sepolia testnet using Hardhat. The overall process is very similar to deploying to an L1 testnet, with the main differences being in the configuration.

The following video provides a complete walkthrough. While it uses a slightly outdated testnet (Rinkeby), the core steps—configuration, funding, deployment, and verification—remain the same. We will adapt this process for the modern Arbitrum Sepolia testnet.

Now, let's apply those concepts to the Arbitrum Sepolia testnet.

1. Project Setup and Configuration

Assuming you have a standard Hardhat TypeScript project, your first step is to update hardhat.config.ts. You need to add a network configuration for Arbitrum Sepolia and an API key for Arbiscan to enable automated verification.

Here is a sample configuration. Notice the arbitrumSepolia network object and the etherscan object with a custom chain definition.

// hardhat.config.ts
import { HardhatUserConfig } from "hardhat/config";
import "@nomicfoundation/hardhat-toolbox";
import "dotenv/config";

const SEPOLIA_RPC_URL = process.env.SEPOLIA_RPC_URL || "https://sepolia.infura.io/v3/your-key";
const ARBITRUM_SEPOLIA_RPC_URL = process.env.ARBITRUM_SEPOLIA_RPC_URL || "https://sepolia-rollup.arbitrum.io/rpc";
const PRIVATE_KEY = process.env.PRIVATE_KEY || "your-private-key";
const ARBISCAN_API_KEY = process.env.ARBISCAN_API_KEY || "your-arbiscan-key";

const config: HardhatUserConfig = {
  solidity: "0.8.20",
  networks: {
    sepolia: {
      url: SEPOLIA_RPC_URL,
      accounts: [PRIVATE_KEY],
    },
    arbitrumSepolia: {
      url: ARBITRUM_SEPOLIA_RPC_URL,
      accounts: [PRIVATE_KEY],
    },
  },
  etherscan: {
    apiKey: {
      // No API key required for Sepolia, but good to have for other networks
      sepolia: '', 
      // Arbiscan API key
      arbitrumSepolia: ARBISCAN_API_KEY,
    },
  },
};

export default config;

What you need to do:

1. Install dependencies: Make sure you have dotenv installed (npm install dotenv).
2. Create .env file: Create a .env file in your project root.
3. Get an RPC URL: You can get a free one from services like Alchemy or Infura for ARBITRUM_SEPOLIA_RPC_URL.
4. Get an Arbiscan API Key: Create an account on Arbiscan (the block explorer for Arbitrum) and get a free API key. Add it to your .env as ARBISCAN_API_KEY.
5. Add your Private Key: Export the private key of your development wallet and add it to .env as PRIVATE_KEY. Remember to prefix it with 0x.

2. Fund Your Account on Arbitrum Sepolia

Transactions on L2 still cost gas, albeit much less than on L1. You'll need Arbitrum Sepolia ETH to pay for the deployment. The process is a two-step "bridge":

1. Get Sepolia ETH (L1): Use a public faucet like sepoliafaucet.com to get test ETH on the base Sepolia network.
2. Bridge to Arbitrum Sepolia (L2): Go to the Official Arbitrum Bridge and connect your wallet. Make sure you are on the Sepolia network, and then deposit your Sepolia ETH to Arbitrum Sepolia. The funds should arrive on the L2 within a few minutes.

You can add the Arbitrum Sepolia network to MetaMask using the details from the Arbitrum documentation (LINK) or by using a site like Chainlist.

3. Deploy and Verify

With your configuration set and your account funded, deployment is straightforward.

1. Run the deployment script:

   npx hardhat run scripts/deploy.ts --network arbitrumSepolia
   

   After a successful run, Hardhat will print the deployed contract address. Copy it.

2. Verify the contract:
   Instead of the manual copy-paste method, we can use Hardhat's built-in plugin. This is far more reliable, especially for contracts with imports.

   npx hardhat verify --network arbitrumSepolia <YOUR_CONTRACT_ADDRESS> "Constructor argument 1" "Argument 2"
   

   Replace <YOUR_CONTRACT_ADDRESS> with the address from the previous step and provide any constructor arguments your contract requires. If successful, you'll get a link to the verified contract on Arbiscan.

Deploying to Optimism with Foundry

To show the versatility of the process, let's briefly look at deploying to another major L2, Optimism, using a different toolchain, Foundry. The principles are identical: configure the network, fund the account, and run a command.

The GitHub repository below contains helpful snippets for deploying to Optimism with various frameworks. We'll focus on the Foundry approach.

Foundry's CLI, forge, is powerful and can handle deployment and verification in a single command.

1. Setup Environment Variables:
   Foundry typically reads environment variables directly from your shell.

   export OP_SEPOLIA_RPC_URL="https://sepolia.optimism.io"
   export PRIVATE_KEY="0x..."
   export ETHERSCAN_API_KEY="your-etherscan-key" 
   

   Note: Optimism's block explorer, Optimistic Etherscan, uses the same API key as Ethereum's Etherscan.

2. Fund Your Account:
   The process is identical to Arbitrum's:

   1. Get L1 Sepolia ETH from a faucet.
   2. Use the Official Optimism Superchain Bridge to transfer it to the Optimism Sepolia testnet.

3. Deploy and Verify with Forge:
   The forge create command deploys your contract. By adding the --verify flag, Foundry will automatically attempt to verify it on the block explorer after deployment.

   forge create --rpc-url $OP_SEPOLIA_RPC_URL \
     --private-key $PRIVATE_KEY \
     --etherscan-api-key $ETHERSCAN_API_KEY \
     --verify \
     src/YourContract.sol:YourContractName \
     --constructor-args "Argument 1"
   

   This single command handles everything. It compiles, deploys, and verifies, making for a very efficient workflow, which is one of Foundry's main strengths.

Conclusion

Congratulations on making it through this lesson! You are now equipped to deploy smart contracts to the leading Ethereum Layer 2 networks.

Key Takeaways:

• Deploying to an L2 is very similar to deploying to Ethereum L1, primarily requiring configuration changes for the specific network's RPC URL and Chain ID.
• Each L2 ecosystem has its own testnet (e.g., Arbitrum Sepolia, Optimism Sepolia), block explorer (e.g., Arbiscan, Optimistic Etherscan), and a bridge to move assets from L1.
• Contract verification is a crucial step for establishing trust and enabling interaction. Modern toolchains like Hardhat and Foundry provide plugins and flags to automate this process.
• Using automated verification is the professional standard, as it's faster and less error-prone than manually pasting code, especially for complex contracts with dependencies.

Preview of the Next Lesson:
Now that we've deployed a contract to a single L2, a natural next question arises: how can an application on Arbitrum interact with a contract on Optimism, or back on Ethereum? In our next lesson, we will describe the architectures and security trade-offs of different cross-chain communication patterns, setting the stage for building true multi-chain applications.