Blockchain and Web3 Development: Layer 2 and Scalability Bridges and Interoperability Polygon Arbitrum Optimism zkSync

What This Is

A blockchain bridge is a set‑of‑smart‑contracts and off‑chain relayers that let assets (ERC‑20, ERC‑721, state) move between two otherwise isolated chains. By “bridging” Ethereum to Layer‑2s such as Polygon, Arbitrum, Optimism, or zkSync, users can keep the security of the Ethereum mainnet while enjoying cheap, fast transactions on the L2. Real‑world: a DeFi trader swaps ETH for USDC on Uniswap (Ethereum), bridges the USDC to Polygon, and then supplies it to a lending pool that offers 10× lower gas fees.

Key Terms & Code Snippets

• Bridge Contract (Lock‑Mint pattern): The source chain contract locks the original token, while the destination chain contract mints a wrapped representation (e.g., PolygonUSDC).
  solidity // Source (Ethereum) – lock function lock(address token, uint256 amount) external {
IERC20(token).transferFrom(msg.sender, address(this), amount);
emit Locked(msg.sender, token, amount); }

• Message Passing (L2 → L1): A system where the L2 posts a calldata‑packed message to an L1 inbox; the L1 contract executes it after a challenge period.
  solidity // Optimism L2 → L1 IOptimismInbox(inbox).sendMessage(l1Target, calldata, gasLimit);

• Optimistic Rollup: Assumes blocks are valid unless a fraud proof is submitted. Faster & cheaper, but finality is delayed (usually 1‑7 days).

• ZK Rollup: Generates a succinct zero‑knowledge proof that proves state transitions are correct; finality is near‑instant because the proof is verified on‑chain.
• Polygon PoS Bridge: A set of contracts (RootChainManager, ChildChainManagerProxy) that handle ERC‑20/721 deposits and withdrawals between Ethereum and Polygon’s PoS sidechain.
• Arbitrum Nitro: The next‑gen Arbitrum rollup that uses AVM (Arbitrum Virtual Machine) for near‑EVM compatibility and retryable tickets for reliable L2→L1 messaging.
• Retryable Ticket: A special L2→L1 message that can be re‑executed until it succeeds or expires, preventing permanent loss of funds on transient failures.
• ERC‑20 ↔ ERC‑20 Bridge Wrapper: The L2 token inherits the original ERC‑20 interface but adds bridgeMint/bridgeBurn for the wrapped asset.
  solidity function bridgeMint(address to, uint256 amount) external onlyBridge {
_mint(to, amount); }
• Cross‑Chain Oracle (e.g., Chainlink CCIP): Provides a trust‑minimized way to verify that a bridge event really happened on the source chain.
• Gas‑Relay (Meta‑Transaction): Allows a dApp to pay the L2 gas on behalf of the user, useful when the user only holds ETH on L1.
• Finality Gap: The period between a transaction being executed on L2 and being considered final on L1; crucial for UI/UX and security.

Step‑by‑Step / Process Flow (Deploying a Token Bridge to Polygon)

1. Write the L1 lock contract in Solidity (see “Lock‑Mint pattern” above).
2. Compile & test with Hardhat: npx hardhat compile && npx hardhat test.
3. Deploy to Ethereum Goerli using an Infura/Alchemy RPC:
   js
const Bridge = await ethers.getContractFactory("EthBridge");
const bridge = await Bridge.deploy();
await bridge.deployed();
4. Register the L1 contract on Polygon’s PoS Bridge via the Polygon UI (or call setFxRootTunnel).
5. Deploy the L2 mint contract (inherits ERC20 + bridgeMint/burn).
6. Verify the pair by sending a test deposit from Goerli → Polygon’s Mumbai testnet:
   js
await bridge.lock(USDC_ADDRESS, ethers.utils.parseUnits("100", 6));
// Watch the `Locked` event, then call `bridgeMint` on the L2 side.
7. Integrate in the front‑end with @maticnetwork/maticjs or wagmi to abstract the bridge calls for users.

