11周搭建生产级 L2 Rollup：逐周构建日志

“交钥匙”的实际含义

在阅读时间线之前，请先了解：当一个 Rollup-as-a-Service 供应商告诉你 4 到 6 周上线主网时，他们指的是 4 到 6 周内完成一个带有默认配置的可用排序器和一个桥合约。这并非一个生产级 L2。生产级 L2 是当 L1 Gas 飙升时不会崩溃的排序器、能在真实负载下满足最终性 SLA 的证明器、能经受监管机构质询的桥，以及只在真正出问题时才呼叫人类的监控系统。

这两个定义之间的差距大约需要七周的工作量。以下是这几周实际包含的内容。

人员配置： 1 名协议负责人，2 名基础设施工程师，1 名智能合约工程师，1 名 SRE，1 名产品/项目经理（兼职）。第 8 到第 10 周有外部审计。

第 1 周：用例与堆栈选择

第一个决定影响最为深远。Optimistic 堆栈（OP Stack、Arbitrum Orbit）与 ZK 堆栈（Polygon CDK、ZK Stack）之间的选择。团队根据五年运营预算映射了吞吐量目标、提款时间容忍度和证明成本。ZK 在纸面上看起来很有吸引力，因为它能消除七天的提款等待期。但数据表明 optimistic 方案更优：基础设施成本更低，运营所需团队更小，工具也更成熟。

决策：采用 OP Stack。结算层使用以太坊。数据可用性使用 Celestia。初始使用默认排序器，并规划了去中心化路径。尚未编写任何代码。

第 2 周：基础设施搭建

创建云账户、IaC 模块、密钥管理，以及为 OP Stack Rollup 所需的四个特权角色（管理员、批处理者、提议者、排序器）生成钱包的脚本。

我们早期发现了一个错误：钱包是在笔记本电脑上生成的，并存储在 1Password 保管库中。协议负责人提出了反对意见。到周五时，这些钱包已被轮换，在 HSM 工作流中重新生成，笔记本电脑上的钱包已被销毁。这件事没人会谈论，直到他们需要向投资者解释为什么 4000 万美元的金库密钥曾保存在密码管理器中。

第 3 周：在 Sepolia 测试网部署 L1 合约

部署了 L1StandardBridge、SystemConfig、OutputOracle、OptimismPortal。op-deployer 工具处理了大部分工作。但它没有处理的是：代理管理员的升级权限，默认设置为单一签名者 EOA。团队将其替换为一个 4/7 多签，并带有 48 小时时间锁，然后才向任何合约注入资金。这多花了两天时间。如果你跳过这一步，你推出的 Rollup 将面临单把密钥泄露即可掏空桥的风险。

第 4 周：排序器与节点服务启动

op-geth、op-node、op-batcher、op-proposer 部署在三个区域，并配有自动故障转移。首次 L1 到 L2 存款成功。首批 L2 交易开始流转。团队庆祝了一番。

然后 SRE 问道：当批处理者的 L1 钱包在周日耗尽 ETH 时会发生什么？没人有答案。于是添加了监控告警，并编写了补充操作手册。Rollup 在生产环境中因这类“无聊”的原因而崩溃，团队在本周结束前又编写了三份“无聊故障”操作手册。

第 5 周：几乎让启动夭折的一周（之一）：数据可用性

团队在第 1 周决定使用 Celestia 作为 DA。第 5 周现实降临。OP Stack 上集成 Celestia 需要一个自定义的 plasma DA 包装器，命名空间分配耗时超出预期，并且 DA 故障安全路径需要显式回退到 L1 calldata。当时该 plasma 包装器仍是测试版软件，在真实批次大小下三天内崩溃了两次。

修复花了五天时间，并与创始人进行了一次艰难的对话，讨论是否要更换 DA 层。团队保留了 Celestia，添加了“如果 DA 确认延迟超过 90 秒则自动回退到 blob calldata”的路径，并为其部署了广泛的监控。

第 6 周：桥加固与经济学配置

