一文解析 OP Stack 受开发者热捧的原因

撰文： Haotian

最近， OP Stack 表现尤为抢眼，先后有 opBNB、Zora、Base、Worldcoin、DeBank 等十多个项目宣布加入 OP Stack 阵营，有博主预估仅 Base 一家就可以给 OP Treasury 带来 $4.5M 额外收入。

难道只是因为 Optimism 在 layer2 中很正统，会整活吗？这背后的门道恐怕没那么简单，我来说说我的思考：

一个开源堆栈被广泛应用的关键是 License 的开放程度，四大天王提供的 Stack 服务中，Optimism 为 MIT License，而 zkSync、Arbitrum、Starknet 都用了 Apache License 2.0，二者都是开源程度较高的 License 许可证，但 MIT 更简洁自由，通俗讲可以为所欲为。而相较之下，Apache 则在兼容性、商标使用、专利授权、责任限制等方面都有一些限制，看似有利于产品商业化，实际上却成了枷锁和限制。

Optimism 和以太坊 EVM 的兼容程度高，看其 Github 11994 次 Commits 2. 3k forks （开发者活跃度）就知道这背后有多少代码更新和融合工作了，这个数据甚至优于 Arbitrum ，也远超 zkSync 和 Starknet 。试想，一个和以太坊融合度更高，现在开源自由程度又最大的 Stack ，哪个项目方能不爱？某种程度上，选择 OP Stack 还真是选择了 L2 的正统性。

不少人说 OP Stack 成了项目方“一键发链”的工具，这句话带有讽刺韵味。估计有些项目享受“拿来主义”时并没有想过，一键发链搞 layer2 的必要性。如果真是一种撸撸毛党的盈利手段，这样的 layer2 只能是榨取市场流动性的一个叙事罢了，显然这和 Optimism 最终要实现的 SuperChain 愿景也背道而驰。其实，项目方之所以尤为在意商业化“自由”，主要还是在打“创收”的算盘。

个人认为，像 Base 这样有 Coinbase 光环加持的项目，可以靠用户的撸毛预期，开发者的活跃明显从 C 端市场吃到一口肉，其他 layer1 这么做，主要为在熊市增加一些 B 端服务商业收入来源， Rollup as a service (RaaS)。基于这套成熟的 L2 方案，来为一些开发者提供潜在商业化的服务。因为 OP Stack 比较通用，不同链做 layer2 还得做专业的定制开发，而把这样的定制开发能力打包卖给没有开发能力的客户，很 make sense 吧？这确实是一种熊市“苟着”的策略。不然，一个 NFT 市场，一个资产社交平台做 Layer2 图啥？

那为啥不用 Arbitrum 的 Orbit 做 layer3 呢？ layer3 的专属链固然好但目前市场需求并不大， Cosmos 数百个专属 appchain 的现状似乎验证了这一点。而且 layer3 的跨链通信交互目前还存在技术难点，在游戏、 social 等应用链市场起来之前，偏金融属性的 DApp 尤为看重应用之间的可组合性和通信性，以目前的技术成熟度，开发独立专属链会有摩天大楼建在郊区的无力感。眼下， Layer2 的市场需求无论是叙事性还是叙事性，明显大于 layer3 。

那用 zk Sync 的 ZK Stack 做 ZK layer2 不好吗？确实，基于 ZK Stack 也可以构建 layer2 。开发者当然想搞 ZK ，毕竟叙事性更强，但奈何它难搞啊。 Stack 最核心的 zk circuit 电路算法是个难啃的骨头，开发者想走 zk 路线，仅消化编程语言 gap 和 zk 电路的高深就得一段时间吧。想独立定制开发 ZK 电路系统，技术上太难了，当然共享 zk Sync 的组件也是个选择，但现在这大兄弟支持吗？我们从 opBNB 荒废的 ZK 代码更新就能看出端倪。

以上正是 OP Stack 能在四大天王 Stack 战略中拔得头筹的原因。我个人觉得这对 Optimism 来说是利好，因为项目方可以选择定制开发 Sequencer，也可以和 Optimism 共享一个 Sequencer，而后者需要给 OP Treasury 纳税，这位博主对 Base 的收入做了预估，以目前的市场热度，以 10% 的分成，OP 都可以拿到 $4.5M 的收入，将来随着 BASE 生态进一步壮大，这一数字保守可能达到 $20M。

最后，当然期待更多的项目方能够基于 OP Stack 开发，最好也雨露均沾一下，照顾下 Arbitrum Orbit layer3 和 zkSync 、 Starknet 的生意。不过，布局 layer2 或 layer3 之前，得想清楚自己的起心动念，如果只是为了多个叙事，蹭 L2 的热点大可不必。至于 ZK Stack 也不要眼红 OP Stack ，先做好自己核心 ZK 组件的去中心化才是最主要的，未来会有被开发者广泛使用的一天。