Layer2 开发：从“在 L2 上写合约”到“自己发一条 L2”

一、先分清你是在“用 L2”还是在“发 L2”

绝大多数开发者需要的只是第一条路径。在 Arbitrum 或 Base 上部署合约，和在以太坊主网上部署的体验几乎一致：Foundry 编译、RPC 部署、前端用 viem 读取。区别只在 Gas 成本和区块确认速度。

第二条路径才涉及“Layer2 开发”的完整含义：运行排序器、配置桥接合约、选择数据可用性层、决定证明系统。OP Stack 目前承载了 50 多条生产链和超过 50% 的 L2 交易量。Arbitrum Orbit 在游戏垂直领域有明确的生态聚集，Polygon CDK 和 ZK Stack 则走 ZK 证明路线，提供近乎即时的最终性，代价是 EVM 兼容性存在边缘情况。

判断标准很简单：如果你的用户关心的是“你的应用好不好用”，而不是“你的链有什么独特经济模型”，你大概率不需要发链。

二、应用开发路径：在 L2 上部署合约

这条路径的工程实践已经高度标准化。以 Arbitrum 为例，本地开发用 nitro-devnode 启动一条模拟链，Solidity 合约用 Foundry 编译部署，前端用 viem 连接。

一个最小的部署脚本片段：

# 启动本地 Arbitrum 链
git clone https://github.com/OffchainLabs/nitro-devnode.git
cd nitro-devnode && ./run-dev-node.sh

# 用 Foundry 部署
forge script script/Deploy.s.sol \
  --rpc-url http://localhost:8547 \
  --broadcast \
  --private-key $PRIVATE_KEY

部署到测试网或主网时，只需要把 RPC URL 换成 Chainstack、Alchemy 或官方公共端点。Hardhat 的配置方式也类似，在 hardhat.config.js 中指定网络和私钥即可。

真正需要开发者留意的，不是部署命令本身，而是L2 特有的行为差异。Arbitrum 对交易的数据发布收取额外费用，一些为以太坊主网设计的硬编码 gas limit 的交易，在 Arbitrum 上可能因为数据费用不足而失败。如果你要部署 Multicall3、EntryPoint 或 create2 工厂这类确定性合约，且链的创世配置中没有预置，需要通过 Inbox.sendL2Message 从父链提交预签名交易来绕过 gas 限制。这不是“写合约”能解决的问题，是“理解目标链的收费模型”的问题。

三、链开发路径：OP Stack 的互操作是当前最值得关注的变化

如果你确实需要发一条链，2026 年最实质性的技术进展来自 OP Stack 的互操作性。它让同一组 OP Stack 链之间能够读取彼此的状态，ETH 和 ERC-20 通过原生铸造和销毁在链间移动，合约可以低延迟地组合其他链上的事件。

这个能力由几个预部署合约支撑：L2ToL2CrossDomainMessenger 处理大多数应用层的跨链消息，CrossL2Inbox 提供更低层的验证入口，SuperchainETHBridge 负责原生 ETH 转移。

一个用 Foundry 发起跨链消息的片段（需要在 Supersim 本地多链环境或 interop devnet 上运行）：

# 在目标链上部署接收合约后，通过 L2ToL2CrossDomainMessenger 发送消息
cast send $L2_TO_L2_MESSENGER \
  "sendMessage(uint256,address,bytes)" \
  $DST_CHAIN_ID \
  $RECEIVER_ADDRESS \
  $ENCODED_PAYLOAD \
  --rpc-url $SRC_URL \
  --private-key $PRIVATE_KEY

这里的关键设计决策不在代码里。互操作目前仍处于活跃开发阶段，部分功能被标记为实验性。这意味着你不能把它当作已经稳定的生产系统来规划业务逻辑。消息有过期机制，跨链重组的安全性依赖于排序器的诚实假设，依赖集（dependency set）的配置决定了哪些链的故障会传播到你的链上。发链之前需要想清楚：你需要的是“共享安全性的多链生态”，还是“一条独立运行的链”？OP Stack 的互操作提供的是前者，代价是对其他链的状态产生依赖。

四、ZK 路线的取舍：即时最终性 vs 工具链成熟度

Polygon CDK 和 ZK Stack 的核心卖点是有效性证明：每批交易附带一个密码学证明，无需像 optimistic rollup 那样等待 7 天挑战期。对于需要快速提款或跨链最终性的场景，这是实质性的优势。

但代价体现在两个地方。第一，EVM 兼容性不是 100%。CDK 和 ZK Stack 的文档都承认存在边缘情况，部分以太坊合约需要调整才能在 ZK 链上正确运行。第二，工具链的成熟度。Foundry 和 Hardhat 的 ZK 链适配仍在演进中，自定义预编译合约、调试工具和区块浏览器的支持不如 OP Stack 和 Arbitrum 完善。

Polygon CDK 结合 Avail 作为数据可用性层是一个被讨论较多的组合：交易数据发到 Avail 而非以太坊，利用数据可用性采样将成本降到接近零。但这个方案的信任假设发生了变化——你信任 Avail 的 DA 保证，而不是以太坊的。对于需要严格继承以太坊安全性的项目，这不是一个可以轻率做出的选择。

五、一条容易被忽略的建议

Layer2 开发中最昂贵的错误，发生在框架选择阶段，而不是编码阶段。框架决定了证明类型、结算路径、排序器经济学、可用的合作伙伴集成，以及未来能否低成本地迁移。技术上迁移框架是可能的，但运营上极其复杂：桥接合约需要重新审计，用户需要迁移资产，已经部署的合约状态无法带走。

一个实用的筛选顺序是：先确定你的应用是否真的需要自己的链（大多数不需要）；如果需要，再确定你需要 optimistic 还是 ZK 的最终性保证；最后才是在同类型框架中比较生态和工具。反过来做——先选一个框架，再为它找理由——是失败率最高的路径。