默认的 L1StandardBridge 代码经过了审核和审计。但默认配置没有。团队花了一周时间设置并记录了以下内容：

• 每资产和每用户的提款速率限制
• 暂停权限限定于一个 2/3 紧急多签
• 抗审查的强制包含窗口
• L1 到 L2 消息的 Gas 上限以防止 griefing 攻击
• 初始可桥接 ERC-20 代币的白名单

这是不起眼的工作。但也是决定你的 Rollup 能否在第一次遇到恶意行为者时存活下来的工作。

第 7 周：几乎让启动夭折的一周（之二）：错误证明与争议游戏

OP Stack Rollup 需要错误证明基础设施，否则它只是一个被美化的侧链。op-challenger 服务监视无效的输出提案并进行争议。正确配置它意味着要理解争议游戏合约、质押经济学以及挑战者需要在几分钟内还是几小时内行动的场景。

团队对这项工作低估了整整一周。挑战者虽然在运行，但并未针对独立的执行客户端进行验证，这意味着它会批准提议者发布的任何输出。修复这一问题需要启动第二个以可信模式运行的 op-geth 实例，将其接入挑战者的验证路径，并编写测试来模拟恶意提议者。

如果这个漏洞被遗漏并且 Rollup 已经启动，安全模型将只是纸上谈兵。桥将因一个错误的输出提案而被掏空。

第 8 周：审计启动与前端集成

外部审计开始。四名工程师继续加固基础设施，同时智能合约工程师全职与审计人员合作。与此同时，Rollup 被集成到现有前端，RPC 提供商签约，区块浏览器部署完成。

审计人员在第一轮中发现了 11 个问题。其中三个严重性为高。没有一个是团队编写的代码问题，全部是配置选择问题。在生产级 Rollup 中，配置就是代码。这个教训直到第 8 周时才会有人真正内化。

第 9 周：几乎让启动夭折的一周（之三）：负载测试现实

第一次真实的负载测试：每秒 2500 笔交易，持续一小时。排序器撑住了。但到测试结束时，证明器落后了 18 分钟。桥提款开始排队。监控在 60 分钟内触发了 47 条告警，其中大部分是误报，这意味着真实信号被淹没了。

一次暴露了三个问题：

1. 在真实内存池波动下，证明器的吞吐量并未达到规范书声称的值。
2. 告警阈值是针对测试网负载设置的，而非主网。
3. 提款队列没有限流电路，只有一个硬上限，返回的是无用的 revert 信息。

团队花了两天时间从头重写告警逻辑，添加了一个带有背压的优雅提款队列，并配置了比原始预算多 60% 的证明器容量。这是唯一一周，有人认真考虑是否要将启动推迟一个月。决定继续推进，是因为问题已被识别、受控并处于监控之中，而非问题已经全部解决。

第 10 周：审计修复与最终加固

所有审计发现的问题均已关闭。重新审计确认没有回归。进行了 12 小时的浸泡测试和一次混沌测试，在批次处理中间杀死了排序器。恢复过程干净利落。操作手册有效。

第 11 周：主网上线

创世区块生成。桥上链。首个主网交易发生在周二 14:32 UTC。没有人发推庆祝。团队连续 72 小时盯着仪表板。

这才是 Rollup 真正上线的那一周。而不是在第 6 周它首次能够工作时。

“交钥匙”的实际成本

以上 11 周描述了由一个已经熟悉领域的小型资深团队实现生产级 L2 的最小可行路径。所谓的“4 到 6 周交钥匙”承诺是真实的，但它只把你带到这个时间线的第 4 周，而第 5 周到第 11 周还在前面，并且被伪装成“上线”。那些没有考虑到这个差距的创始人会在第一次遭遇恶意事件时发现它。

交钥匙服务涵盖的是那些已被充分理解并模板化的部分。它不涵盖那些决定你的链能否在真实对手、真实审计或真实负载峰值下存活的部分。这些部分需要第 5、7 和 9 周。

• 原文链接： medium.com/@ancilartech/...
• 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～