撰文：Haotian

在 zkSync 链上刻铭文，短时涌入的天量交易，确实是一次 layer2 公链性能的「压力测试」，不过结果并非「宕机」，恰恰相反，这是一次 zkSync 的公开练兵，结果是 TPS 峰值、GAS 稳定性等都完美经受了考验。

乍一听，是不是有点反直觉？接下来，用技术逻辑，我来给大家澄清一下：

zkSync 打包出块的工作原理，简单而言：用户构造交易进入 zkSync Sequencer 的排序序列，然后 Sequencer 根据 Gas Fee 高低排序打包进区块，然后再把区块传入 Proof 系统验证，最后 Submit 到主网完成 finality 状态确认。

这里边有 2 个关键点，容易制造「体验糟糕」假象：

1）用户构造交易环节：大部分用户都会通过 Metamask 等钱包端发起交易，而通过钱包端向 zkSync 发交易，交易会先进入 RPC 远程调用服务器里，然后 Sequencer 接收这些交易进入排队序列。这里的排队时间短则几秒，长则几分钟，人如果等待时间较长，MetaMask 就会认定该笔交易已经失败，然后前端返回交易失败的提示。

然而，这并不意味着交易真失败了，而只是因为 Metamask 的 RPC 响应时间和反馈逻辑和 zkSync 的 Sequencer 排队打包交易逻辑存在「不兼容」所致。这正是为何，一些明明 MetaMask 显示失败的交易，在等待一段时间后，后端服务器显示又成功的原因。

如果用户不走钱包管道，直接使用后端代码调用 zkSync 的 RPC，就不会存在响应时间超时以及提示失败的问题，体验相对而言会很丝滑。这确实会让一些可使用后端代码指令的「科学家」取得了优势，但本质上属于钱包体验端的问题，和 zkSync 链的处理能力无关。

2）Sequencer 公平排序环节：当用户短时向 RPC 队列发出交易时，每一笔交易都会从 nonce 值为 0 开始叠加，如果上一笔交易还在排队状态，nonce 为 0，这时用户又发起了一笔新交易 nonce 为 1，zkSync 的 Sequencer 会根据 time 来给这些交易分配 nonce，然后按照顺序排序。

但倘若，用户在 MetaMask 前段看到上一笔交易显示失败后，同时又提交新的交易，很可能新提交的交易由于钱包端和 zkSync API 接口调用的问题，有一部分交易最终并没有成功提交到 RPC 的排队序列中。用户以为提交了很多交易，实际上 zkSync 只收到了其中一部分，而只要他们收到就会去排序处理。

这么看，用户看到 MetaMask 反馈交易失败，不停提交新交易的行为也会造成大量交易失败，因为根本就没有提交到 zkSync 链的后端，只是你在前端以为自己提交了。

整体而言，MetaMask 钱包的 RPC 响应时间逻辑问题和用户着急向链上叠加交易的行为，都会造成大量的交易「失败」，如果清楚 zkSync 的后台交易处理工作流程的话，相对更容易避开这些优化体验问题。

基于以上科普，再来澄清下「宕机」问题：

zkSync 链并未「宕机」，只是浏览器前端显示问题，因为浏览器会通过 zkSync 的 RPC 接口拉取最新数据，但是接口响应会有延迟，大量新交易会使响应变慢。

总之，浏览器的拉取数据同步速度跟不上排队交易激增的速度，这是浏览器前端的问题，与链的运转没有关系。通常等交易速度适当放缓，浏览器可以抓取到新数据后，问题就会解决。

当遇到浏览器不 work 的时候，可以通过其他同步 zkSync 区块数据信息的浏览器来交叉验证，比如：https://hyperscan.xyz

真实链的「运转性能」情况如何呢？

1）在所谓宕机传闻爆出后，zkSync 的官方工作人员 Anthony Rose 在推特却频频发出 TPS 刷新捷报。实际上，zkSync TPS 飙到了 187.9 的峰值，正常情况下，TPS 只有 50-100 左右，这说明大量的新交易涌入，zkSync 其实抗住了压力。这确实也给未来数千甚至上万的 TPS 做了一次充分的「压力测试」。

2）ZK-Rollup 的特殊机制决定了，处理的交易量越大，Gas 费则越便宜，事实上，zkSync 的 Gas 费确实更加便宜了，因为交易成本也被分摊了，根据 growthepie 数据显示，近 24 小时，zkSync 的 Gas 平均值还降低了 5.2%，平均在 $0.19 左右，这个数据每个人的体验可能不一样，但综合链的运行数据，确实是便宜了。佐证了 ZK-Rollup 的更流畅体验需要将现有的用户规模提升一个量级。

铭文事件对 layer2 公链的影响？

根据 dune 数据显示， Sync 的铭文铸造，14 个小时新增了 5M 笔交易，已有 65575 个 Holder 参加。诚如上述所言，zkSync 官方已经知道了这场社区发起的「压力测试」活动，还紧急采取措施来确保 zkSync 链的有序进行。

这个数据对 zkSync 而言确实是一次较好的压力测试实验，其正向影响大于负面。长远看，铭文事件并非传言中把 layer2 性能打回了原型，反倒给 layer2 的进一步性能优化提供了实践经验。

不过据我了解，除了 Sync 之外，还有其他铭文正在铸造，虽不及 Sync 那么 fomo，但也给此压力测试添了一把火。

Anyway，结果总体而言是好的，大家若厘清 zkSync 后台排序出块的技术逻辑，再拨开其中存在的「体验糟糕」误会，就应该懂得，一切运行安好，我们得给 layer2 多一点信心。