(For Arbitrum, Optimism, or zkSync replace steps 4‑6 with the respective SDKs: @arbitrum/sdk, @eth-optimism/sdk, @zksync/web3.)

Common Mistakes

• Mistake: Approving the L1 token but forgetting to approve the L2 wrapper.
  Correction: Always call approve on the L2 bridge contract after the first deposit; otherwise bridgeMint will revert.

• Mistake: Assuming instant finality after a L2→L1 message.
  Correction: Respect the challenge period (Optimism ≈ 7 days, Arbitrum ≈ 1 day). UI should show “Pending finalization” until the period ends.

• Mistake: Hard‑coding mainnet addresses when testing on testnets.
  Correction: Use environment variables (process.env.POLYGON_BRIDGE) and separate config files for each network.

• Mistake: Relying on tx.origin for access control in bridge contracts.
  Correction: Use msg.sender and role‑based AccessControl – tx.origin can be spoofed through a malicious contract.

• Mistake: Skipping the “withdrawal proof” step on Polygon (i.e., not submitting the Merkle proof).
  Correction: Call exit on the RootChainManager with the correct proof; otherwise funds stay locked forever.

Blockchain Developer Interview / Practical Insights

1. Trust Model Comparison: Be ready to explain why an Optimistic rollup needs a fraud‑proof window while a ZK rollup does not—focus on “data availability vs proof validity”.
2. Message‑Passing Mechanics: Interviewers love to ask how a retryable ticket differs from a normal L2→L1 message (re‑execution vs one‑shot).
3. Bridge Security Patterns: Mention the “two‑step withdrawal” (lock → proof → release) and why it mitigates “bridge‑steal” attacks.
4. Gas‑Cost Reasoning: Show you understand that a single L2 transaction can batch dozens of L1 state changes, dramatically reducing per‑tx gas (e.g., 10× cheaper on Polygon vs Ethereum).

Quick Check Questions

1. Scenario: A dApp lets users bridge ERC‑20 tokens from Ethereum to Arbitrum, but the UI immediately shows the new balance on Arbitrum after the transaction is mined on L1.
   Answer: Wrong – Arbitrum’s L2 state isn’t final until the retryable ticket is executed; the UI should wait for the L2 receipt.

2. Scenario: A bridge contract uses tx.origin == owner to restrict who can call bridgeMint.
   Answer: Dangerous – a malicious contract can forward a user’s transaction, making tx.origin the user while msg.sender is the attacker; use msg.sender with proper role checks.

3. Scenario: You need to withdraw USDC from zkSync to Ethereum. Which component must you interact with?
   Answer: The zkSync L2→L1 exit contract that verifies the zk‑proof and releases the locked token on Ethereum.

Last‑Minute Cram Sheet (10 one‑liners)

1. ⚠️ Security: Never trust tx.origin for auth; always use msg.sender + AccessControl.
2. Gas tip: Use uint256 for amounts; uint128 can save ~5% gas on storage‑heavy contracts.
3. Compiler: Most L2 bridges compile with pragma solidity ^0.8.17; avoid older versions that lack built‑in overflow checks.
4. ERC‑20 vs ERC‑777: ERC‑777 adds hooks (tokensReceived) useful for automatic bridge callbacks.
5. Optimistic finality: 7 days on Optimism, 1 day on Arbitrum – UI must reflect this delay.
6. ZK finality: Near‑instant (≈ 1 block) after proof verification; great for NFT bridges.
7. Polygon Bridge: RootChainManager (L1) ↔ ChildChainManagerProxy (L2) – always register the L2 token with the proxy.
8. Retryable Ticket: Can be re‑executed up to its expiry; always check ticketStatus before assuming success.
9. Cross‑Chain Oracle: Chainlink CCIP replaces custom relayers for trust‑minimized verification.
10. ⚠️ Attack vector: “Replay attack” on L2→L1 messages – always include a nonce or use the bridge’s built‑in replay protection.